- The Case for "Good Enough" Software Looks Great
- This Argument Is Sensible
- Is It Really Cheaper to Produce Buggy Software?
- Is the "Good Enough" Approach Useful for (M)any Projects?
- "Good Enough" Software Damages Your Reputation in the Marketplace
- So What's the Alternative?
- We Need Talented Developers, Not "Good Enough" Software
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Is It Really Cheaper to Produce Buggy Software?
One of the unspoken assumptions of the "good enough" approach is that it's more expensive to produce defect-free software than it is to produce defective software. In a sense this is true, because, as the old joke goes, "If it doesn't have to work, you can have it now." The question is really whether it's cheaper to produce something that nearly works but has a few defects, compared to something that works and has no defects.
To answer this question, we have to examine our assumptions about the software development process. Do we develop software and then spend time and energy finding and removing the bugs that have somehow sneaked into the code? Or do we continually and constantly create and simultaneously validate that the software is defect-free?
The first approach is the path to "good enough" software. It's a really good way to add lots of cool features that more or less work. It also justifies the need to do triage on the defects because there are so many that we only have the resources to remove the most important ones.
The second is the path to what I'll call software that "just works." No drama, no trauma, the software just works. Rather than spend lots of time writing new features on top of buggy code, we must strive to test and clean up as we go along. By making testing a continuous and integral part of the software development process, we never get to the stage where we can claim that there are bugs but it makes more sense to leave them alone.