Technical debt

According to Techopedia, technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.”

Here’s the thing. A lot of organisations consider technical debt a technical problem. In other words, it’s something for their IT teams to deal with. However, the reality couldn’t be more different.

A problem shared

It’s true that technical debt requires technical solutions. But the responsibilities for shouldering its burden are usually left at the doors of both IT and business. Technical debt is notorious not only for its impacts on running and maintaining software systems. But also for its ability to disrupt IT-business alignment. The fact is both divisions approach technical debt in very different ways. The below statements sum things up pretty accurately from both sides:

• IT excels in understanding technical debt but struggles to explain what it actually involves, not least the impacts and risks for business.
• Business has no problem accepting the reality of technical debt but excels in downplaying its impacts and risks.

This miscommunication often perpetuates a vicious cycle, generating more and more technical debt to a point where a system becomes volatile to almost every change. Martin Fowler’s helpful graph breaks down the sources of technical debt into four quadrants below:

Now even though this debt is divided into “good” and “bad”, we can take it as read that any technical debt is generally bad.

Deliberate responses are often driven solely by business concerns. Whether the response is prudent or reckless doesn’t really matter. A product has to be released as soon as possible. Or a bug needs to be fixed right away, etc. Even in cases where an organisation is aware of the consequences, they’re hardly ever addressed.

Inadvertent reckless responses more often than not reflect the quality of the team involved. If a team’s struggling with the concept of layering, you can be pretty sure they’re not fit for the job. Not being aware of gaps in your knowledge raises a pretty alarming red flag.

Inadvertent prudent responses to technical debt can be usually attributed to more technically proficient teams. The difference is they’re fully aware of the mistakes made and are now getting their house in order.

Getting the message across

So how can technical debt best be managed? The secret lies in effective communication:

• Explain the impacts of TD in a systematic but accessible way.
• Make the problems visible to everyone using proper tooling.

To explain the risks of technical debt, the consequences of ignoring them must be communicated in a way that makes business sense. Of course, this is easier said than done. Let’s face it, IT departments aren’t exactly renowned for their soft skills.

The key here is to ditch the IT jargon. Instead, present the negative consequences of taking shortcuts. Let’s take the following two scenarios:

• If we take this shortcut, our user data model will get disconnected from our Active Directory. This is going to create major obstacles going forward.
• If we take this shortcut, our users won’t be able to access single sign-on functionality. That means they won’t be able to automatically log in to our app using Windows environments.

Everything out in the open

Making technical debt visible is not as complicated as you might imagine. This is largely down to the huge capabilities of automation, with its ability to connect static analysis tools to the automation pipeline and generate regular reports. For example, linters and open-source platforms like SonarQube are great tools for comprehensive and same-for-all analysis of source codes. They also measure incremental changes so everyone can see when things are getting better and vice versa.

But it’s not all about tools. To mitigate the risks associated with technical debt, organisations can also adopt other software engineering principles such as pair programming and peer reviews, which are great ways to share knowledge among teams. As you might expect, technical debt analysis is one of the core components of Profinit’s Legacy Systems Assessment.