Information Technology Dark Side

Every now and then I write an article that gets a lot of attention for whatever reason. My post, “Is there REALLY any rigor in waterfall,” was one of those. Sure, it wasn’t as popular as “The Rules of Office Romance,” by DJ1.0, but it captured a considerable audience for a few days and became embroiled in a chicken-egg discussion about requirements and testing on a blog over at InfoWorld. Here’s a quote from one of the comments that almost made me feel really good.

“Take a look at this post on Tech Dark Side where David Christiansen goes back to “the source” to see what problem Dr. Winston Royce was actually trying to solve when he documented the waterfall methodology back in 1970.

I’ve known for a while that waterfall shouldn’t be the only method. After reading David’s post, I’m almost ready to agree with his conclusion that it should never be used.”

Frankly, I’m perplexed by the belief among many technology practitioners in the ideal, the “one true process,” that will solve any problem, whether it is Waterfall, Spiral, Agile, or whatever comes next. It is a fixation I believe is unique to IT – I don’t remember seeing this type of zealotry when I worked as a manufacturing R&D engineer at Bell Helicopter. Engineers there had a much more experiment, do-what-it-takes sort of attitude that couldn’t be captured, analyzed, and then reduced to a simple prescription for project success.

Maybe this has something to do with the fact that there’s nothing real about software – it’s an entirely abstract creation unlike anything else in our world. Or maybe it’s just too many smart people trying to “smart up” everything.

This post also sparked an interesting discussion with Mike Kelly, president of the Association for Software Testing. He complained, rightly so, that he never knows what I’m talking about when I use the word “process,” and then he introduced me to a model that I find very helpful, from James Bach‘s presentation “No Best Practices: How to Think About Methodology.” I’ll sum up here, but you can use the link to download the PDF if you would like to read the whole thing.

Basically, there are three contexts for the word process in discussions about methodology:

What we think we do

What we say we do

What we actually do

As a general rule, when I complain about process I am referring to what we think we do and what we say we do, not what we actually do. This is an important distinction to me as a project manager – part of my job is to reduce the gap between these three things by telling the truth about my projects, focusing on delivering valuable software that works, and generally doing whatever I need to do. You can hardly call that a process.

One more point, and then I’ll stop rambling. Nobody thinks the problems faced by IT departments are simple. I’ve read ComputerWorld, Better Software, Harvard Business Review, and other magazines for years and can’t recall seeing a single article claiming we’re trying to solve simple problems. Quite to the contrary, these magazines generally declare that the problems we try to solve get more and more complicated all the time. So what, right? Well, here’s the so what – “process” is most useful for solving simple problems with a few inputs and outputs, not complex ones.

Examples of good candidates for repeatable processes:

Tying shoes

Baking bread

Changing tires

Building the same part over and over and over

Applying for a credit card

Getting pregnant (probably funner without a routine process though!)

Examples of terrible candidates for repeatable processes:

Finding someone to marry

Being the first to land on the moon

Finding the Northwest Passage

Inventing the next killer app

Integrating multiple complex systems in a large, complex organization

Winning the superbowl

I think this is fundamentally the problem I have with process zealotry, that it just doesn’t add much value to problems that ultimately require uncommon brilliance, bravery, strength, intelligence, etc. to solve. It is better to believe in these human values, to rely on them, and on ourselves, than on some naive and idealistic belief in a “right” way to build software.

If you enjoyed this post, make sure you subscribe to my RSS feed! Stumble it!