All Code Must Die
Tags: webdev, programming, php
Published: 2023-08-21 18:45:27

Contrary to the popular phrases ‘future proof’ etc it is my opinion that all code must die. Now what do I mean when I say all code must die? All code is out of date the minute it is written, because of that all code ideas though good at the moment are unable to predict the future and thusly cannot stay relevant for very long. Businesses change and grow with time, and code that may have fit the part in 2004 does not service the company in 2014. You cannot expect a hack job on a WordPress site to maintain its value. Code itself degrades in value from day one of writing, therefore what you had written in 2004 is likely dead by 2008. Lets look at some more details on why.

##### Degradation of Code Quality

From the minute code is committed its out of date. Similar to how a car is made the minute it drives off the lot it begins to degrade in value. Code is the same in the sense that, when it is released it (hopefully) works and solves a distinct problem. But when the environment around it changes it needs to change to keep up. This means that every minute of everyday as the environment of code from quality, to patterns, to servers, to number of developers in the universe changes the code must change to keep up. the further it lags behind the further it degrades. It seems to me that businesses view code as a child. You invest in it early and it takes care of itself in the long run, and can fund you in the future. However, I am trying to express that code is like a child who never grows up. Your code will never become an adult because the minute it does the environment grows up around it and it becomes a child all over again. Its age is relative to its environment not to a global time scale.

##### Changing Business

Companies grow and shrink and their demands change with that. You cannot expect a company of 5 employees to be serviced by the same code base that 100 employees need to work with or on. And if they do use the same software lets say for example GitHub, the practices around how it is used with 5 employees vs 100 will be very different. Yet we see companies trying to maintain and enhance old code bases rather than letting their 9 year old code die, and be reborn in a new form.

##### New and Old Developers

I do not mean young and old I mean new and old, as in the developers who have been with the company for 8 years vs the developers who have been with the company 4 weeks. Aging code maintained for the sake of fear of rebuilding can easily cause a rift between these two groups, which would in turn degrade the future code that they develop. Maintaining old patterns, or code styles simply gets in the way of the fresh minds who want to solve the problem in a new way. It also binds the old developers to the old ways of thinking as they must remain focused on that school of thought not being able to look forward. This in turns continues to degrade the code base as it then ends up with random new architectures inside it, which only cause confusion down the road.

##### What is Death?

All code should die. All websites, apps (mobile, web) whatever platform, operating systems etc, all of them should die at some point or another. What do I mean by die? Should I just delete it all? …. Yes. Restart the whole thing knowing what your team knows now and you will have a great product that could enjoy at best a 4 – 5 year life cycle. We go though Presidents and Prime Ministers before we’re willing to let go of a code base. The best investment a company can make is in its attitude toward its software. Accept that what is written today ought to be fully rewritten within four years. Even if your code is so lean it only has 5 lines. Those five lines today do not have the same value or relevance five years from today. Accept it that code itself has the shortest life span in your company’s assets. You will have the same desks and chairs and walls but you will need to give new life to your code.

Don’t waste time bringing the old up to date, rather say goodbye when you need to, and build it all over again. Erase the tech debt, erase the management debt, let it go, and make it new.