Design-Defect Rework Cost: When Architecture Choices Bite

Updated May 2026. Source: Capers Jones; Boehm 1981; portfolio operational data.

The three patterns

1. The wrong abstraction

A class hierarchy, type system, or data model that does not match the domain. Sandi Metz's 2016 talk The Wrong Abstraction remains the canonical practitioner reference: duplication is far cheaper than the wrong abstraction. The visible symptom is that small feature changes require modifying multiple classes in non-obvious ways, that test scaffolding feels disproportionate to the test, and that new team members repeatedly ask why a particular structure exists. Wrong-abstraction defects are the most expensive design defect to fix because the abstraction touches everything built on top of it. They are also the hardest to catch in design review because the wrongness is often invisible until enough features have been built to show the mismatch.

2. The missing seam

Two modules that need to evolve independently have no clean interface between them. Michael Feathers' Working Effectively with Legacy Code (2004) coined the "seam" terminology and remains the practitioner reference for adding seams retroactively. The visible symptom is that every change to module A requires a coordinated change to module B, that tests cannot exercise A without setting up B, and that the team treats the two modules as one in conversation. Missing-seam defects compound over time: each new feature added without a seam makes adding the seam more expensive.

3. Excessive coupling

Changes in one module routinely require changes in two or three others, none of which are obvious from the original change. This is the textbook coupling defect, and the metric to track is the average number of files modified per pull request that should be a single-file change. SonarQube and CodeClimate both surface this metric; the average for a healthy codebase is roughly 1.3 to 1.8 files per single-concept PR. A codebase running at 3 to 5 files per single-concept PR is generating coupling-driven rework on every change.

The cost-of-change steepness

Design defects sit higher on the Boehm cost-of-change curve than any other rework category. The reason is propagation. A code defect typically lives in one or two files. A requirements defect propagates to whatever code implemented the requirement. A design defect propagates to every piece of downstream code that depended on the design, which on a mature system is usually most of the system.

The implication: when the cost-of-change is plotted by defect category rather than by detection phase, design defects show a steeper curve than even requirements defects. A design defect caught during design review costs roughly the same as a code defect caught in code review. A design defect caught after a year of feature development can cost 100 to 1,000 times more than catching it at design time. The Boehm cost-of-change page covers the underlying curve; the propagation steepness is what makes the design line particularly painful.

The three prevention investments that pay back

1. Architecture Decision Records (ADRs). A 1 to 2 page document per significant design decision, written before code starts, capturing the context, the decision, and the consequences. The ADR forces the team to articulate the design choice in words, which surfaces approximately 30 to 50% of the design defects that would otherwise reach implementation. Michael Nygard's 2011 blog post Documenting Architecture Decisions is the canonical reference.
2. Design review by someone outside the immediate team. A 30 to 60 minute review session with a senior engineer or staff engineer outside the team catches a different category of defect than internal review: the externally visible misfit with adjacent systems, the unfamiliar pattern that the team has not seen elsewhere fail. Costs roughly 1% of engineering capacity at organisation level; typically reduces design-defect rework by 25 to 40%.
3. Spike work for high-uncertainty design decisions. When the team is genuinely unsure about a design choice, a deliberate 1 to 3 day spike (throwaway code to validate the design) is dramatically cheaper than committing to a design and discovering it was wrong six weeks later. Spikes are under-used in most teams because they feel like "wasted" work, but the cost-of-change math favours them strongly for genuine uncertainty.

What design review cannot catch

Honest assessment: design review catches around 60 to 70% of design defects that exist at the time of review. It does not catch design defects that emerge over time as the system evolves into territory not anticipated by the original design. These emergent design defects are the wrong-abstraction category, and they typically cannot be prevented at all: they can only be detected early and remediated cheaply through good refactoring discipline.

The implication for engineering management: design review is a high-ROI investment but not a silver bullet. The complementary investment is a refactoring budget (typically 10 to 20% of sprint capacity) that allows the team to remediate design defects when they emerge, before they propagate further. The technical debt cost sister site covers the refactoring-budget side of the same equation.

Sources

• Jones, C. Applied Software Measurement. 3rd ed. McGraw-Hill, 2008.
• Metz, S. The Wrong Abstraction. sandimetz.com, 2016.
• Feathers, M. Working Effectively with Legacy Code. Prentice-Hall, 2004.
• Nygard, M. Documenting Architecture Decisions. 2011. cognitect.com.
• Boehm, B. Software Engineering Economics. Prentice-Hall, 1981.

Frequently asked questions