Why Software Fails
Charette compiles a catalogue of the largest software disasters in history — Denver's airport baggage system, the IRS modernisation, the FBI Virtual Case File — and extracts the structural reasons behind them.
Most failures are not technical: they are failures of scope, communication, governance and the political will to stop when stopping is the right answer.
For product direction the piece is diagnostic training; reading it next to any project plan changes which questions you ask first.
A useful complement to Royce's paper: Royce warned against linear development, Charette shows what happens when the warning goes unheeded.
The reporting is dry, the conclusions are not.
Central argument
Charette argues that large-scale software failures — drawing on cases like Denver International Airport's baggage system, the IRS modernisation effort, and the FBI's Virtual Case File — are not primarily caused by technical inadequacy but by failures in scope management, governance, communication, and the political inability to cancel projects that should be stopped. The central finding is structural: the conditions that produce catastrophic software failure are organisational and managerial, which means they are predictable and, in principle, preventable. Charette's implicit thesis is that the industry keeps relearning the same lessons because the incentive structures that cause failure are more durable than the post-mortems written about them.
Critique
The piece's core limitation is selection bias toward spectacular, high-visibility public-sector failures, which may not generalise cleanly to commercial software development where market feedback, shorter cycles, and different accountability structures change the failure dynamics considerably. Government IT projects operate under procurement constraints, political visibility, and contractual rigidities that private product teams rarely face at the same intensity, so some of Charette's structural diagnoses risk being mistaken for universal laws when they may be contextually specific. A thoughtful reader might also note that the article, published in 2005, predates widespread agile adoption and the DevOps movement, leaving open the question of whether its conclusions remain equally valid in delivery environments built around iteration and early failure.
Why it matters for product
For a product leader, Charette's catalogue functions as a checklist of governance failures: the cases consistently show that someone knew the project was in trouble long before the public reckoning, but lacked either the authority or the political cover to act. This maps directly onto the challenge of maintaining an honest roadmap — the pressure to preserve stakeholder confidence often produces the same silence that Charette documents in federal contractors. The piece also sharpens how to read scope: when a project cannot be stopped despite clear signals, it is rarely a delivery problem; it is an organisational design problem about who holds the power to name failure and on what terms.