The last two per cent

Anyone who has built something will recognise the shape of the problem. The system works. It handles the ordinary case cleanly, the demonstration goes well, and everybody agrees it is nearly finished. Then it takes as long again to finish as it took to build.

The reason is that the remaining work is not a smaller version of the work already done. It is a different kind of work. What remains is the set of cases that do not fit: the user whose name contains a character the form rejects, the date that falls on the one day a year the calculation assumes cannot happen, the network that disconnects halfway through rather than at either end. Each is rare. There are a great many of them, and rare events are common in aggregate.

There is a second reason, less often admitted. The pleasant part of building is the part where progress is visible. Handling the awkward cases produces no visible change — the system does what it already appeared to do, only now it genuinely does it. An engineer who spends a week on this has nothing to show, and a project manager looking at demonstrations sees a week where nothing happened.

Mature teams plan for this explicitly. They treat the demonstration as roughly the midpoint rather than the end, and they resist the temptation to schedule the launch from the date the happy path first worked.

The discipline this requires is mostly honesty about what 'working' means. A system that works when everything goes right is not a working system. It is a demonstration of one.