Exposing the Fallacy of "Good Enough" Software
- 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
The idea behind "good enough" software is that quality is situational and subjective. James Bach of Satisfice Inc. describes "good enough" software as making rational choices in the face of market-driven projects. The idea is that it's okay to ship with bugs as long as you ship with the "right" bugs; that, given enough benefits, the minor problems will be overlooked.
The Case for "Good Enough" Software Looks Great
Software projects are very complex and hard to predict. Yes, the latest buzzword-compliant methodology may make great promises for productivity and predictability, but the reality is that surprises happen. Given that reality, software projects should focus their resources on producing software that is "good enough," which means that the benefits outweigh the problems and that further improvement would be more harmful than helpful.
The idea that further improvement could be harmful follows from the assumptions surrounding market-driven software. On resource-constrained and time-constrained projects, the assumption is that costs for higher quality can be too expensive to achieve, so a lower quality has to be accepted.
James Bach calls this a utilitarian approach and says that to be "good enough" you have to be able to distinguish between important and unimportant, necessary and unnecessary. When defects are found, they need to be evaluated on a case-by-case basis to determine whether the problem is serious enough to require fixing.
The idea is that if the problem is insignificant, then in the larger scheme of things it's unimportant and it's not necessary to fix the defect. Overall the project is better served by leaving the defect alone. Yes, the problem will be noted, but the team's time and energy is better spent on adding other valuable features or removing problems that detract from the value of the overall product.