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.
- 01 What "Broken" Usually Means Separating a technical failure from a schedule, scope or ownership failure. 13 min
- 02 The First Week: Establishing Facts Reconstructing the real state from the repo, the incidents and the deploy history. 13 min
- 03 Reading a Codebase You Did Not Write Finding the domain logic, and the decisions nobody wrote down. 13 min
- 04 Repair, Wrap, Replace, Rewrite, or Archive A time-boxed assessment with an honest threshold for each of the five outcomes. 12 min
- 05 Stability Before Features Stopping the bleeding, and resisting the pressure to keep shipping through it. 11 min
- 06 Building a Test Safety Net Retroactively Characterisation tests around the paths the business actually depends on. 10 min
- 07 Renegotiating Scope With the Business Presenting the trade so the schedule stops being the defect. 11 min
- 08 Working With the Team That Built It Getting the truth from people who expect to be blamed for it. 10 min
- 09 Sequencing Repairs Without Freezing Delivery Interleaving repair and delivery so neither one stops. 10 min
- 10 Restoring Deployability Getting back to a release you would be willing to perform on a Tuesday. 10 min
- 11 Handing Back Ownership and Documentation Leaving a team able to operate the system without you in the room. 10 min
- 12 Preventing the Next One The early signals that predicted this, and the controls that catch them. 10 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.
