Rescuing Broken Software
Diagnosing, stabilising, and finishing a project that stopped working
A failing project is diagnosed, not restarted: establish facts, stop the bleeding, build a safety net, and renegotiate scope with the business before touching architecture, because the schedule is usually the actual defect.
Walking into a stalled delivery, the temptation is to form an opinion in the first hour and rebuild in the first week. Both are mistakes. This book runs the order that works: reconstruct the real state from the repository, the incident record and the deploy history; stabilise before improving; build a characterisation test net around the paths the business depends on; decide rewrite, refactor or replace with a defensible reason; and renegotiate the schedule before touching the architecture. It ends where a rescue should — with a team that can run the thing without you.
Written for: Founders and leaders with a delivery that has stalled, and the engineers walking into it.
3 of 12 chapters published. The rest go live as they are written.
What it makes operable
Outcomes, not topic coverage.
- 01Establish the actual state of a delivery within the first week
- 02Stabilise and build a retroactive test net before changing the design
- 03Decide rewrite, refactor or replace with a reason you can defend
- 04Sequence repairs without freezing delivery, then hand ownership back
Complete contents
12 chapters, in order.
Each chapter settles one decision, so it can be read on its own. Read in sequence to build the argument the book is making.
- 01
What "Broken" Usually Means
Separating a technical failure from a schedule, scope or ownership failure.
- 02
The First Week: Establishing Facts
Reconstructing the real state from the repo, the incidents and the deploy history.
- 03
Reading a Codebase You Did Not Write
Finding the domain logic, and the decisions nobody wrote down.
- 04In writing
Stability Before Features
Stopping the bleeding, and resisting the pressure to keep shipping through it.
- 05In writing
Building a Test Safety Net Retroactively
Characterisation tests around the paths the business actually depends on.
- 06In writing
Rewrite, Refactor, or Replace
A time-boxed assessment with an honest threshold for each option.
- 07In writing
Renegotiating Scope With the Business
Presenting the trade so the schedule stops being the defect.
- 08In writing
Working With the Team That Built It
Getting the truth from people who expect to be blamed for it.
- 09In writing
Sequencing Repairs Without Freezing Delivery
Interleaving repair and delivery so neither one stops.
- 10In writing
Restoring Deployability
Getting back to a release you would be willing to perform on a Tuesday.
- 11In writing
Handing Back Ownership and Documentation
Leaving a team able to operate the system without you in the room.
- 12In writing
Preventing the Next One
The early signals that predicted this, and the controls that catch them.
Evidence
What this book is arguing against.
Third-party sources behind the book's premise. Every figure in them belongs to the party that published it and is attributed to them in the text.
- AI Project Failure Statistics 2026: The Complete Picture
Pertama Partners · 2026-02-08 · Industry report · reported
- Legacy Code Modernization with AI Agents (2026)
Tembo · 2026-06-18 · Vendor engineering · reported
- AI Can Migrate Code. Who Validates That the Business Still Works?
Abstracta · 2026-06-11 · Industry report · reported
Continue through the library
Adjacent operating manuals.
The Software Engineer's Career Handbook
Career advice written against the old ladder tells you to get faster at producing code, which is the part that stopped being scarce. This book is written against the shift instead: what is actually rare now, how to build comprehension and specification as deliberate skills, how to work with agents without losing the ability you would need without them, and how to choose problems, companies and forms of leverage that make judgement compound rather than depreciate.
Read the full book
Agents That Finish
Frontier models are close to perfect on work a skilled person would finish in four minutes and close to useless on work that takes four hours. The gap is not intelligence. It is that most agent architectures cannot notice a wrong intermediate state, let alone roll one back, so the first bad commitment is inherited by every step after it. This book builds outwards from that failure mode: decomposition as a real artifact, verification between steps, checkpoints an agent can resume from, compensating actions for effects that already left the system, and budgets that bound the damage when none of it works.
Read the full book