Technical debt: Hot to assess it and manage it
Although it has never received proper consideration from a management point of view, “technical debt” is a popular concept among developers. Indeed, it is an idea useful for managing any company with a software development department.
Developers tend to describe technical debt as a consequence of deadline pressure, when, in order to deliver a product on time, developers have to cut some corners here and there, make compromises, and leave open wounds on a shadowy matter named code quality.
From an engineering point of view, technical debt can be described as a choice in software design made to satisfy short-term needs but capable of harming a long-term ontogenesis of code.
From a managerial standpoint, technical debt is not a debt, but a risk of increasing cost or schedule of development on account of current development process and its outcomes. Any decision made, any line of code written and any functionality delivered is naturally bound to a certain risk. The only circumstances under which you can develop with equal efficiency, regardless of what exactly is being developed, is the absence of any code to stay compatible.
On a qualitative level, the concept of technical debt is apprehensible. However, as with any risk, it is sometimes necessary to quantify it. There are several indicators of the amount of technical debt:
* Estimate accuracy. Without technical debt present, in an ideal word, developers’ ability to estimate time required to develop a particular feature would evolve and become more accurate. Increase in expertise in project domain; better knowledge of used tools and frameworks; ability to predict performance of other team members – theoretically this all would make estimates of any developer and of the development department as a whole more precise. Should the opposite happen, it means the system is getting out of control. The loss of accuracy in estimates can be measured, and this measurement can give you a very good idea about the amount of technical debt accumulated.
* Time to first feature.Another useful metric is time to first feature by new hires. A period of adaptation is always required when a new developer joins the team. This period is determined by two factors: aptitude of the code for comprehension (the shape of the learning curve), and speed at which the developer moves along this learning curve (his own capacity to learn). Both of them are important. However, if on average new hires require more time to bring new features to your production environment, it is pretty likely that the learning code has become too flat – and it is the technical debt to blame for it.
* Internal metrics failure. Developers and DevOps really love tools and metrics. They benchmark and measure incessantly. It is very likely that your development team has already set up some tooling to automatically track the current status of software. For example, they might have a system tracking build “health,” i.e. checking whether the current version of software passes tests. It is normal to have this system indicating poor status even most of the time. At the same time, having this indicator in a poor status for prolonged uninterrupted period of time is totally unacceptable. If you have builds in a red status for a month, it means that in the last 30 days your software has never met the quality standards it was satisfying in the past. The important metric here is maximum duration of all-red interval. The larger it is, the more likely you are to be drowning in technical debt.
Developers do not like technical debt: it brings unnecessary complexity and bereaves the system from elegance and finesse; it is just not how things should be properly done. Or is it
Many team leads and managers with a development background easily fall into a quixotic fight with any signs of technical debt as soon as – or even before – it merely arises.
On the other hand, some result-driven leaders show little or no respect for technical debt at all. Such managers can be successful if they are good with finding the proper timing to change jobs. They deliver results at first, digging deeper and deeper into a well of technical debt, keeping the team under relentless pressure and, at the end of the day, leaving an almost unbearable amount of unsolved problems to a successor.
Needless to say, both approaches are dangerous. As with any kind of risk, technical debt is beneficial when properly managed. Some best practices:
* Know your debts. Any person capable of dealing with his own credit card bills should know when he’s running up the expenses. It is always a good idea to have debt documented. Two approaches are possible here: document debt as it is actually incurred, or document debt as soon as you find it as an actual obstacle. My personal recommendation is the second one. This way your debts will prioritize themselves automatically. Key to knowing your debts is being peremptory in following the procedure for debt documenting.
* Review and repay. Knowing your debts, you should review and repay them from time to time. Sometimes it might be better to incur one debt while repaying the other one. Speaking in financial terms, you should have high accounts payable turnover ratio: the longer the technical debt stays with you, the harder it will be to repay it since knowledge will disperse.
* Remember diminishing returns. The law of diminishing returns applies to repaying technical debt almost unconditionally. Removing the largest problem might decrease risks dramatically. Every subsequent problem solved will bring less and less utility.
* Plan for contingency. Since technical debt is a risk, having contingency reserves is a good idea. You’ve run up the bills when your business required that, which is great. But when you’re planning the next period, the next development, make sure you’re taking into account an actual amount of risk.
* Divide et impera. There is a time to rend, and a time to sew – not only for your company as a whole, but for your developers as well. A huge temptation exists to let some developers – those, more rapid and less thorough – to make new developments, incurring technical debt, while leaving “workhorses” to clean up and repay it. But it is not a good idea. Even though it might affect short-term productivity, for the sake of motivation and team building, no developer can be excused from debt-repaying duty.
In spite of all the consequences described here, when dealing with technical debt, you should be risk-prone, not risk-averse. Since incurring technical debt still requires a large effort, it is almost impossible to make too much debt in a short period of time. When repaid fast, technical debt does not leave much accumulated interest. Being properly managed, technical debt is safe and enables delivery of valuable product for business growth.