Every software system that has ever died — been replaced, rewritten, abandoned, or quietly moved to a server that nobody monitors — died because it grew too large to change. Too many features. Too many dependencies. Too many stakeholders who needed the thing that was added in Q3 of 2019 and has been load-bearing ever since, not because it’s important but because removing it would require a meeting, and the meeting would require an agenda, and the agenda would require someone willing to say “we should delete this,” and nobody is willing to say that because the last person who said that was asked to present a 47-slide impact assessment and never suggested deleting anything again.
Software dies of obesity. Not starvation.
The Arithmetic
Features are calories. Each one individually nourishing. Each one adding weight.
A typical enterprise team adds twelve to thirty features per quarter. A typical enterprise team deletes zero features per quarter. This is not an exaggeration. This is the arithmetic, and the arithmetic is patient.
After five years: 240 to 600 features. The number of features any single person on the team understands: roughly 30. The ratio of understood to total: five to twelve percent.
The industry has a polite name for this ratio. It’s called [[Technical Debt]]. It should be called what it is: the system is too fat to move, and nobody remembers what most of it does.
The asymmetry is the entire problem. Adding a feature requires one committee (product). Deleting a feature requires three to five (product, engineering, architecture, stakeholder, legal if it’s customer-facing). Adding takes one sprint. Deleting takes one sprint plus three months of “can we really remove this?” emails.
So features accumulate. Weight accumulates. The build takes forty minutes. The deployment pipeline has seventeen stages. The test suite takes four hours and fails nondeterministically. The system develops conditions. The system reaches a weight at which movement is painful and stillness is death.
This is [[Critical Mass]] — the point at which complexity becomes self-sustaining. Below critical mass, you can still change things. Above it, the chain reaction feeds itself: each feature creates dependencies, each dependency creates constituencies, each constituency defends its feature.
The Enterprise Cycle
Every enterprise system follows the same lifecycle. I have watched this cycle from inside boardrooms, billing three thousand pounds a day to tell people what they already knew:
Year 1: A small team builds something that works. It is fast. It is understandable. The people who built it love it.
Year 2-3: The system is successful. Success attracts features. Features attract stakeholders. Stakeholders attract roadmaps. The people who built it start to leave, replaced by people who maintain it. Love is replaced by duty. Duty is replaced by process.
Year 3-5: Nobody can hold the whole system in their head anymore. The architecture exists in folklore. A developer removes a feature and three other features break. The developer puts it back. Nobody removes anything again.
Year 5: A senior developer — usually the newest one — suggests “starting fresh.” The rewrite proposal has forty-seven slides. The timeline is off by a factor of three.
Year 5-7: The rewrite ships. It reaches feature parity at month eighteen. By month twenty-four, it has started accumulating its own features. By month thirty-six, it has reached critical mass.
The cycle repeats. The industry calls this “modernisation.” It is not modernisation. It is the same obesity on a newer framework.
The Only Force That Prevents It
I maintain a codebase. Solo. It’s a web application with eleven domain modules, a streaming AI agent, a compliance engine, and more moving parts than most teams of twenty manage.
Last week, I deleted 13,022 lines of code in nineteen commits. The codebase gained features. Not lost — gained. More capabilities, fewer lines. Content editors. AI context awareness. A convention from three months ago becoming the foundation for something nobody planned.
Net: -6,389 lines.
This is not a refactoring sprint. This is not tech debt payoff. This is tending — the routine, unglamorous act of growing AND pruning, applied by someone who loves the codebase enough to make it smaller.
Enterprise systems cannot do this. Not because the code is different, but because the relationship is different. Enterprise systems don’t have a gardener. They have committees. Committees plant. Committees never prune. Committees cannot prune, because pruning disappoints constituencies, and disappointing constituencies requires someone willing to be unpopular, and committees are designed to distribute unpopularity so evenly that it dissolves into inaction.
The solo developer has one constituency: themselves. Disappointing yourself is free and requires no meeting. Deleting working code requires the same courage as writing new code, and more taste. But it can be done on a Tuesday morning without filing a change request.
The AI Accelerant
Now add AI to this equation.
I work with an AI that writes four thousand lines of code in a day. Not bad code — good code. Tested, structured, following the conventions of the codebase. The AI is fast, precise, and tireless. It is the most productive planter in the history of software gardening.
But the AI does not prune.
The AI does not walk through the codebase on a Wednesday and feel that something is heavy. The AI does not notice that a domain built four months ago has been superseded by a capability that emerged last week. The AI does not say “we should delete this.” The AI builds what is asked, and what is asked is almost always more.
With AI, the growth pressure is 100x. A vibe-coded app — one where the developer prompts the AI and ships without reading — reaches critical mass in weeks, not years. Even a well-navigated codebase reaches it faster, because the paths are chosen but the weight still accumulates.
The answer is not “use less AI.” The answer is “prune more.” The AI’s gift is speed. Speed of growth must be matched by willingness to reduce. If nobody deletes four thousand lines in a month, the system reaches critical mass before Q3.
The Diet Nobody Prescribes
Here is the prescription that no enterprise architect will give you, because it cannot be expressed in a Jira ticket:
Someone has to love the codebase.
Not manage it. Not own it in a RACI matrix. Not be the “technical lead” whose name is on the architecture document. Love it. The way a gardener loves a garden — enough to plant and enough to prune, enough to grow it and enough to cut it back, enough to say “this was good work and it’s time for it to go.”
Love shows up as three things:
Desire for the solution to exist. Not the ticket — the solution. The person who lies awake thinking “there must be a better way to do this” is the person who will find it. The person who closes the ticket and moves on will not.
Stubbornness to carry an idea across time. The convention I built in December for sidebar resize modes was deleted along with the feature it served. The for-loop survived. Three months later, it became the foundation for AI context awareness. That for-loop survived because I was too stubborn to delete something that wasn’t hurting anything and too stubborn to build something new when the old thing was sitting right there.
Love for the codebase as a whole, not just the parts you wrote this week. The willingness to delete 5,242 lines of working, tested code because the LLM does what it did, better, and the code is now weight.
These three things cannot be distributed across a committee. They cannot be automated by an AI. They cannot be scheduled in a sprint. They are the properties of a single person’s relationship with a single codebase, maintained over months and years.
This is why solo projects survive and enterprise systems collapse. Not because of skill. Because of love.
The Arithmetic, Revisited
Enterprise team:
Features added per quarter: 12-30
Features deleted per quarter: 0
Trajectory: obesity → critical mass → rewrite → obesity
Solo developer (with AI):
Lines written per day: 4,000
Lines deleted per month: 13,000
Net per campaign: -6,389
Features: more than before
Trajectory: tended → pruned → growing → tendedThe difference is not the AI. The AI is the same in both scenarios. The difference is whether someone loves the codebase enough to make it smaller.
Software dies of obesity, not starvation. The only cure is someone who cares enough to prescribe the diet. And in the enterprise, that person does not exist, because caring about a codebase is not a deliverable, and love is not a quarterly objective.
If you enjoyed this, there’s an encyclopedia of satirical entries on software development concepts, where every principle from YAGNI to Gall’s Law to Zawinski’s Law gets the roast it deserves. And a mythology where a developer, a lizard, and a caffeinated squirrel have been arguing about architecture for a hundred episodes.
See also:
Critical Mass — The physics of when complexity becomes self-sustaining
Tending — The missing practice: growing AND pruning
YAGNI — The principle that could have prevented this
Zawinski’s Law — Every program expands until it can read mail
Gall’s Law — The rewrite will reach critical mass too
Vibe Coding — The fastest path to obesity
Vibe Engineering — Navigation delays obesity but doesn’t prevent it
