A picture first.
On 26 October 1992, the London Ambulance Service put a new computer-aided despatch (CAD) system live across the city. Paper backups were removed. Controllers were told to lean on computer-generated allocations. The system was supposed to be faster and more accurate — within hours it drowned in delays, duplicate dispatches, and scrolling exception messages.
It wasn’t a simple “the computer crashed.” The official inquiry was blunt: the software was incomplete and under-tested; hardware resilience under full load hadn’t been proven; fallback to a second server hadn’t been tested; vehicle status and location data were unreliable; staff weren’t fully trained; and the control-room layout changed the same day, making mutual cover harder. Technically the system often “did what it was designed to do” — but the design assumed near-perfect live data. The real world doesn’t. Imperfections stacked until the service failed as a system. Semi-manual workarounds returned; around 4 November the system locked up for good.
Three reminders for anyone shipping software — or agents — into the real world:
💡 “Demo-ready” ≠ “production-ready.” Green checks in a demo don’t survive dirty data and peak load.
💡 Fallback is a feature. An untested rollback is no rollback. Paper backup, human override, and degrade modes are product, not afterthoughts.
💡 Automation must not erase judgment. When data goes bad, “more automatic” means “wrong faster.” Keep confirmation and override in the design.
Ever lived through a go-live that went sideways? Drop a lesson in the comments — not to scare, but to ship safer next time.
Top comments (0)