#70 Setting a Context

Mark Griffin (0:04)

Hi, welcome to another edition of the Construx Inspect and Adapt podcast. I'm your host, Mark Griffin, Director of Customer Solutions here at Construx. We're a team of software engineering experts founded by legendary author, Steve McConnell. Here at Construx, we believe every software team can be more successful at delivering higher levels of business value.

Today, we're going to talk about a simple word with powerful ramifications and successful soft projects, and that word is context. How should teams use it to get things aligned in the right direction? What are some of the things in software projects that setting context can help with?

Senior fellow, Earl Beede and Principal Consultant, Steve Tockey dig into this topic and largely agree on the ways to reap its benefits. So let's listen in.

Earl Beede (0:47)

Today's topic is this idea of setting a context or a context diagram or a use case diagram or something like that. Someone will say, here's where you are, a little map that says you are here and here's what's around you.

This is actually a big deal in the world of software. What we see over and over again is that organizations start building these projects and they've never stopped and said, what is our context? What is this? I'm referring to when I say the project or the system or the product. I've gone into many companies and I asked the question right off the bat, help them understand, particularly when we're doing things like requirements. What is your product?

They all look at me and go, oh, the product is, and I get four different answers. I say, okay, let's map this out, and we start to draw it, and they realize that they do not have a consistent idea of what is in and what is out, what the scope is, and this is what a context does. Setting the context is actually a critical part of actually doing any good project work on software development or even development work on software development. And what we see over and over again is that a lot of meetings can be made a lot more efficient and effective, a lot more communication can happen if you understand the context. No thoughts on that so far?

Mark Griffin (2:07)

Yeah, no, I think it's, I think you're...

Steve Tockey (2:09)

Okay, so far, carry on, carry on.

Mark Griffin (2:11)

Carry on.

Earl Beede (2:11)

Okay, carry on. Steve was just shocking me, because I actually assumed, and this is my ignorance, I assumed that in early software development, early world of software, the context was kind of known.

You were building one system, that was it. You were building one computer and the software just happened to come with the computer. Software was initially just another part, like a screw or a drum. That's just what you did to help make the computer run, and you sold it as part of the computer. You didn't sell it separately. And so the context was pretty well known. You didn't have to do a bot. But Steve said, hey, Earl, this came out of Structured Analysis in the 70s.

Steve Tockey (2:52)

Right.

Earl Beede (2:53)

And I would think, you know, it really didn't really, if it was 70s, it had to be late 70s, because we didn't get the complexity necessary really to say, ooh, I need to stop and figure out what my context is, because we knew it. It was just, we were building it and plugging the wires in, it's like, this is the thing that happened.

Steve Tockey (3:09)

No, not at all. Structured Analysis and System Specification by Tom DiMarco, did it come out in 72?

And so that's even when it was published, it must have been used before that.

Earl Beede (3:25)

Fair enough. That's education to me here, because one of the things I want to sort of really bring up over and over again is that even if it was, it just started with DiMarco in the late 60s, early 70s, no one uses it even hardly today.

Steve Tockey (3:42)

Well, it would be fairer to say that it was popularized by DiMarco. Whether or not it was invented by Tom could be another story.

Earl Beede (3:54)

Yeah. And as Mark was saying, we're probably doing some sort of content analysis or context understanding well before software was. This is not something that software necessarily invented, but a lot of software teams don't do it.

I don't know how you've gone into shop, Steve, and looked and said, okay, tell me what's going on here. What is the boundaries of this? Well, three, four different answers come out in short order because they've never sat down and really analyze what is the boundaries of the product, of the project, what the scope is, and all this is what setting the context with something like a context diagram or a use case diagram will give you.