DEV Community

Cover image for Stop Coding! Code is Debt!
Thomas Hansen
Thomas Hansen

Posted on • Originally published at ainiro.io

Stop Coding! Code is Debt!

I once had a manager who wanted me to maintain a project with 1.5 million lines of code. I begged him for more than a year to get to rewrite the project. He never allowed me to do it. His argument was that it had taken 15 years to create, and it had been maintained by 50+ developers over time. In his mind the code was valuable because of the resources he had spent on creating it in the first place, and maintaining it over time. My argument was that this was the reason why the code was worthless.

Code is not an asset, it's a liability. Sometimes it's a necessary liability for us to be able to perform our job, but it's never an asset! On your company's balance sheets we should really write up code as debt, not as an asset. The reasons for this is because code requires maintenance, so it's a future obligation for us to maintain, such that our clients can have working products and we can generate revenue. If we could have generated revenue without code, we'd be much better, because then we've got less future maintenance costs to deliver products that our clients are willing to pay for.

Obsolence

The above project my manager wanted me to maintain was based upon Durandal. This was in 2019, and Durandal had been abandoned by its main developer 11 years earlier. This implied we were stuck with a codebase we had not means to fix bugs in if something was wrong. In addition, Durandal was a brilliant project in 2005, but time had really left it in the stoneage already at that point.

In addition the project was scattered with jQuery and IE6 hacks. In 2019 IE6 didn't exist, at least not as a legitimate problem for the users we were targeting.

On top of this, the project had been maintained by 50+ different developers, each with a different style and knowledge level. The project was also suffering from astronaut architecture, and consisted of 25+ micro services, most of who shouldn't have existed in the first place. To further the insult, the project needed one message broker, but supported 5 different message brokers, because the original architect had demanded it should be portable to everything from Solace to Rabbit MQ.

The project was a hot smoking pile of garbage, and I could probably have completely rewritten it with less than 50,000 lines of code

Extrapolate in Time

40 years ago a cell phone would cost you $15,000, it would weigh 50 pounds, and you'd need to charge it 5 times per day. You could speak in it for maybe 30 minutes before it was out of battery, and it was really quite dysfunctional, and you were better off simply using your landline.

Just because the above phone at some point was valuable, doesn't imply it's valuable today. If you offered me the above phone for free, I'd be like; "Thx bruh, but I'm fine - You keep it!" The same is true for code.

Code that once held value doesn't necessarily have value today. Code that's been maintained by "a bajillion" devs over decades doesn't necessarily require the same resources to create from scratch as required to originally create it in the first place and maintain it over time. Something the above cell phone example clearly illustrates.

By completely rewriting your code, and simply do what I refer to as "SHIFT+DELETE refactoring", you pay back your "debt", and you have a chance at reducing your future debt by 10x, sometimes even more. This is because of that as time passes we find new tools and new ideas that allows us to deliver more for less. Something clearly illustrated in the above video where I reduce 40 hours of work down to 5 seconds.

But by clinging to your code as if it was a living baby you loved more than your own life, you're really clinging on to debt, and you're making your own life much more difficult, and you end up being depressed because of having to maintain something that's the equivalent of a cell phone created in 1989 in 2024.

When it comes to cell phones everybody understands me and agrees with me. When it comes to code, few understands the problem, because the guy who's making the decisions rarely have the capacity to see the code for what is actually is - Which is as follows ...

A hot smoking pile of garbage!

Your code has about the same value as the above dirty rock, and by holding on to code as if it was somehow magically creating value, you're actually just clinging to debt.

Top comments (1)

Collapse
 
dyfet profile image
David Sugar

Emotional attachment can be a strong force. "That" was great code! Yeah, back in 1995 when dinosaurs walked the earth and the internet was still a noisy modem ;). For many things the functional / practical lifespan of code is often far shorter than the emotional lifetime people experience and invest in it. For this reason, I actually like devices more because they tend to have longer practical product lifecycles.