Technical Debt: The Difference Between Standing Still and Moving Forward
ByOn June 4, 2015 At 1:34 pm
Responses : Comments are off for this post
Currently, there are many businesses whose innovation and productivity are hampered by costly and inflexible information technology. Anywhere between 4-6% of a firm’s revenue is spent on IT – a figure that has grown in recent years. This growth in the expense of IT can be attributed to neglect, poorly executed integrations, and the rapid speed of change in technology. Quantifying the cost of lost productivity and innovation is a difficult task, but Gartner estimates that the total cost of poor systems architecture, design, and development will reach $1 trillion in 2015. This is an average of $1 million per organization or, according to software analytics firm, CAST, approximately $3.61 per line of code.
This expense is called technical debt. The challenge with technical debt, for IT leaders, is that the cost of lost opportunities attributed to tech debt is not easily calculated, but the costs of attempting to modernize legacy systems are quite visible and substantial. Therefore, in order to improve performance of IT systems, IT leaders need a thorough understanding of technical debt.
The author of this post goes onto describe an experience with a mid-sized manufacturer that was spending 85% of its maintenance budget on supporting one legacy system. In this scenario integrating new applications was a risky endeavor and the constant maintenance required was taking resources away from automation activities that would stimulate growth. The old system at the firm mentioned was successfully phased out, and a more modern and efficient one took its place. However, the ultimate focus should not be on the success of replacing the old system, but on why the old system was so riddled with technical debt.
The difficulty of dealing with technical debt is leveraging the resources available to support current processes and capabilities with the existing deteriorating code, while also deciding when and how to transition old systems out to support new objectives. An effective analogy would be to compare an old legacy system to an old beat up car. The owner of this car knows that it would be cheaper in the long run to replace the car with a more modern and efficient one, but may not be able to do so because they don’t have enough for the down payment or can’t go a day without the transportation. They are subsequently stuck trying to keep the old car running. However, this analogy does not demonstrate well the value of abandoning the old system. The difference between an poorly running legacy system and a modern fully integrated one is greater than the difference between an old car and a new car. This is because, ultimately, either car will achieve its goal of getting its owner to a destination. With an old technical debt ridden legacy system and new efficient system, the difference in outcomes are supremely different. A new top-notch system can deliver opportunities for innovation that the older system would inhibit.
Eliminating the source of technical debt (the old legacy system) is not as simple as hiring developers to rebuild the infrastructure; this does not keep future technical debt from rearing its head again in the future. In order to proceed with handling technical debt and its consequences, the following steps need to be taken:
- Calculate existing technical debt: this can be done by comparing the capabilities of the current software in place to industry-leading versions.
- Determine the organization’s goals: to what extent do business activities currently rely on the legacy system in place, and what functionality will be needed in the future system.
- Identify and prioritize the areas that require the most remediation.
- Measure and track the progress of this process at the senior level.
It is necessary to be aware that even after updating the systems in place the threat of adding on technical debt again is still very much present. This requires vigilance of the efficiency of IT operations.
To read the full post go here.