"Good enough" ain't

By: Doug Scott

Abstract: Obstacles are a natural part of a developer's career progress. Don't despair, and above all don't give up on quality in moments of doubt. By Doug Scott.

"Good enough" ain't

Obstacles are a natural part of a developer's career progress. Don't despair, and above all don't give up on quality in moments of doubt.

In Becoming a Technical Leader, Jerry Weinberg relates an entertaining tale about his study of the game of pinball. A player for forty years, Jerry found that his learning followed a "ravine plateau" pattern. He'd hit a point where his scores leveled out, and when he discovered a new technique to send the numbers back up again, the scores dipped instead -- until he had mastered the new skill. At that point his scores shot higher then ever before.

A developer's progress

Weinberg's story seems to me to describe what happens to developers as they mature in this industry. Skills, knowledge, and self-confidence rise and fall as programmers meet obstacles, overcome them, and surge ahead again. Trouble only threatens when developers takes obstacles too seriously, allowing them to stall progress. Instead, they should think of obstacles as a natural phase.

Junior programmers are pleased to find that the programs they have designed are actually worthwhile to users. They hit the first wall when they learn that despite their improving skills, programs still go wrong -- sometimes after long periods of daily use. They reorganize their knowledge and learn new techniques to keep their programs working even when other connected pieces break. Eventually they learn how to test programs so that they are robust yet easy-to-read and debug. And so they master the art of defensive programming. End of story? Hardly.

Unfortunately, lessons in disappointment continue -- especially for those who move into project management, systems design, or business architecture. Large systems are quite different from small ones; the techniques developed alone or in small teams no longer work when the team numbers a hundred, or (heaven forbid) a thousand developers. All earlier knowledge and experience can count for very little without version control, test beds, and good documentation utilities. Down go the confidence levels as developers scamper through training sessions, manuals, and web scans, trying to catch up on techniques of which they were only dimly aware before. And of course politics play a role; it's sad when developers' knowledge rates second to the rhetoric of a glib speaker.

Crisis of confidence

In their moments of doubt, developers may think: "Enough is enough. I can do no more." This is real failure (which can also be a gift, once worked through). Failure kills confidence in the ability to deliver a quality solution. Rationalizing, developers deny their basic ambitions: "Quality is not the goal we seek. We only seek delivery." And what a poor ambition that is. High quality is of course attainable -- and within time and cost constraints. All those legacy systems, written long before anyone had any grand schemes for design, testify to the idea that quality programs can be written, and can outlast their predicted life times by an order of magnitude. Why do developers deny that it can happen?

Consultants like James Bach and Ed Yourdon have suggested that we should give up on trying to produce "quality software" and produce "good enough software." Bach, an authority on software testing, asserts that the testing process itself measures software quality. As long as the testing process is of a higher quality than that which is to be measured, he argues, this is sustainable. My concern is that, like many theories, this one may be corrupted in actual practice. Rather than train staff to produce better software, managers can use the phrase "good enough" to justify lower standards.

My problem with "good enough" is the same problem Kevin Weeks pointed out in "Fighting Words," although I take the opposite perspective. Weeks asserts that quality cannot be defined except in relative terms. This is my own reservation about "good enough:" there is no acceptable definition. The predictable consequence of such a standard is that programmers or marketers themselves define and argue over "good enough."

A developer might argue against the readiness of a new compiler, for instance, citing its 200 obscure bugs and its six serious ones. Management might consider the six serious bugs negligible (ignoring the 200 obscure ones entirely), insist that the compiler is "good enough," and ship it as it stands. At the other extreme is a hardware manufacturer I knew. Obsessed with a single extremely obscure fault, he broke into the development labs one night and stole a prototype motherboard from the engineer's workbench.

Can "good enough" be determined objectively?

James Bach argues that "good enough" is best judged in testing by using a risk-based approach. You monitor the nature of the errors encountered against the level of test coverage, and then judge the degree to which that represents an acceptable level of quality. The temptation to adjust that level downward must be powerful, and I believe such meddling accounts for much of the hostility Microsoft faces today. (It may also explain the high interest in Linux, which is much more difficult to set up and use).

Yourdon and others embrace "good enough" without Bach's stringent measurement requirements, using the concept against developers who take pains to deliver products of quality. Is "good enough" really what customers want? (Remember customers? Those awkward cusses who are the only source of revenue for this industry?)

A quality product has its quality designed in. In addition to architecting a solution, developers must strive to ensure that the design is sympathetic to the rest of its environment. Microsoft programmers have, in the past, written a new API rather than re-using or modifying one already in the library, and the result is a mess of APIs which are difficult to understand and maintain. Without foresight and without integration, MS may always be first to market. But it will need to commit a sizeable maintenance team to look after the obscure and difficult code. And it will continue to face hostility from users who have to fight with its products.

Most managements are blinded by the idea that quality slows progress, and the Bach message is that quality is unattainable anyway. Yet when time spent on rework is considered, all studies have shown that concentrating on quality by improving the development process actually speeds progress. Capers Jones reports that 45 percent of faults are caused in the stages before coding starts (requirements and design). Sort them out early, and the benefits later on are significant. Building quality into the product from the start ensures that the need to set a level for "good enough" doesn't arise. Quality is there from the start. How can quality be ascertained? This is something I'll be coming back to in the next few weeks. You can attain a high quality product without slowing your projects to a crawl. Nor must concern about quality unload a lot of bureaucracy onto your most precious people, the developers.

Still, a slice of working code is a very seductive thing; some (I believe most) managers will sacrifice tomorrow's clean system  to see code running today. If things are going to change, they're going to have to be changed by stealth.


Server Response from: ETNASC01