Technical debt can bog down any organization that attempts to be agile. If too much of the IT budget is spent on maintenance and not on innovation and development, productivity will decline sharply. The example used in this post is Telefonica in Spain; the company freed around 14 billion Euros and 18% of the total IT budget after they had removed thousands of legacy systems weighed down by technical debt. This demonstrates the monetary value of reducing technical debt within an organization. However, technical debt is not only detrimental in the sense that it constrains an organization’s budget, but also in that it is an impediment for developers because they are building on a less than solid foundation.
Developer productivity reacts negatively to technical debt as demonstrated by the following formula:
Developer Productivity = 1 − [size(technical debt)⁄ size(system)]
The author of this post posits that this formula may not reveal strongly enough the negative effects of mounting technical debt on productivity; because as system size and technical debt grow productivity is likely to go below zero. Furthermore, any attempts to improve the situation can often result in more problems than in any improvement. Therefore, when technical debt consequences reach such heights what can be done to resolve the situation?
There are three steps proposed in this post to remedy technical debt build up.
1. Keep track of it
Before engaging in managing technical debt, there must be a keen awareness of how tech debt affects the process outcomes at an organization. For example, is most of the IT budget spent on infrastructure and maintenance? Is there a large amount of innovation that needs to be pushed out, but only a small amount of innovation is able to be pushed out through a funnel? These are the type of metrics that are needed to solve the problem. There are several services that can provide these metrics. One mentioned in this post is CAST Software. CAST implements static source code analysis in order to produce an amount of total technical debt in the system under study. This enables the organization to compare and trend technical debt across applications.
2. Avoid it
If there is a vested interest in monitoring technical debt, there will also be a desire to avoid tacking on more debt onto the system. In order to avoid adding more debt, some key agile practices can be utilized, such as: continuous integration, automated unit testing, refactoring, complete feature testing, and test driven development.
After identifying and preventing more technical debt from being added, the process to begin technical debt reduction can begin. The scenario drawn out in this post, in order to demonstrate some methods for tech debt reduction, consists of four sprints prior to release. Given this scenario there are three strategies that can be used to reduce technical debt.
The first strategy is to fix all bugs in the first sprint before building any new functionality. The benefits of this method are that it promises a stable foundation to build upon, bugs that are fixed sooner rather than later are easier to fix, and after all bugs are dealt with there will be less risk present for the rest of the schedule.
The second strategy is to enact ‘hardening sprints’ in which a team will gather all bugs that were discovered during production and previous sprints, and then attempt to restore the product to an acceptable state in order to release it as planned. This, however, is not the best option and is a possible signal that there are other issues at hand that caused the implementation of this strategy.
Lastly, the third option would be to do a little bit of technical debt reduction work in each sprint. This method allows for small amounts of technical debt to be removed while also being able to provide new functionality within each sprint. The reason for why continuous delivery of functionality is important is that if any team refrains from delivering functionality for some time it will soon be the case that what they are producing is no longer relevant.
In a study cited in this post, it was found that integrating a prioritized list of technical debt items parallel to the development backlog and then focusing a percent of sprint effort or every nth sprint to technical debt reduction is the best strategy for technical debt management.
A clarification is made at the end of this post – that technical debt remediation is not inclusive to solely bug fixing. Bug fixing is an issue that must be taken care of as soon as possible in order to continue on to new things, while debt reduction is focused on reducing risk and not simply resolving such problems.
To read this full post go to: http://www.gregerwikstrand.com/technical-debt-reduction/
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.