Code Lifespan: Identifying Software On Its Last Legs

From the moment you deploy your digital product, whatever it may be, the timer starts ticking down on the code’s lifespan. The depreciation of code is an inevitable fact that all CTOs have to consider. It is part of the parcel in the product development lifecycle.

Identifying problems and being prepared to keep your digital property working efficiently is central to your role. However, it is often difficult to predict the future and know what transformations it will have to endure, and how long it will have to endure them before it has to be completely overhauled.  We’ve got you covered in this blog post.

What is your product’s purpose?

To begin to answer the question, it is perhaps most obvious to start with looking at the purpose of the product. Even when you are initially developing the source code for your product you will have an idea (or been explicitly told from higher up) of how long it is expected to last.

For example, mobile phones are an example of tech which moves at a rapid pace, constantly evolving at a dizzying speed. We make one rotation around the sun and then there’s a new kid on the block kicking the older technology to the curb.

Companies like Apple capitalise on this with their extensive R&D to keep things moving quickly and purposefully deprecating their code. It also why mobile apps are so volatile. They often come and go on iOS in particular because developers simply cannot keep up with the pace of change, as older code is removed from the API.

“Understanding the purpose of your product is central to ensuring it doesn’t cause massive headaches further along the line.”

In other cases, the need for change will have absolutely no relationship to the condition of your code. For example, compare how websites look now vs. 5 years ago. The reason behind this is shifting UI and design trends. If your business needs to keep a fresh face in line with competitors, the directors aren’t going to spare a thought for your code.

At the other end of the spectrum, there are web applications. Websites, online portals and databases are built to stand the test of time because frankly, they must. They have longer lifecycles because they are more complex structures. Ultimately, this means there is a reduced focus on iterating to avoid destabilising the functionality of the product. Think of public services web applications like government portals or social housing services.

Understanding the purpose of your product is central to ensuring it doesn’t cause massive headaches further along the line. That’s why we run in-depth Discovery Workshops with our clients to get to fully comprehend the features and work required to make the project a long-term success.

The Half-Life of Code

An interesting consideration to take into account is the concept of the half-life of your code. It’s good to understand how this affects your bottom line and what the implications are for your code. Dan North defines this as:

“The amount of time required for half of an application's code to change so much that it becomes unrecognizable.”

The reality of programming is you spend more time reading code than you do writing it. So keeping your code simple and easy to read is optimum. The idea behind monitoring the half-life of your code is that you can keep it as up-to-date and accurate as possible. Simply, you want to keep it short.

In a perfect world, you would have all the time you need to ensure this was the case, but you will know that this fantasy realm doesn’t exist and countless other problems demand your time and attention.

Sandi Metz says “Here's where the concept of half-life matters. You can lower your costs by reducing the half-life of your least stable code.” He argues that the dynamic code that changes the most also costs the most. These elements are often the most important to your business and they rapidly shift and evolve to meet your business demands. By focusing on the code that churns you can get the maximum lifespan out of your code.

The real headaches arise when code doesn’t get updated and the reason for that is because it’s hard to read. That is when real problems arise. Technical debt will start to accrue as the code begins to gather cruft, the conditionals increase as the half-life of your code continues to lengthen.

The best way to prevent long-term problems will be to identify this unstable code and future proof. For Greenfield projects, this is significantly easier as you can engage in best practices like refactoring your code and keeping your codebase well documented. However, this isn’t always the case. Finding a competent team of professionals to take on legacy code, especially if you’re stuck, can be the best solution.

Security

The final point to consider here is security. In this debate, it’s probably the trump card and often the reality check that brings us back to Earth. Considering the security of your stakeholders, whether internal or external should be your number one priority bar none.

Unfortunately, there will always be malicious actors who seek to profit from the weaknesses of others and technology is no exception. While there is no hard or fast rule to how quickly criminals can take advantage of ageing software frameworks, you have to accept that it is an inevitability.

To stay ahead of those who seek to take advantage of technology, the creators of the coding software we use must keep up to date and we must move with them.

Answer the question!!!

With all that said, what can you expect the lifespan of your code to be? There are two answers here.

The cynics of the world will [correctly] tell you, that from the moment you deploy your code, it is outdated. Innovation never stops and you should always look to be agile, ready to adapt to what the future holds. After all, technology has never been one to sit on its laurels.

However, a more realistic response to your question is 3-5 years. However, that is NOT the absolute answer and every single case should be treated individually. However, in our experience, it typically takes 3-5 years for one of the following conditions to prompt the need to change:

• A security threat forces you to adapt.

• The framework and libraries you use are upgraded.

• The pace and technological demands of your industry force you to adopt new practices.

• Design trends have totally changed the visual landscape of your industry or niche.

• The users you serve are no longer satisfied with your product.

Break down barriers with Co-Creation

Whether you are starting a project from scratch and want to futureproof your project or need a team of experts to assist you with legacy code, we can help. We’ve proven ourselves time and again, exceeding our previous clients’ expectations and delivering on their investments.

In each project we undertake, we uncover all we need to know about your users and business need to craft a bespoke solution to your needs to accurately quote what it’s going to cost. We can work with all levels of your business to help them understand what we are trying to achieve and how we mean to execute it.