Rescuing Broken Software

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.