The cost of not deleting code

Through the years, I've stumbled across thousands of lines of unused code of all kinds. It might have been nice, well tested, neatly architected code fitting perfectly into all the tools, frameworks and standards for its time. But in the end, it was never called.

Maybe the feature was discontinued. The client code that called this feature on the server was removed. But the server side code was left in place. Maybe the team forgot to remove it. Maybe it was decided that it might be required for the future. Maybe there was no time for it, since new features had to be released the next Wednesday.

Bug fixing costs

Lots of books and web-literature discusses how the cost of fixing bugs exponentially increases in different phases.

If you see an error while initially implementing a feature, it'll take you seconds to fix it. Add a minute, and you can write a test to make sure it never happens again. Sometimes, even this minute seems excessive.

Or you can let it slip all the way through to production, where it actually causes real life problems. Maybe support staff is contacted. Maybe several developers are involved. Maybe revenue losses occur. Maybe regulatory issues arise. Maybe tens of work hours are wasted, until someone spots that faulty regex or that misspelled word.

That minute for writing a test suddenly seems extremely cheap.

Dead code costs

Adjacent to this, lies the cost of maintaining dead code. If you refactor code, you might end up adapting the dead code for your changes, believing it is still in use. You may rewrite tests. You may notice that things are a bit off, and then refactor the dead code too, so it fits the new style better. And then you notice the frameworks it uses are outdated, so you update those too. Then you get comments during some form of review, telling you to fix a few small mistakes. Back and forth.

All that for code that'll never be called in production.

You might not even know that it's not in use, because you're new to the team. Maybe nobody told you the feature isn't in use anymore. Maybe there's no usage statistics telling you the endpoint is never called.

The amount of dead code may be substantial, and will, over time, add up. Developer-time is expensive, so you should prefer using it efficiently. As do the developers. It's not fun to notice those eight hours you spent making the code really sleek was for nothing. I don't think I exaggerate if I say the team I'm currently working on has spent hundreds, if not thousands, of hours combined over the years just maintaining dead code - refactoring, pull requests, discussions, adjacent issues,  build time, testing etc.

That minute for removing the code right away suddenly seems extremely cheap.

Existing code costs

Simply having a large code base has inherent costs. Cognitive load. Time to learn it well enough to work efficiently. Build and deploy-times. Time to test. Review time. Discussion time. Architecture choices.

More code takes more skill or experience to neatly divide into logical chunks. Adding new code to a large code base is likely more complex than to add it to a brand new, empty repository.

Not removing dead code, amplifies all this. And so even if you continuously ignore the dead code, or pretend it's still alive, it'll still cost. Even if you never change a single byte in it, it'll still make every other new feature slower to implement. And every build slower. And possibly, you'll hit a wall at some point.

Maybe that one new feature just can't be added due to that dead code, for some reason. Maybe your most experienced developers quit, for whatever reason. Maybe every new feature takes weeks of research to be sure it'll be possible to implement safely. Maybe you start losing customers because your app is stuck in the past, and your competition is running circles around you. Maybe you'll have to hire more developers to cope with the sheer amount of code that needs maintenance.

That minute for removing the code right away suddenly seems extremely cheap.