Why Software Eventually Rots and How to Beat the Clock

Software Doesn’t Rust—But It Definitely Rots

In this week’s Commit & Push, we sit down with economist with a background in software engineering Robin Hanson to probe a question most devs feel in their bones but rarely name out loud: Why do big codebases seem to decay no matter how many tickets we close? From the hidden cost of interdependencies to the looming impact of shrinking world populations, Hanson pushes us to zoom out and see software as just one example of a much larger economic story.

Software Rot Is Real—And It’s Not About Bits

Unlike houses eaten by termites, our code doesn’t lose electrons. The rot Hanson describes is structural: every new feature breeds more interdependent parts, making future changes exponentially harder. Eventually, the cost of another patch outweighs the cost of a rewrite—and we scrap the whole thing.

Refactor, Replace, Or Let It Die

We developers love a heroic rewrite. Hanson is skeptical. Total replacement often fails because the live system keeps evolving while the green-field build lags behind. We counter with the “strangler” pattern—incrementally engulfing legacy modules until nothing old remains. Hanson concedes the tactic works, but only delays the inevitable. Very few systems, he argues, survive 40–50 years without a full reboot.

Key takeaway: Whether we nuke the monolith or strangle it, we’re paying the rot tax. The smart play is to time those payments to business reality, not engineering idealism.

Technical Debt vs Rot

Technical debt is the interest we owe for cutting corners today. Rot is the entropy that accrues even when we code clean. Debt can be paid down; rot can only be managed or outlived. That distinction matters, especially for startups racing to product-market fit. Sometimes it’s rational to pile on debt—and accept future rot—because survival today is worth more than perfection tomorrow.