Software and Common Sense, Part II
August 14, 2006
Alex Bunardzic responded to my previous post, so it looks like we have a genuine discussion brewing here. Blog to blog isn’t particularly efficient, but efficiency isn’t the point of these sorts of things, is it? So, here’s Alex’s original post, my response is here, his response, and now … here we are.
Alex is correct, that this is an issue of common sense verses counter intuitive methodology. Well, mostly correct — good methodology doesn’t have to be counter intuitive. But that’s just nit picking. Perhaps a more accurate statement is that this is an issue of naive verses educated intuition. Rephrased, I think we’re both headed in the same direction .. if from different angles.
Alex’s example of the intuitive (but poorly educated) stock trader is a perfect example. Naive, eager, and ready to commit to whatever catches his fancy — a recipe for disaster, no doubt. Of course, given extensive training and having worked with successful mentors, the trader’s intuition matures and becomes an incredible asset. The book “Blink” examines the power of intuition in both naive and trained forms; Kathy Sierra and Dan Russell have written about it several times. Intuition (or first impression, or whatever you’d like to call it) can be a very valuable tool, no doubt about it … but it has to be challenged and defended and honed over time to become so.
I guess I just have a hard time trusting plain ol’ common sense as a good justification for action. When someone says “Peat, I think we should take this approach” my first question is … why? “It just seems right” isn’t a good answer, even if that person has informed opinions and a good track record of making correct decisions. Is it an issue of trust? No. It’s simply taking the appropriate time to make sure that we’re doing the right thing.
The key, of course, is appropriate.
Alex goes on to say:
“I’ve seen too many people being enthusiastic about the counter-intuitive, bureaucratic ways of developing software. That approach is almost always amazingly catastrophic.”
And he’s perfectly, 100%, absolutely, correct. Heavy handed practices are largely professed by people who don’t know enough about their responsibilities, or don’t trust the advice of people who do. In trying to cover their asses, they suffocate the creativity and passion required to make good software … and kill the effectiveness of their people and product.
On the other hand, if I simply ask “why?” and challenge the technique in question, two things happen: it becomes a question, and therefore a conversation; and the people who make a decision together feel responsible for it. “Why” breaks the intuitive cycle, but not in a fashion that cripples the process of building software. “Why” builds better software, and better developers. Sometimes asking “why” requires a team to throw out heavy processes … or take them on.
I guess it’s important to frame the conversation within the context of what’s important. As Alex said,
“It’s all relative, you see. The only thing I truly care about is the best results for the end user — a human being paying to use the software.“
Sometimes, that person’s life depends on the software, and consequently a remarkable amount of time and energy should be spent on making the system as robust as possible. Sometimes, it’s just a cute little web app. Regardless — good software is always about the end user.
Anyhow, intuition is just another tool in the box, but it’s the first one we pull out of it. It’s worth investing in a good one, but foolish to depend on it for everything.