IT technical debt: How to measure and reduce the technical debt of projects & project portfolios

Escaping the black hole of technical debt... Is your reflex to grunt when you see this? Yes, so do we. Between fatality and despair, there are solutions! Technical debt is a software development concept invented by Ward Cunningham in 1992. The term comes from a metaphor, inspired by the existing concept of debt in finance and business, applied to the field of software development. Beyond what the company already has behind it, the stock, it creates legacy as soon as it develops. It's a permanent flow. It's when you let yourself be overtaken that you create a technical debt that becomes binding...

Find out more in this article:

• The main categories of technical debt
• How do you quantify technical debt?
• How can you manage a project while recognizing its technical debt?
• How do you measure technical debt?
• What levers can CIO activate to better control technical debt?

The thinking behind the creator of the concept of technical debt, Ward Cunningham

As long as 30 years ago, Ward Cunningham drew a comparison between technical complexity and debt in a feedback article.

Delivering the first code is a lot like getting into debt. A small debt speeds up development, provided it is quickly repaid by a rewrite...

The danger arises when the debt is not repaid quickly. Every minute spent on code that isn't quite right adds to the interest owed on that debt. Every week that passes makes developers forget what to do to repay the debt they've accepted.

A CIO can come to a total standstill because it is crumbling under the weight of unpaid development debts.

It's appropriate for an IT project development team to seize opportunities to repay (or settle) this technical debt. If you're managing one of these software development projects, set aside a percentage of your development cycle to pay off your debt. Or better still, dedicate an entire development cycle. A Sprint 0, for example, with Scrum. To complete this work. If you don't, that sub-optimal or faulty code is bound to come back to haunt you. Either your project team, the help desk, the support team, or someone else downstream from your deliverables. Not to mention the increased difficulty of upgrading your application over time.

It's a real debt, and like any other debt, you'll have to pay it back sooner or later.

You sometimes accept quick & dirty developments. Because it saves you time and justifies the risks and total cost. But you're adopting a very short-term thinking process. You don't really know how to estimate the long-term costs and risks involved. If you don't absolutely have to take the risk, don't take it. Delivering quality work is your priority!

The main categories of technical debt

1. Debt accumulated over time due to changes or evolutions in development frameworks

It's almost inevitable that your framework will evolve and improve to the point where you'll want to adopt newer versions. If you don't monitor these changes and evolve your code base accordingly, you'll find it increasingly difficult to adopt newer versions. Perhaps someone will add a new module or integrate a new service that you'll need in the near future. This category of debt is the least destructive and can be avoided by adopting a good framework update strategy.

2. Obsolescence debt

Projects depend on external elements (libraries, APIs, models, architectures, etc.). They also generate technical debt, as external elements evolve in parallel, leading to theobsolescence ofcertain parts of the code and the need to create updates. Technical debt is unavoidable in software development, and persists throughout the life of the product.

3. Pragmatic debt

The reality of software development is that there's never enough time to do a perfect job. Sooner or later, you'll have to make something less ideal in order to meet deadlines and budget. Often you can afford to compromise on quality, but how do you know when? The rule of thumb is that the cost of implementing the feature in this sub-optimal way is equal to the cost of doing it twice! Once to finish it on time and once to rework it in a more optimal and sustainable way.

If you fail to repay debts 1 and 3 within a reasonable period of time, it's like having signed up for a high-risk mortgage. You'll find that with this accumulation of technical debts, it becomes almost impossible to add new functionality to the existing system in a timely manner. You probably have far more bugs in your system than is acceptable. You inevitably spend more on operational maintenance. Your users have already started to notice errors, security flaws or performance problems... These represent the cost of maintaining the debt a bit like the interest you pay on your mortgage while you still have to find a way to repay the capital.

Discipline is its own reward in the long run. You'll be able to afford to spend more money on new features over time if you pay off your debts in a timely manner. It's best to create a structured plan for paying off debt with an acceptable timetable.

How do you quantify technical debt?

Before taking on this debt, it's a good idea to determine how much you'll need to invest to pay it off. Calculate the proposed debt in euros by adding up :

• the development days required to correct the code
• the additional support efforts that will be required during the period when the project customer is operating a non-optimal solution
• payment deadlines for project customers who will not be 100% satisfied...

This financial assessment of the application's lower structural quality enables you to compare the IT costs with the potential business losses due to a failure that could not have been envisaged before accepting this debt.

At the very least, quantifying your technical debt will help you reduce the number of structural quality violations. The key is to keep a watchful eye on this violation counter.

