A team declared the old system unmaintainable and began a complete rewrite.
Two years later, they shipped. Within months, developers were calling the new system unmaintainable.
The senior developer mused, “If the disease followed us, perhaps we did not leave it behind.”
Then: “What did we rewrite, the code or ourselves?”
The Teaching Unfolds
There is a particular kind of suffering that software teams know well: the moment a codebase is declared beyond saving. The language shifts. Words like “legacy,” “spaghetti,” and “technical debt” stop being descriptions and become verdicts. The team reaches a consensus that feels almost spiritual in its relief: we will start over. We will do it right this time.
And so the rewrite begins.
The rewrite is one of software development’s oldest rituals, and one of its most seductive. It promises a clean slate — no inherited decisions, no workarounds built on workarounds, no comments that say “do not touch this.” It promises that the problems we have are problems of the code, not problems of us.
But the koan asks us to sit with an uncomfortable observation: the new system became unmaintainable too. And it did so quickly. The team was talented. Their intentions were good. The technology was modern. So what followed them from the old codebase into the new one?
The answer the koan suggests is: the team itself. The habits of communication that produced unclear requirements. The pressure cycles that made shortcuts feel necessary. The unspoken assumptions that never made it into any document. The tendency to optimize for shipping over understanding. These are not artifacts of a programming language or a framework. They are patterns that live in how people think, talk, and make decisions together.
This is not an accusation. It is an invitation. If the code we write is a reflection of how we think and collaborate, then a rewrite without reflection is just transcription. We copy our habits into a new file and call it progress.
The senior developer’s second question is the sharper one: “What did we rewrite, the code or ourselves?”
A rewrite of the code alone is a change of address. The rewrite that matters is slower and less comfortable. It asks: why did this become unmaintainable? Not at the architectural level, though that matters. At the human level. What conversations were not happening? What decisions were being avoided? What did “done” mean to us, and was that definition ever honest?
There is a practice worth trying before any significant refactor or rewrite. Before the first line of new code is written, gather the team not to plan the architecture but to examine the habits. What do we do when requirements are unclear — do we ask, or do we guess? What happens when someone raises a concern late in a sprint — do we engage with it, or do we defer it to the next cycle where it becomes someone else’s problem? What is our actual relationship to documentation, not our stated one?
These are not comfortable questions. They are also not technical questions. But they are the questions that determine whether the next system will be the one your team is proud of in five years, or the one the team after you will want to rewrite.
The koan does not say that rewrites are wrong. Sometimes a codebase genuinely cannot be saved. But it asks us to be honest about what we are actually hoping the rewrite will fix. If the answer is “the code,” that may be true. If the answer, quietly, is “the feeling of working in a difficult system” — that feeling may be worth examining more directly.
Code is a record of decisions. If our decision-making process is unchanged, our code will reflect that, eventually, regardless of how clean the initial architecture was.
The disease the senior developer names is not technical debt. It is unexamined practice. And the good news — the news that makes this a teaching and not just a diagnosis — is that practice can change. But it changes through attention, not through a new repository.