* 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.
How to deal with 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.
Sign up for CIO Asia eNewsletters.