We’ve all heard the phrase often mentioned in discussions surrounding the DevOps space. We’ve all seen the job adverts freely mentioning the concept as a reason why you’d want to join a company. But what precisely is technical debt and why are DevOps developers increasingly being sought after to help alleviate it? Is it because DevOps developers have a particular tech stack that makes the handling of technical debt more manageable, is it something more intrinsic to the personality of a figure working in DevOps, or is it simply a catch-all opinion that’s spread to the masses without any real reason?

During this brief blog post, we’ll attempt to shine a light on these questions and offer some potential reasons as to why DevOps is considered useful in managing technical debt.

What is technical debt?

But first, before attempting to examine the relationship between DevOps and Technical Debt and why the two are so closely associated together, it’s important to first define what technical debt is. 

Simply put, technical debt is a concept in software development that refers to: 

“The consequences of software development actions that intentionally or unintentionally prioritise client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations…” - Information and Software Technology Journal

Following this definition, we can interpret technical debt as an unknowing accumulation of subpar decision-making that results in an organisation’s IT products being rendered either unusable or more commonly, in dire need of management and organisation. 

Encountered both in the development and operations side of the business, technical debt sees organisations uphold short terms goals (client value or delivery deadlines etc.) over long term ease of use. Think running before you can walk, but with tech. 

And that’s not to say technical debt is necessarily a bad thing either. It’s now widely considered a natural part of a business’ lifecycle which is why we see it so often referred to neutrally on adverts regarding job roles. It’s at this point neither an outwardly good nor bad thing, but more rather a neutral occurrence that businesses come across at times that has to be attended to. 

So, how does DevOps come into this?

Well, when we think about the overall functions of a DevOps team and the responsibilities that are usually levied their way, we can begin to see hints towards why DevOps is widely considered useful in the battle against technical debt. 

1# DevOps Product teams

Speaking in broad strokes, DevOps are usually made up of small multidisciplinary teams that are focused solely on handling the entire lifecycle of a chosen product or service from formation, to release and then finally retirement.

When thinking about this, it stands to reason that if DevOps were placed in an area where technical debt naturally arises over time, the DevOps teams’ everyday management of the product area would mean they can recognise the early warning signs of debt forming and take the appropriate actions to help solve it. 

Also, through coming across the technical debt daily in the everyday management of their chosen product, DevOps teams would be more inclined to remedy the issue straight away as it arises rather than prioritizing other, short term goals.

#2 DevOps can create self-service platforms

In conversations around the topic of remedying the blight that is technical debt, you’ll often see self-service platforms built by DevOps referenced as a useful tool organisation can use due to them helping avoid the technical debt commonly built up through toolchain creation and miscommunication.

Through self-service platforms that are built up to meet the precise needs of an entire product team (third-party software-as-a-service solutions etc.), organisations will be able to streamline groups and ensure inhabitants are on the same page regarding platforms. 

This should, in turn, reduce the separation commonly seen between platform builders and consumers and instead form an inclusive and collaborative environment where everyone is on the same page regarding internal betterment and from that technical debt reduction. 

3# DevOps Automation is key

As any person familiar with the development process will tell you, automation is arguably one of the most integral strategies DevOps can use when working. From Culture-Automation-Lean-Measurement-Sharing models to the self-service platforms mentioned earlier, automation runs integral to DevOps past and present work practices. 

Automations close proximity to DevOps means it can also be highly useful in passively tackling technical debt. Consider for example a scenario where your application works in the development stages, but not in pre-production or production stages. The cost associated impact caused by the time that needs to be allocated to help your team spot find the error could be considered technical debt. 

Through automation types such as configuration-as-a-code and infrastructure-as-a-code allowing product teams to clearly & repeatedly express how they want the environment to be etc. with little to no variation, there’ll be less time spent troubleshooting and more time spent tackling other more neglected parts of the business… like technical debt.

BONUS – Using DevOps built API models

This is more so a stylistic choice on the part of an organisation than an outright recommendation, but it’s been proven that encouraging teams to use APIs with well-defined, versioned interfaces can battle some of the root causes behind technical debt.

Often in product development, technical debt is caused by different teams accessing and misunderstanding data and changing the schema of the table to meet their needs (inadvertently resulting in hidden dependencies).

Through DevOps creating APIS that each of the products needs to adhere to (with clear future roadmaps and support for semantic versioning), an organisation can avoid this potential stumbling block and create less fragile systems as a result.

Then if at some point down the line a game-changing feature is needed to be implemented to the API spec, DevOps can release a new version of the API with support for the “old” API for a pre-determined support period. All this amounts to, as alluded to throughout the entirety of this blog post, is less unstable systems and from that, less technical debt.

To conclude

In looking at the entirety of this blog and the reasons why DevOps can help in the management of technical debt, we can begin to see certain patterns form. DevOps through various means can help the overall organisation and internal operation of a product, system etc. which in turn can negate the common root causes of technical debt.

While it would be a far cry to say that technical debt can be completely eradicated from a product, through utilising the DevOps space in the right way you can without question make real change and efforts to helping combat it.

*ENDS*