Every time I've rebuilt a system I understood well, the second version came out smaller than the first. Less code, fewer files, fewer special cases. This surprised me the first few times. Now I expect it, and when a rewrite comes out bigger, I treat it as a warning sign.
The clearest case I remember was a billing module. The first version ran around 2,000 lines, full of branches for edge cases we thought we'd hit. The rebuild, done two years later by someone who'd supported the original in production, came in near 700 lines and handled more real scenarios. Nothing clever happened. We just finally knew which branches were fiction.
The first version is mostly guessing
The first time you build something, you don't fully know what it needs to do. You know what you were told, and you know what you can imagine, but you don't know what's real yet.
So you hedge. You add a config flag because someone might want to turn this off. You add an abstraction because there might be a second case someday. You handle an input that can't actually happen, because you aren't certain it can't. Every one of these is a reasonable bet made under uncertainty.
A year later, most of those bets have resolved. The config flag was never flipped. The second case never came. The impossible input stayed impossible. All that code is still there, still maintained, still confusing the next person, and all of it is compensation for uncertainty that no longer exists.
Understanding is what shrinks it
The second version is smaller because you're building with answers instead of guesses. You know which cases are real. You know which flags mattered. You know the actual shape of the data because you watched it move through production for a year.
This is why I'm careful about who should rewrite something. The person who understands the current system deeply will make it smaller. The person who just finds it ugly will make it bigger, because they'll re-add every hedge from scratch under the same uncertainty the first author had.
There's a trap worth naming. Ugliness and complexity look the same from the outside. A senior engineer learns to ask whether an ugly piece of code is bad, or ugly because the problem is genuinely messy and the code is being honest about it. Those two need opposite treatments.
Before anyone rebuilds a component at Shanti Infosoft, the first question is whether we understand why the current one is shaped the way it is. If we can't explain the weird parts, we aren't ready to replace them. The weird parts are usually load-bearing.
Smaller is the evidence, not the goal
I want to be careful here. Small code isn't automatically good code. You can compress something until nobody can read it, and that's worse than the verbose version. Shrinking isn't the target.
Smaller is the symptom of understanding. When the second version comes out dramatically simpler, it usually means we finally understood the problem. When it comes out bigger and more clever, it usually means we didn't, and we hid that from ourselves behind abstraction.
So I don't chase line count. I chase understanding, and I read the line count as a signal for whether we got there.
That's really a governance point, and we made the fuller argument in why writing code was never the bottleneck.
When you last rebuilt something, did it come out smaller, and if it didn't, are you sure you understood the original?
Top comments (0)