The pricey bill of technical debt: When and by whom will it be paid?

Trade-offs are made in software development every day. One of these is the choice between quick solutions and better – but also more expensive – solutions. Bad choices may result in technical debt, which leads to more costs down the road. Besker, Martini, and Bosch report on the height of these costs and their causes.

Incurring technical debt can be a sensible business decision in the short term. But that debt will have to be repaid eventually – and comes with interest.

Until the debt is repaid, it’ll have an adverse effect on the evolvability and maintainability of the software: it becomes hard to train new developers, and changes that seem small may take ages to complete or even be wholly infeasible to implement.

It’s important to note that not all technical debt is the same. Some forms are more harmful than others – what we don’t know however (side note: In the rigorous, empirical sense), is how harmful they are and who are affected most.

These are things we should know, otherwise it’s nigh impossible to manage technical debt responsibly!

Unfortunately it isn’t possible to get cold, hard numbers about the actual cost of technical debt. Consequently the authors used two methods that don’t necessarily yield reliable data on their own, but do paint a more accurate picture when they’re used together:

• An online survey that includes questions about the experiences that respondents have had with technical debt. This survey was completed by 258 software professionals, which were recruited from the authors’ professional networks and software engineering groups on LinkedIn (side note: Does anyone actually use those?);

• Semi-structured group interviews with software professionals from 7 companies to confirm results from the survey and gain a better understanding of the implications of those results.

Discoveries were centred around the cost, challenges, and consequences of technical debt.

On average, respondents claimed that 36% of software development time is wasted by interest due to technical debt. That’s a lot of time that could otherwise have been spent on adding new features and reducing time to market!

At first glance the interest appears to be higher for older systems (say, older than 20 years) than for newer systems that are less two years old, but no actual linear correlation could be found.

One might conclude from the data however that technical debt is typically introduced early and then never really resolved.

There are 11 types of challenges that arise (side note: The exact mapping between the concepts identified by Li et al. and the list presented here isn’t entirely clear.) from technical debt (Li, Avgeriou, & Liang, 2015):

• Complex architectural design
• Requirements
• Testing
• Source code
• Infrastructure
• Documentation
• Dependencies on external resources
• Too many different patterns and policies
• Uneasy/tensed social interactions between stakeholders
• Lack of reusability in design
• Dependency violations

Survey results show that participants believe that complex architectural design, requirements, and testing have the highest impact on development.

The impact of these challenges seems to be partially related to a system’s age: in newer systems the requirements are more likely to be the most impactful factor, while for older systems it’s complex architectural design.

It’s interesting to note that for most team roles (developers, product managers, project managers, and testers) complex architectural design is seen as the main culprit. Software architects and managers on the other hand see requirements as the biggest issue.

Technical debt interest comes in the form of extra time that needs to be spent on activities that don’t provide any value to customers.

Respondents ranked “Understanding and/or measuring the issues” and “Management process of the issues (track, monitor, communicate)” as the most time-consuming activities.

The first mostly affects developers, experts (side note: The article doesn’t include any definitions for these roles, but I assume this is about domain experts.), product managers, and project managers, while the latter is the largest time waster for managers, software architects, and testers.

1. Li, Z., Avgeriou, P., & Liang, P. (2015). A systematic mapping study on technical debt and its management. Journal of Systems and Software, 101, 193–220.