Context Matters

  1. Posted on June 17, 2007 10:21:AM by Earl Beede to Practicing Earl
  2. Methods & Processes, Technique, Agile, humor, problem space, solution space, context, requirements

So, I was driving along, making a right turn into a driveway like I have done a thousand times before. I did what one always does when making a right turn: I checked carefully for pedestrians and watched the driveway to make sure nobody was coming down it. I then signaled my intentions and proceeded. Unfortunately, this right turn was occurring in England. Did you know that right turns in England cross on-coming traffic before entering a driveway? Well, I and another car added more evidence to the theory that two pieces of matter can not occupy the same space at the same point in time. In making that right turn, context mattered.

Context matters with requirements and design work. The context actually determines if something is part of the problem space or the solution space. The same exact statement (e.g. the menu must drop down) is a solution requirement if the context is that I am to build the user interface; a problem requirement if the context is that I am to build the database only. In fact, I am starting to believe that any kind of specification without a clear understanding of its context is basically worthless.

Context matters when picking lifecycles. I recently was teaching our Agile seminar and describing the basic Agile approaches. "But," said the students, "we have twenty interdependent technology streams with 300 developers building a core proprietary OS on three continents with at least five 'equally treated' stakeholders who need direct access to the developers to work out interface details to the UI and other hardware components while maintaining backwards binary compatibility." Well, out of the box XP isn't going to cut it here.

Context matters as we determine solutions. In fact, one of the great failings of software development is that we often design our solutions more on the function to be performed rather than the characteristics (qualities/non-functionals/attributes -- select the name you like) the design supports. A solution that would be functionally fine if the context were that maintainability didn't matter may be worthless in a context that has long term support concerns. It is my observation that this kind of context is rarely described in a project.

Speaking of the project, context matters there, too. Which side of the "iron triangle" -- schedule, resources, or functionality -- is the side that is fixed and which side will adjust? (Clue here for managers: you can only fix one and your project will have a higher chance of success if you don't change your mind five or six times during the project.) I will select all manner of practices for one context and different practices in another.

In fact, context matters with any "best practice". The word "best" doesn't make it immune to the reality of the context. While it may be best somewhere, it could be a "worst practice" for your project. How do you know the difference? You can't until you fully comprehend the context and that usually means trying the practice out. (A *** Vitale moment: "Plan-Do-Check-Act time, baby")

I hope you take all these ideas in the right context.

Post a Comment:

 
 

Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).

 

Contact Earl