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.