- 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
This Argument Is Sensible
From a traditional software engineering standpoint, "good enough" software looks like a mistake because it ignores the goal of achieving high quality. It doesn't aim for six-sigma quality or defect-free software. Indeed, it even ignores the well-known number of defects metric.
The interesting thing, though, is that the "good enough" approach is sensible because it measures what matters. It counts problems that will have a serious impact on the users and ignores those that have a trivial impact. It does the risk management that software engineers seem to like. The decision to ship is based on the risk of shipping a software product that will be seen as low quality. Once that risk is low enough for the organization, the software is good enough to ship. Conversely, if there are not enough valuable features in the software, even if the defect count is zero, the risk of shipping is too high and the software is not good enough.