Products have a life expectancy – a time that they operate as expected before they need fixing or replacement. This is true for almost all products. A meat product for instance, can only be kept ‘operating as expected’ for a few days, depending on the storage method. A computer is obsolete in 2 to 3 years for power users, because it doesn’t ‘operate as expected’ with the latest and greatest software. A refrigerator starts misbehaving after 10-20 years and then it needs replacing. We all know that these products have a life expectancy and we understand and accept that.
This understanding is different for software applications. Most people that use software, expect it to work indefinitely. They don’t expect that the creator of the software needs to spend money to keep the software alive the way it is. It’s working now, right? Most people do, however, want new functionality or behavior in software applications and understand that this takes some effort to accomplish.
Software applications do have a life expectancy. This is caused by changing hardware, operating systems, new utilities and increasing capabilities driven by the internet. Also, new technologies and insights are being developed continuously, rendering current technologies – on which applications are built – obsolete.
These factors are external and cause the need to adapt our application to them, to keep it compatible, secure and maintainable.
Another factor that plays a big part in the life expectancy of applications is technologic debt. This is time and effort that gets accrued during software development and has to be paid back at some point in time. For instance; an application is created with a technology that is new to the developers. Over time, the developers understand the technology better and have new insights in how to develop with it. The gap between what was originally developed and what would be developed now, with the knowledge acquired around the technology, is called technological debt.
Another example; an application is developed by an external vendor. The customer wants new functionality and asks the vendor for a quote. When the vendor comes back with the time and effort it would take, the customer responds: “this is too expensive and takes too long, do it for less and quicker”. The vendor gives the customer the choice to get the functionality quicker and for less money, but warns the customer that this will be a technical shortcut and that there is still work to be done because of that. The customer chooses to get the functionality quicker and for less money. The work that still needs to be done is the technical debt.
In most cases though, technical debt arises in teams with lots of experience and the best intentions. It’s a natural byproduct of modern software development.
Technical debt needs to be repaid because it causes an application to be less maintainable, less secure and less compatible with other technologies. The more technical debt an application accrues, the less maintainable it is. Changes will take more and more time and effort to build and cause decreasing software quality.
This increasing lack of maintainability is the interest that builds up on unpaid technical debt. The longer you keep technical debt around, the higher the interest will be and the harder to pay back the debt, just as with a financial debt. This can increase to a point where it is too expensive and takes too long to implement the changes an organization needs, which brings the application and the organization to a halt. The external factors; changing hardware, operating systems, new utilities, increasing capabilities driven by the internet and new technologies and the technical debt of an application cause the need to change.
The need to change due to external factors follows a trend over time; the release of new operating systems and new core technologies. The emergence and write-off period for hardware. And the evolvement of utilities and third-party systems that we need to be compatible with. New operating systems are released every 2 to 3 years (although this is speeding up significantly). Hardware is, on average, obsolete and written off every 3 to 4 years. Core technologies, like the .Net Framework, evolve every 1 to 2 years. The same goes for most utilities, like Microsoft Office.
We could choose to have software that is not compatible with the newest operating system or version of Microsoft Office. We could also choose not to upgrade technologies used in the application, rendering the application more vulnerable to security attacks over time and making them harder to maintain. This is not a good practice because it could present a risk to the survival of our organizations.
Even if we choose not to support the latest operating system, at a minimum we need to keep our application secure and maintainable. This means that we have to keep our application up to date on technologies and best practices while following the trends of building block technologies – like the .Net Framework. In this case, we would have to plan for a major update every 1 to 2 years. This update would not only mean the mere upgrade of technology components – like the .Net Framework – but also the adoption of new insights and best practices, e.g. the implementation of an industry standard data communication technology that wasn’t available 2 years ago.
This doesn’t take away the technical debt and interest on it. We can upgrade technologies and make the application compatible with a new Operating System, but the structural lack of maintainability that might have built up over time, doesn’t go away. We must pay off technical debt and the interest on it. Maybe not completely to zero, but to a point where the ROI (Return On Investment) for paying it off is acceptable. We can measure technical debt roughly through technical mechanisms (cyclamate complexity of code being one of them) and analyzing things like coverage of documentation, maturity of the quality and assurance process. This gives us an idea on what it would take to make the application stable, maintainable and secure and get the time and effort to implement changes to a reasonable value.
Sometimes, the technical debt and interest has compiled up to a point that it is equal or higher than the time and effort it would take to design and build the application from scratch. This is often the case when applications are intertwined with obsolete technologies.
The life expectancy of an application depends on the technical debt it accrued. Technical debt will increase when an application does not get updated to accommodate external changing factors. This and other factors that increase technical debt will determine when an application’s lifecycle gets to a halt. However, if we choose to pay technical debt, invest in maintainability, security, stability and accommodate to the external factors, we can keep our application alive and healthy for a long time.
What to do?
In conclusion: when dealing with software development, it is wise to at least do the following:
- Measure the technical debt of the software
- You need to know how much technical debt there is in your application. There are lots of tools out there to help you measure it (like http://www.ndepend.com ) Also, there are vendors out there that can help you determine and continuously measure technical debt
- Continuously pay off technical debt
- You should always be paying off technical debt, continuously throughout the development process. In each development iteration, plan to pay off some technical debt. When you do this, your application will live a long and healthy life
- It isn’t easy to get this into the regular development process. The notion of technical debt needs to be understood and adopted by your manager, which doesn’t always happen. Alternatively, you could just plan these items in as necessary technical items that need to be solved in the iteration, not talking about technical debt.
Created with
