Week 28 Day 6: When 'Good Enough' Is the Right Definition of Done

'Good enough' has a bad reputation because it sounds like mediocrity. But 'good enough' is actually a sophisticated judgment: understanding precisely how much quality the situation requires and investing exactly that much. The internal tool that five people use does not need the same polish as the customer-facing product that serves a million users. Applying the same Definition of Done to both is not quality consciousness -- it is waste.

Here is the framework for calibrating your Definition of Done to the situation. Ask three questions. First: who is the audience? Internal teams have different quality needs than external customers. An internal dashboard that is functional but ugly is fine. A customer-facing interface that is functional but ugly is not. The audience determines the polish threshold. Second: what is the cost of failure? A bug in the billing system that overcharges customers has a different cost profile than a bug in the internal reporting tool that shows the wrong chart title. The cost of failure determines the testing threshold. Higher-cost failures require more thorough testing. Lower-cost failures can tolerate faster, lighter testing. Third: what is the expected lifespan? A prototype that will be rebuilt in three months does not need the same architectural quality as a platform component that will run for five years. The lifespan determines the code quality threshold. Short-lived code can tolerate shortcuts that would be unacceptable in long-lived code. Using these three dimensions, you can create tiered Definitions of Done. Tier one -- minimum viable: functional, tested against primary paths, deployed. For prototypes, experiments, and internal tools with small audiences. Tier two -- production standard: functional, fully tested, documented, monitored, reviewed. For customer-facing features and business-critical systems. Tier three -- high assurance: everything in tier two plus performance testing, security review, accessibility audit, and disaster recovery verification. For financial systems, healthcare applications, or any system where failure has severe consequences. The tier system gives your team permission to be appropriately thorough rather than uniformly exhaustive.

The tiered Definition of Done approach implements what Weinberg (1992) calls 'quality as relative value' -- the principle that quality is not an absolute standard but a relationship between the investment in quality and the value returned by that investment. His 'Quality Software Management' framework demonstrates that the optimal quality investment varies by context, and that both under-investment (too little quality) and over-investment (too much quality for the context) are wasteful. Research by Boehm and Turner (2003) on 'balancing agility and discipline' quantifies this tradeoff: they found that quality costs follow a U-shaped curve, where both minimal quality investment and maximal quality investment produce higher total costs than context-appropriate quality investment. The three diagnostic questions (audience, cost of failure, lifespan) map to what risk management frameworks call 'risk-based prioritization' (ISO 31000). The audience question assesses 'impact scope.' The cost-of-failure question assesses 'severity.' The lifespan question assesses 'temporal exposure.' Together, they produce a risk profile that should determine the quality investment. Research by Jones (1996) on software quality economics found that organizations using context-dependent quality standards achieved 20% lower total cost of ownership than organizations using uniform standards, because they avoided both the cost of under-quality (defects) and the cost of over-quality (unnecessary process overhead).