Thursday, November 30, 2006

Hiding Faults

It's a bit of a truism among software development professionals that users don't know what's hard and what's easy. Marketing people shrug and smile halfheartedly when you tell them that you've cut processor usage by 55% by designing and implementing a reentrant, optimized request-parsing module, and their eyes pop out of their heads with glee when "you can make it BLUE TOO?!?!???". Most complex systems have at least some opacity to the uninitiated; my Mechanic brother has a much more detailed idea of what A Good Car is than I do, and there aspects of structural engineering I know precisely nothing about. But at least in those two cases, and I'd argue most others as well, there's at least some way for nonexperts to judge the underlying quality of the system.

In software, that's a lot harder to do.

Most programs, especially in the Enterprise business, are heavily customized and customizable; there's no easy comparison to peers off the shelf, and nobody wants to go through two separate installation/configuration exercises just to compare performance. As a consequence, enterprise software just doesn't have the same quality pressures on it as a lot of other products do, including commercial software; after a week or so of using it, I can tell you that I like Firefox better than Internet Explorer 7 because it's faster, more reliable, and having complex pages open in one tab doesn't slow down other tabs. But how can anyone tell whether the Enterprise System they've just bought and spent a year customizing, at great expense, is really Good? We can measure Good Enough -- whether it meets business goals -- but we can't tell what the variance in quality for competitive products would have been. Is our implementation really Good, or is it Good Enough for us because our business is built to tolerate Bad? What economies are hidden from us, what effort are we wasting, because we don't know how Good our software can be?

All questions I don't have answers to. But I do know this: The difficulty we have answering those questions makes it possible for a lot of bad code, and bad coders, to survive in the marketplace.