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

A customer falls off their chair when the waiter hands them their restaurant bill

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.

Why it matters

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 howeverIn 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!

How the study was conducted

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:

What discoveries were made

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

Cost

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.

Challenges

There are 11 types of challenges that ariseThe 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):

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.

Consequences

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, expertsThe 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.

The important bits

  1. On average about 36% of software development time is wasted due to interest payments on technical debt
  2. Technical debt is typically introduced in early project stages and tends to persist throughout the software life cycle
  3. Project participants are mostly plagued by complex architectural designs and requirements
  4. Understanding, measuring, and managing issues takes a lot more time in projects with technical debt

References

  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.