The Root Causes of Software Rework
Updated 17 April 2026
Capers Jones' research across thousands of software projects consistently identifies four systemic causes that account for the vast majority of rework. Understanding which one is your team's primary driver is the first step toward reducing it. Each cause has a dedicated page with evidence, specific failure modes, and a prevention playbook.
Unclear Requirements
The most expensive source
Requirements defects account for approximately 45% of total rework cost. Ambiguous acceptance criteria, unstated non-functional requirements, and scope creep cause rework at every downstream stage. Capers Jones data shows requirements-origin defects are discovered latest and therefore carry the highest 1-10-100 multiplier.
Poor Testing
The escape-rate problem
Bugs that escape to production cost 5-100x more than those caught in development. DORA 2024 shows elite teams maintain change failure rates below 5%; low performers exceed 30%. The test pyramid (unit, integration, E2E) and the shift-left principle are the primary defences.
Technical Debt
The rework multiplier
Technical debt increases the cost of every future change. Stripe research found developers lose 17.3 hours per week to bad code. High debt raises defect density and slows every rework event. The debt-rework compounding effect means unmanaged debt causes exponential rework growth over time.
Miscommunication
The invisible rework source
Conway's Law: system design mirrors communication structure. Communication gaps between teams, between product and engineering, and across time zones become architectural defects and spec failures. Remote and hybrid teams show higher incidence. The prevention playbook focuses on async-first communication, ADRs, and runbooks.
After identifying your root cause: