Legacy was inevitable
Legacy systems are treated as evidence of past incompetence. They are what rational decisions look like after twenty years of bad options.
Stop assigning blame
The standard reading of a legacy environment is that somebody screwed up. The IT manager who bought the wrong ERP, the consultants who billed for the integration that never stabilized, the vendor who promised a roadmap and shipped a rebrand. Pick a villain and the mess explains itself.
The reading is wrong. Companies bought what existed. Consultants recommended what they had seen work. Vendors built what could be profitably sold to many customers at once. Every actor optimized honestly inside the constraints they had — and the aggregate result was still fragmentation, everywhere, in every industry.
When every participant acts rationally and the outcome is still bad, the fault is not in the participants. It is in the option set.
The two roads
For most of the software era there were exactly two realistic ways to get a system. Buy standardized software: fast, affordable, and built for the average company in your industry — which your company is not. Or build custom: shaped to you, and so expensive, slow and risky that only large enterprises could seriously attempt it.
The buy road produced the familiar collection of isolated products, each an approximate fit, each with its own copy of the customer table. The build road produced something rarer and stranger: a system that fit perfectly on delivery day and then froze, because the team that understood it moved on and every change carried consultant rates and regression risk.
Most companies mixed both roads and got both failure modes.
Why build was worse than it looked
The custom system's deepest problem was never the build cost, painful as it was. It was what happened after. Software shaped to a business must keep changing as the business changes, and handcrafted systems made every change a project. So the changes stopped, quietly, and the system that was once the company's proudest asset became the thing nobody dares touch.
Every mid-sized company has met one: the order system from 2004 that still runs the warehouse, maintained by one semi-retired developer, feared by everyone else. It is not there because someone was stupid. It is there because it worked, and changing it stopped being economically defensible years ago.
The debt was structural
Technical debt is usually described as the residue of shortcuts. Across a whole economy it is better described as interest on decisions that were correct at the time. The company that bought the standard package in 2008 was right to. The one that built custom in 2012 was right to. The debt accumulated anyway, because both options charged it — just on different schedules.
Surely some of it really was incompetence — failed projects, bad vendors, careless integrations. Of course. But incompetence explains individual failures. It does not explain the same pattern repeating across every sector, every geography and every company size for thirty years. Only economics explains that.
Why this matters now
If legacy were the product of bad decisions, the cure would be better decision makers, and the last three decades show how well that works. But if legacy is the product of economics, then changed economics change everything — the same rational actors, facing a new option set, produce a different outcome.
That is exactly the claim of the principles that follow. And it has a sharp corollary for anyone building software today: systems assembled without a platform underneath them are still walking the old build road, and it still ends in the same place.
Nobody needs to be smarter this time. The options need to be better, and they are.
Why systems fail to become platforms