Technical debt is a very important concept to developers that is often lost on the management end. Developers use the concept to describe the consequences of a pressure to meet deadlines; to release features on time developers will write quick and dirty code, compromise on standards, and leave code quality out to dry. Technical debt is the choice between making sustainable software and making short-term decisions that are detrimental to code in the long run.
For management, debt wouldn't be the term they'd use to describe the concept - but they would rather see it as the risk of increasing costs or missed deployment schedules due to the current development process. Any code written has inherent risk associated with it. Therefore, technical debt is not seen as something ineffectual, but as, sometimes, a necessary risk. To be able to decide whether the risk is acceptable or not technical debt has to be quantified.
There are several ways to measure the presence of technical debt in a code base:
- Estimate Accuracy: without technical debt the estimations of time needed to develop a certain feature would become more accurate overtime. As developer knowledge in a certain area increases (knowledge on tools and frameworks, team performance, etc) estimations by developers would become more accurate. If this is not happening (and estimations become less accurate and more difficult to pinpoint) it is likely that the system is plagued with technical debt. The decreasing accuracy of estimates can be measured and, therefore, be used to measure technical debt.
- Time to First Feature: the time for adaption by new hires is a useful metric for technical debt. This encompasses the comprehensibility of the code and the developer's own ability to understand the code. Both of these components are important, but if it has become typical that new hires need more time to bring components into production "it is likely that that the learning curve has become too flat". Technical debt is often the cause of this.
- Internal Metrics Failures: developers and devops often use tools and metrics to see if code is meeting certain standards. It is likely that your development team already has an internal tool in place to track that status of software; it can be the case that this tool indicates poor behaviour most of the time, and that can be normal. But also keep in mind, that if you have a component that has been marked for 30 days as performing below satisfactory, there's probably technical debt present. The duration of failure to meet standards is a key indicator technical debt.
So once you've measured the presence of technical debt in your system, how do you manage it?
Technical debt is often seen as solely a negative thing, but just as we mentioned that risk is inherent to code - technical debt is also inherent to a system. Many teams immediately fight against technical debt, even before it has actually shown itself to be present. Other teams entirely ignore technical debt, mounting pressure on their developers and digging themselves into a deeper debt.
Ultimately, it is necessary to know how much debt you are incurring. This means either documenting debt in the moment, or when it starts showing itself in the system. The latter option is perhaps the better one, as it automatically helps prioritize those debts that need to be addressed first.
Once you know where and how much debt you have, repaying it from time to time is important. It is best to repay it sooner rather than later, because the longer they are in a system the harder it is to identify. Refactoring is the best way to go about this. This means that there will probably always be certain levels of technical debt present in your system, which means certain levels of risk, so preparing for possible failures with a contingency plan is also a good idea.
Dealing with technical debt is dealing with risk. In a business you can't be risk-averse, but deal with it smartly. If you deal with technical debt in the ways mentioned above, you system should be safe from any from any major problems and enable business growth.
To read the full post visit here.
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.