As with debt in the real world, the trick with technical debt is to keep a close eye on your debts and make sure you have a plan of action to pay them off. Allowing your debts to grow without thinking about what you're doing is an unacceptable way to run your personal finances...
... like your software development project.

To do this, keep a record of your debts in a simple format, like that of an account tracker, and easily understood by everyone. In it, the team details the technical consequences of those decisions that will negatively impact the quality of the product's implementation (probability, impact and remedies envisaged). Make sure that every developer on the team knows and understands this register. Every time you add debt, add a line to your register at the same time as you deliver the code in question.

When you repay debt, cross out the corresponding entry in the register.

Make it a routine at the end of each Sprint to conduct a review of your debt register. As with a risk register, make sure you have an action plan to address each line.

Share the register with your team. Make sure they understand the reason for considering a new debt and the magnitude of the upcoming repayment.

...Not everything is technical debt

Not all defects and bugs are technical debt. They're often just mistakes, even if you consider them irresponsible or unworthy. In reality, these errors don't often reflect design decisions. If it doesn't directly jeopardize product quality, it's not technical debt.

In Scrum, a good DONE definition must be robust enough to ensure that unreasonable levels of debt are not reached. If, despite this, technical debt continues to increase, the definition of DONE will probably have to be revised.

How can you manage a project while recognizing its technical debt?

Detail the technical consequences

For effective project management, keep a record of your liabilities in a simple format. Detail the technical consequences: probability, impact and remedies envisaged. Whenever you add debt, add a line in your log when you deliver that code. And when you pay back debt, cross out the corresponding entry in the log! And, at the end of each Sprint, conduct a review of your debt register.
If you want to go further, you can define risk indicators. And apply them to projects using project portfolio software.

Expand infrastructure lifecycle management to include strategic portfolio management interfaces

Digital businesses demand a resilient and adaptable infrastructure; however, uncontrolled technical debt is preventing infrastructure and operations managers from meeting this requirement. IT leaders should strengthen portfolio management by adopting practices that keep their infrastructures agile and up to date.

An infrastructure portfolio management practice provides the support and resources needed for ongoing assessment, lifecycle management and governance.

Choose an infrastructure component to pilot for strategic portfolio management planning that is of high value and has no obvious barriers to implementation.
Assign the appropriate owner to draft a strategic portfolio management interface plan for the infrastructure component.

Once stakeholders are comfortable with the procedure, increase the number of infrastructure components subject to this procedure. Continue until all components identified by other portfolios as requiring higher levels of performance in terms of benefits, risks and costs, have a strategic portfolio management interface plan.

What tools are needed to measure technical debt?

• Automatic measurement tools: this is an interesting way to start effortlessly measuring the level of technical debt, thanks in particular to tools that detect violations of best practices. The Sonar tool, for example, ensures that developers follow class and method metrics.
• Test coverage measurement tools: this type of solution provides information on the amount of code covered by automatic tests. For example, coverage of less than 75% may indicate major problems in the code.
• Manual measurement tools: You can build up reports to measure the impact of technical debt using certain indicators. Such as the number of bugs over a given period and per application, the duration of investigations on a legacy product, component or code, the rate of dissatisfaction during deliveries, etc.

What levers can CIO activate to better control technical debt?

1. Agile technical debt: improve overall code quality 

Agile development is all about speed. When teams scramble to meet sprint deadlines, this usually results in tedious methods, inefficient routines or poor-quality code.

The peer reviews are an expensive but effective way of checking that good programming practices are being followed. Watch for code problems and correct them as quickly as possible. You need to share them with the team, so that you can learn from mistakes every time. Take the opportunity to enrich your document on standards and best practices to be followed by developers. For a more significant improvement, involve your technical architect with the development team. Refactor your code on a regular basis (not every Sprint, but every Release, for example). This will give the team the opportunity to analyze and rewrite part of the code at regular intervals to reduce technical debt.

2. Test, both manually and automatically

Manual testing is not very efficient. One of the most effective ways of reducing technical debt is to automate testing as much as possible. Start by focusing on non-regression tests, which are particularly time-consuming and all too often neglected or botched for this reason. Then focus your attention on end-to-end testing, which guarantees the usability of your solution. These will probably be manual, and carried out by experts in the field, at least initially.

3. Limit risk by rationalizing your choice of technologies

The greater the diversity of technologies used, the greater the risk to quality and the greater the complexity of application maintenance. The "younger" the technologies, the less proven they are. Select components that are stable, supported and regularly updated. It's important to limit the number of technologies involved in building your application. The greater the number, the more complicated it will be to control the sources of debt (and therefore the number of creditors).