Respecting What Came Before
A working system is a record of problems someone already solved
About three years ago I wrote a post in response to the internet noise and the micro-service vs monolith armies around an article from the Prime Video team. Most of it was about that specific storm, but one idea in it kept coming up in my work ever since. I thought it would be good to pull it out on its own because AI made it even more relevant today.
Legacy is a word the industry often uses in a disparaging way. People say a particular system is legacy the way they would call it a burden, something old, outdated, and awkward that a braver engineering team would have replaced by now. I have sat in a lot of meetings where that word was used as a weapon, pretending it was a solid argument in a conversation, and almost none of it was fair. I have watched a team call a system legacy because it simply was old. I have watched them call it legacy because they had not written the code themselves. I have watched them call it legacy because the technology it ran on would do nothing for their CV.
But a system that has been running for years is not a burden. It is a record of problems that have already been solved. Every strange branch in the code, every workaround, every setting nobody wants to touch, is usually there because something went wrong once and someone fixed it. The system carries that history whether or not anyone remembers it. And most of what keeps it running was never written down anywhere.
The engineers who built it were not working with what you know now. They had the requirements, the deadlines, and the tools of their time, and they made the best call they could inside those constraints. From where you sit now, with the incident report in hand, the old decision can look obviously wrong. Everyone is an expert with the virtue of hindsight. It rarely was. It made sense from the inside, to people who could not see their future any better than you can see yours. Have you ever made a call that looked obvious and wrong a year later? I have, more than once.
This is the same mistake we make when we blame an operator after an incident. We take the messy, uncertain situation they were actually in, swap it for the clean version we can see afterwards, and then judge them for not acting on information they never had. Judging the engineers who came before you is the same move, stretched over years instead of minutes. The system looks wrong now because you know how the story turned out. They did not.
There is an old idea called Chesterton’s fence, after the writer G. K. Chesterton, who wrote it down almost a hundred years ago. If you encounter a fence and do not see its purpose, that is not proof that it has no purpose, it may be there for a reason you have not found yet. Old systems are full of fences. The retry count that looks too high, the timeout set to some oddly specific number, the feature flag nobody dares turn off. You find yourself wondering “Why that decision, and not another?” more often than not. But someone probably found out the hard way. Before you rip any of it out, you owe it the small effort of finding out what it was protecting against, because it was almost certainly protecting against something.
A running system is also full of work you cannot see. Not the architecture diagrams or the documentation, the work that actually happens: the manual step someone does every release, the alert everyone knows to ignore, the order things have to start in that nobody documented. That is the real running system, the one that has been adapting to the reality of production for years while the documentation froze in time. A rewrite starts from the clean picture and deletes all of it, and you find out which parts mattered one at a time, in production, at the expense of your customers.
All of this used to be held back by how expensive it was to start over. Rewriting a working system was slow and costly, so most of the time we lived with what we had. That brake is coming off. AI makes it cheap to regenerate large parts of a system on a whim, and the whole pitch is that you no longer need to understand the old thing, you just point the AI at it and it rebuilds it. But going slowly did one useful thing. It forced someone to understand the system before they were allowed to replace it. Make the rewrite free and you still have to understand the system. You have just removed the step that used to make someone do it.
Respecting what came before does not mean you need to keep old systems forever, things do need to be replaced, and plenty of legacy deserves to go, but it is about the order of operations. Understand why the thing exists and what it is holding up before you decide it is worthless, and assume the people before you were not idiots, because they usually were not. The system you call legacy already answers problems you have not run into yet. Throw it away without understanding it and you will replay the same music your predecessors have played all along.
By the way, we often do the same thing with people. A culture that prizes whatever is newest tends to read age as obsolescence, and it pushes its oldest people just when their judgement is worth the most. What gets lost is the same in both cases, the knowledge that was never written down, and it goes with the thing you decided you had outgrown.
//Adrian