Schedule and Events

March 26-29, 2012, Software Test Professionals Conference, New Orleans
July, 14-15, 2012 - Test Coach Camp, San Jose, California
July, 16-18, 2012 - Conference for the Association for Software Testing (CAST 2012), San Jose, California
August 2012+ - At Liberty; available. Contact me by email:

Wednesday, February 04, 2009

Context or what?

There's been a lot of conversations recently on twitter about context. Specifically, the context-driven-school of software testing, which says that the way we do our work should be (strongly) influenced by the business problems we are currently living in.

I went into some detail on this earlier in the week in an interview with the Elegant Coders.

Two days later, and I read Ron Jeffries's Post "Context My Foot."

Now Ron is a very smart guy, and when he and I disagree, I start to wonder what's really going on.

Here's what I see as Ron's Objection: You say your team wants to do extreme programming, but you have business analysts who write requirements documents. You can't fire them - they are your context. So you don't do story cards, but instead do written documents.

And your executives are used to getting estimates of the exact day the software will be done, with all features. And you can't change them - why, that's the business context!

And you've got this one Vice President of Engineering who really hates pair programming, and the HR department won't let you move the cubicles around to create an open environment ...

etc, etc, etc. Rinse and repeat. Eventually, you've made so many compromises that you aren't really doing agile at all.

But you're context-driven, right?

Well, uh ... no.

When I speak of the business domain, I do not mean the fact that a certain vice president is stuck in his ways. Those might be impediments - they may even be context - but they are accidental.

When I talk about context, I mean the essence of the business problem. The essence of the problem at XBox 360 at Microsoft is different than the essence for people developing embedded systems at Boeing.

Don't believe Matt Heusser? How about Michael Porter, professor of business at Harvard University. His book, Competitive Strategy: Techniques for Analyzing Industries and Competitors introduces a 'competitive forces' model in order to examine a business .

It is not light reading, but the basic argument is that to improve the business, you need to examine and adapt to your competitive environment. Instead of a simple prescription of "best practices", Porter gives his readers tools to figure out for themselves the right thing to do.

The book is about essential business context - not accidental. I've read it twice now, and I cannot recall a single instance where Porter talks about giving up on a strategy because the HR department doesn't like the idea.

So I remain context-driven. For nearly any practice, I can come up with cases where I might not want to apply it. And, at the same time, Ron Jeffries does have a point - some appeals to context are just whining.

Our challenge is to know the difference.


Markus Gärtner said...

Thanks for the hint. I've incorporated the book into my reading plans. Your description really made me curious about it, but I've so much to read back on my list, I hope I can get even during this year, hopefully.

Unknown said...

Hi Matt,

I think there is at least one false dichotomy creeping in here. There are a million shades of gray between requirements as 'written documents' and story cards. Indeed, both ends of the spectrum can be equally evil dogma.

A good analyst isn't hung up on 'written documents', but on understanding that context in which we need to develop our software. She brings a massive toolkit to the table: data analysis techniques, state analysis, use cases, quality analysis, myriad others. She's not hung up on slavishly using a specific set for every project, much less hung up on filling out every section of someone else's requirements template.

A good analyst makes sure that the team understands and agrees that they have the right context. This comes from discussions with the right people involved, looking at the system from different perspectives. This takes knowledge of a wide range of tools, and when to apply them, as well as knowledge of who needs to be involved in each conversation.

A static requirements document is as valuable as a set of story cards. More is needed in either case for all but the most trivial of systems.

The agile promise is almost always presented against a backdrop of poor examples of 'that traditional requirements work - documents', but there is danger that the agile community is being told to throw out the baby with the bathwater.

IMHO, of course ;-)