“In fact what you’ll see is that the hard-core geeks tend to give up on all kinds of useful measures of quality, and basically they get left with the only one they can prove mechanically, which is, does the program behave according to specification. And so we get a very narrow, geeky definition of quality: how closely does the program correspond to the spec. Does it produce the defined outputs given the defined inputs.”

– Joel, from his latest post Talk At Yale Part 1

Joel is wrong on this one. I only hope he is wrong because he is stretching the truth to illustrate a point, namely, how going to extremes are usually not the answer.

I do not think that the geek definition of quality is does the program behave according to specification. Perhaps it is for some people, but not for me, and I would say, not for those of us living and working in the real world.

We don’t have time to worry over the specification. We’re building software that was expected to be finished yesterday. That’s the whole purpose of the unit test, so we can determine if it works not like the spec, but like we expected it to, so we can then quickly change it for whatever may come tomorrow. An application passes if the green bar is visible in the test suite. But what that green bar symbolizes isn’t the spec – it ultimately symbolizes what the customer wants today, which is often very different from the spec that was handed down.

Yes, we as geeks do get caught up in the spec from time to time. But tools like unit tests, especially when coupled with agile development, force us to come up for air and design for what the customer wants, not what the spec says.

I think the bigger problem with geeks is that we often mistake ourselves as the ultimate customer, so we design with our biases in mind, and not the biases of others. That’s what gets us in trouble, not the spec, not the test.

Joel will now go on to make a complete fool of me in parts 2 and 3 and I’ll feel like an idiot, but that’s how life goes sometimes.