This is the first part in a series on managing technical debt.  Technical debt is not a new to the software industry, but it has made headlines in recent years as the true cost of software maintenance has become apparent.

First hand experiences

Technical debt – infrastructure (telecommunications)

Having experienced a national telecommunications network upgrade, the tech debt that had to be paid back was enormous. In an infrastructure roll out, where the network is the underpinning of other services, it left a lot of customers and employees disgruntled. What was running fine was not able to scale securely to the next phase in the business’ lifecycle. In that instance, the network was upgraded successfully on a technical level but left a lot of collateral damage.

Technical debt – software

A client of ours has a software package we’re happy to support to keep their business continuing.  However, we are limited in what we are able to do to manage the technical debt based on the budget available.  Every quarter, we assess with the client what issues are costing them and we work out a way to reduce these pain points.  Sometimes the monkey-patching we have to do is inexpensive.  Other major changes are put on the nice-to-have list on the next major release.

What is technical debt?

A simple explanation from wikipedia, Technical debt (also known as design debt or code debt) is a newly formed metaphor referring to the eventual consequences of poor or evolving software architecture and software development within a codebase. The debt can be thought of as work that needs to be done before a particular job can be considered complete. As a change is started on a codebase, there is often the need to make other coordinated changes at the same time in other parts of the codebase or documentation. The other required, but uncompleted changes, are considered debt that must be paid at some point in the future.

Technical Debt Case Study technical debt case study from delft university

The Delft University of Technology paper from the Netherlands is about a scientific peer-to-peer software platform which cites in it’s abstract that unmaintained software falls into the category of technical debt.

Issues creating the tech debt

The research states that the platform suffers from:

  • complex architecture
  • an unintuitive user interface
  • an incomplete and unstable testing framework
  • a large amount of unmaintained code

Paying back technical debt

A new layered, flexible and component-based architecture that readies the platform for the next decade of research was proposed and discussed. Laying the foundations for this new architecture were:

  • implementation of a RESTful API
  • a new graphical user interface

By removing the old user interface, the amount of technical debt in the platform was dramatically reduced. Additional work included the pay off of various kind of technical debt by the means of major improvements to the testing framework, heavy modifications within the core of the platform and changes in the infrastructure to make it more usable and robust.

How much does technical debt cost?

In this case study, some 26,000 lines of code were changed (approx 12,500 removed, 12,500 added, 1,000 new). If using new/added lines of code as a pricing estimate, then paying off this technical debt cost approximately $270,000 @ $20 per line of code.  The real figures are known only to the stakeholders, but it’s clear that a major update to the platform must be budgeted much like a strata plan sinking fund.

After the update to the platform there were several important software metrics improved and huge amounts of technical debt were paid off.

Conclusion

In conclusion, raising awareness about technical debt in general is of utmost importance if we wish to prevent deterioration of the system. Together with a code review policy and static code analysis tools to track code coverage and the amount of code violations, it is hoped to prevent huge amounts of tech debt accumulating in the future.