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; decide between repairing, wrapping, replacing, rewriting and archiving before spending a month on any of them; stabilise before improving; build a characterisation test net around the paths the business depends on; and renegotiate the schedule before touching the architecture. It ends where a rescue should, with a team that can run the thing without you.
What it makes operable
- 01
Establish the actual state of a delivery within the first week
- 02
Choose between repair, wrap, replace, rewrite and archive with a reason you can defend
- 03
Stabilise and build a retroactive test net before changing the design
- 04
Sequence repairs without freezing delivery, then hand ownership back
Contents
12 of 12 published
Every chapter is free to read in the browser, cites its own sources, and stands on its own if you came for one decision rather than the whole argument.
- 01What "Broken" Usually MeansSeparating a technical failure from a schedule, scope or ownership failure.13 min
- 02The First Week: Establishing FactsReconstructing the real state from the repo, the incidents and the deploy history.13 min
- 03Reading a Codebase You Did Not WriteFinding the domain logic, and the decisions nobody wrote down.14 min
- 04Repair, Wrap, Replace, Rewrite, or ArchiveA time-boxed assessment with an honest threshold for each of the five outcomes.13 min
- 05Stability Before FeaturesStopping the bleeding, and resisting the pressure to keep shipping through it.12 min
- 06Building a Test Safety Net RetroactivelyCharacterisation tests around the paths the business actually depends on.11 min
- 07Renegotiating Scope With the BusinessPresenting the trade so the schedule stops being the defect.11 min
- 08Working With the Team That Built ItGetting the truth from people who expect to be blamed for it.11 min
- 09Sequencing Repairs Without Freezing DeliveryInterleaving repair and delivery so neither one stops.11 min
- 10Restoring DeployabilityGetting back to a release you would be willing to perform on a Tuesday.11 min
- 11Handing Back Ownership and DocumentationLeaving a team able to operate the system without you in the room.11 min
- 12Preventing the Next OneThe early signals that predicted this, and the controls that catch them.11 min
Evidence · 3 sources
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.
In the age of AI
The advantage was never the model. It's knowing what to build with it — and having a team that can actually ship it.
That's the part I help with: finding where AI genuinely makes your business faster, deciding what's worth building, and standing behind it once it's live.
Four offices, one very full passport
Every dot on this map is a conversation I still remember.
- Where I've spoken
- Office
