As a CTO I am responsible for making technology-related decisions, taking into consideration the specific business objectives. My goal is to facilitate the working process within a company by shaping a strategic plan tailored to the company culture. I closely cooperate with Product Owers and developers utilizing my expertise in narrow technical domains. 

Bartłomiej Wójtowicz

\[TOC\]

In some ways, technical debt is similar to financial debt, where you prioritize purchasing an item now instead of waiting and saving for it. Technical debt happens when we need something now or very soon, so we do everything in our power to get it. This includes making coding or design decisions - that we know will have to be addressed sometime in the future - to get what we want quicker.

In the [previous article](https://selleo.com/blog/technical-debt-in-software-development), I focused on the [technical debt definition](https://selleo.com/blog/technical-debt-in-software-development), where I went through three debt types and categorised them by the way they come into the life of a software development project.

Basing on the things we have learnt so far, we can now move on to discussing the techniques of debt measuring and their use in the prioritisation, monitoring and prevention of technical debt.

Throughout the post, I will be making reference to the previous article, so consider reading part 1 for a better understanding of the topic, if you haven’t yet.

## How to properly identify and measure Technical Debt

![Img](https://a.storyblok.com/f/86602/720x383/98ff1c86ef/properly-identify-and-measure-technical-debt.jpg)

The complexity of the topic lies in the fact the tech debt level is not easily measured. Therefore it’s not trivial to prepare some slides for the steering committee meeting and demonstrate it with tables and graphs containing sheer numbers. Though that doesn’t mean that there weren’t any attempts ever made to automate the technical debt measurements and quantify its various levels.

### Technical debt measurement at the codebase level

#### Static analysis tools

There are static analysis tools that could provide you with some valuable input. For my beloved Ruby programming language, there are tools like [Skunk](https://www.libhunt.com/r/fastruby/skunk), [Reek](https://github.com/troessner/reek) or [Rubocop](https://github.com/rubocop/rubocop) - all of them could be used to run through your codebase and generate the **report** based on its findings.

The caveat: as with any static analysis, the reports should be taken with a grain of salt, and the best approach is to use the plain numbers they provide **as a basis for a qualitative analysis** of the technical debt problem you may have in your web application.

The aforementioned tools put focus mostly on the **code complexity and structure** in relation to the other factors like code coverage. However, there are also other criteria you can measure your web application code. These include elements like **code churn** and **code ownership.**

<ReadMore> Read also: [Technical Debt In Software Development - The Definition And Why It Matters](https://selleo.com/blog/technical-debt-in-software-development) </ReadMore>

#### Code churn

The code churn metric can be aliased as a "quick fixes'' metric. I remember working for a client from the USA, who had been developing an e-learning product. We've been using Agile/Scrum and during one stand up, when I've been asked for a status of an issue I said something like "that was a quickfix". My statement caught the attention of a lead developer, who immediately followed up with a question "was that a fix that was quick or a quickfix?"

It's easy to understand where that lead developer was coming from. The code churn resembles the number of times a particular line has been touched by a developer, who has **deleted, replaced, or rewritten** the code in question. The code churn is something that you can expect for new functionalities, however, if you continue to see it for some already settled features, then it may indicate that you may have problems with quick fixes inevitably introducing technical debt **you'll be paying off in the future.**

Hence, in that standup situation I described, I've just been asked by a lead developer if I chose to introduce a technical debt for some reason, and eventually if we need to do something about that.

#### Code ownership

![Img](https://a.storyblok.com/f/86602/720x383/09077cb694/code-ownership.jpg)

The code ownership is similar to code churn, but instead of counting the number of times a particular line of code was touched, you count the number of how many **different people** were tasked with applying changes.

Programmers are not robots, and while each of us tries to follow coding best practices, we may come up with different approaches and follow different visions of solving the same problem. Hence, with many architects behind the developed solution, the chances of getting a [Big ball of mud](https://en.wikipedia.org/wiki/Big_ball_of_mud) get higher than in a situation where there was a proper code ownership strategy (task delegation) for the development process in place.

It's a typical situation when the web application or its particular part haven't been developed by one team (software service providers have been changing over the years, or there was no concept of a developer team at all).

### Technical debt measurement at the project management level

Technical debt measurement can be also taken at the higher level, revolving around project management. You can for instance make a retrospective and analyse your current development cycles and compare it to the historical data. If it happens that your CI/CD approach allowed for shipping code **each day / every few days** and nowadays it happens **once in a sprint** (or less frequently) then it’s worth investigating the cause.

<Baner name={software-development} />

Also, the rule of thumb is: trust your developers. Imagine that you’re planning a sprint and your usual approach is to collectively decide about the incoming sprint assignments. And it happens whenever “the functionality X” is on a table, there are no volunteers; developers become defensive and you can hear a snarky remark or a giggle while discussing who should pick something up - that’s a good opportunity to ask your team what’s causing that.

Also if you hear that “Joe should be assigned to functionality X task, because only Joe…” may also be troubling for many reasons, and one of them may be t**echnical debt.** If something requires an extraordinary skill to work with, because it’s not [SOLID](https://simple.wikipedia.org/wiki/SOLID_(object-oriented_design)), then clearly you have amassed a lot of debt to pay off.

Finally, the amount of bugs appearing **now** vs particular development periods in the **past** is an indicator on its own. That can also be a retrospective topic.

## What is the actual price of technical debt?

Now that we have gone through the challenges of the technical debt identification and measurement, a few words on the **actual cost in money**, because that’s usually a baseline for decision making for people who are calling the shots when it comes to paying the technical debt off and when.

One obvious thing is an attempt to estimate the identified workload in terms of development time. But usually, it’s also beneficial to understand the overall future cost of technical debt. Here the **Technical Debt Ratio** (TDR) comes in handy. It is a relatively simple equation of:

![Img](https://a.storyblok.com/f/86602/720x180/b3a73c5804/dzialanie-1.jpg)

In the given formula the remediation cost stands for the cost of fixing the software system, whereas the development cost is the cost of building it from scratch. The result is a percentage you should consider for any new development, as an extra cost of building and shipping software. Such a percentage should also allow for making informative decisions about the next steps in software development and is good to bring up in meetings with stakeholders.

## What steps to take to deal with technical debt? Prioritisation, prevention and monitoring

Now that we know how to identify and measure the technical debt (including the cost) we have a whole **spectrum of choices** where it comes to **addressing** the technical debt, short and long term.

As we have an idea of how much technical debt there is, we can try to quantify the cost of paying off that technical debt, as well as the cost (interest) incurred on any new functionality or amendment in the system, assuming that the technical debt level remains unchanged.

Hence, we can focus on the **prioritisation** of the particular technical debt elements and come up with the technical debt repayment schedule.

We can also work on improving our **monitoring** processes in order to prevent adding more technical debt, as having the debt identified we understand our situation and it might be the case we just can’t afford to add any more debt. Or we come to a decent conclusion that in a retrospective we did regret situations, whenever we added a technical debt in the past.

Because technical debt shares some similarities with medical science, where it’s a known fact that **prevention usually costs far less** than the actual treatment.

<ReadMore> Read also: [Ruby On Rails Web Development](https://selleo.com/blog/ruby-on-rails-web-development) </ReadMore>

## Summary

With the level of cruft measured, there are plenty of good ways on how you can move on with the technical debt. However, it is worth noting that the baseline for all these opportunities is open, transparent, quality communication and tracking the technical debt, ideally on an ongoing basis.

Yet, the software craftsmanship has to sometimes deal with situations where the PM or a team leader is **pressuring** developers and asking for **impossible commitments** on the scope delivery so some kind of arbitrary deadline is being satisfied. And such situations origins may trackback even as far as the selling the service process, where the impossible deadlines were promised in order to close the deal.

It may be the case that you can’t prevent your salespeople from promising impossible things to your customers or there is another process in your organisation that lets such things slip, but what you could do is to at least try to **counter** the aforementioned with other processes that **allow for debt paying.**

And you can start by ensuring you have an environment where developers are transparent with you in terms of what kind of **shortcuts** are required to be made in order to fit the imposed time constraints.

Paying the technical debt here would mean starting with strictly tracking these aforementioned shortcuts and reserving some time in the roadmap/schedule to get rid of that debt. After all, paying the technical debt starts by recognizing it.

Basing on the things we have learnt so far, we can now move on to discussing the techniques of debt measuring and their use in the prioritisation, monitoring and prevention of technical debt.

Technical Debt - Identification, Measurement And Prevention

\[TOC\]

In software development, technical debt is almost always present. It’s usually hard to quantify, requires special coding techniques in order to be paid off and is often tricky to explain or show to a non-developer in a team or to management/stakeholders. Technical debt and the software entropy it brings **lie beneath a lot of software making failures.**

My role as a client and team lead is to communicate technical debt’s existence and its implications to the stakeholders or product owners in order to help them manage it. Thus allowing the decision-makers to **achieve business goals and let their organisation flourish.**

I start such a conversation by making sure that everybody is on the same page when it comes to what technical debt is and where does it come from.

## What exactly is technical debt?

![Img](https://a.storyblok.com/f/86602/720x359/27ffb4bad4/what-exactly-is-technical-debt_obszar-roboczy-1.jpg)

The management, stakeholders, the product owner - these people drive the decisions on where to put focus on when it comes to using developer resources. May it be new features, promised on the new marketing campaign, or just keeping the web application product up to date with the ever-changing business domain surroundings. The priorities may vary.

Yet what is common for a well-operating business, the priorities and goals have to be set straight, however it is often the case that the decision-makers are often the people who **understand the technical debt the least.**

Let’s start with the definition I found on [Wikipedia](https://en.wikipedia.org/wiki/Technical_debt) and see if it comes handy: *“**Technical debt** (also known as **design debt** or **code debt**, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.”*

Of course, there is more to it in the original article, several sections cover various aspects of the technical debt and the resulting cruft in software development. The definition is pretty decent as it highlights the cost, the need for rework and time limitations.

Though it is a bit stiff, technical mumbo-jumbo rich, and not so useful when it comes to reimagining how the everyday development routine looks like, it shows how choices made during a software development iteration, like a sprint, translate to the creation of technical debt. Which in turn, results in software entropy in the form of a new, yet [legacy code](https://selleo.com/blog/fixing-and-updating-legacy-code).

My intention **isn’t to provide a more accurate definition than Wikipedia**, but to cater one for people who do not necessarily appreciate the amount of technical jargon used for conceiving the definition altogether

Hence I do not start the conversion with “technical debt is a concept reflecting the implied cost of...” as it is far more useful to define it as a growth **factor** that makes every new **requirement or change harder** (and more costly) to implement (if not kept in check) to the point where shipping that new change is **just impossible** - an idea easily demonstrated with a line chart.

![Img](https://a.storyblok.com/f/86602/720x359/f6c58edd8e/technical-debt-wykres.jpg)

Also, it is far more useful to talk about various project development and maybe “life in general” situations, **both a developer and a non-developer person can relate to**, to show how these various choices impact our operation capabilities short and long term.

## Where does technical debt come from?

The technical debt origins are usually of three kinds: the unavoidable, the accidental and the deliberate. Hence we talk about types of technical debt, with an important note though that they usually come up with different mixes and flavors.

![Img](https://a.storyblok.com/f/86602/720x383/2c907d790d/unavoidable-technical-debt.jpg)

### Unavoidable technical debt

One of the very basic laws of nature is that things left to themselves, without proper attention and care - **decay**. This is true for many aspects of our life: relationships and love, items and our belongings and… software. A truth that I found is much easier to see and comprehend outside the domain of software systems.

Because, let’s imagine something typical: you’ve just built up your web application. What it means is there are two elements in place: the work from the MVP version of the web application including the code behind your business logic as a first element and the code and setup behind the infrastructure, required by your web app in order to operate, as a second.

And now that the web app is up and running you direct the focus on the business part, finally being able to iterate over the features and functionalities you had in mind, leaving the infrastructure part behind. Because **why focus on something that’s already done**, right?

When we think about cars we use for our everyday commute, it is normal for us to think or accept the fact that once in a while we need to park that car at the mechanic workshop because we feel that things aren’t working the same as they used to (“what’s that strange sound coming from the engine?”, “my brakes started squeaking, better check that out” and so on) or because they simply break. There is also a law in place in many countries requiring you to put your car through special maintenance procedures periodically.

Things break because there is a natural process of the item's element wearing off during use, but also things can break if we forget about the proper maintenance, like changing oil…

<Baner name={software-development} />

Now, you may wonder why I came up with that elaborate metaphor with cars.

Your web application is like a car. There are **2000$** cars and **2000000$** cars. What they share in common, is that **they need maintenance**. In the same manner, your web application requires a DevOps engineer’s attention, from time to time.

Using a car metaphor, a car would break from rust. In the web application world the app may become non-deployable because the code is “too old” (it uses libraries that are **no longer supported** on the operating system level or by particular infrastructure elements - often the case in cloud solutions) or the infrastructure can no longer support the web application code (the new and up to date web app libraries require the infrastructure and system counterparts that are **not present in the old and legacy infrastructure**).

![Img](https://a.storyblok.com/f/86602/720x383/6eac9824bc/accidental-technical-debt.jpg)

### Accidental Technical Debt

It’s often the case that web applications evolve greatly from their original and initial MVP form. The functional requirements change, however the design sometimes struggles to follow, despite even the best efforts made by the team of programmers.

Once again let's use our imagination. The case is as follows: in order to solve some business problem for a user, you need to ask that user for a pretty big chunk of data. Following some good UI/UX practices you avoid a pitfall of achieving so with one, big form on the page, that requires a lot of scrolling through in order to get to the submit button. The decision is made to organize and shape such a big form into a five-step wizard. The development team takes such a requirement and designs a nice solution where code structure follows the aforementioned, arbitrary choice of gathering user input in that certain way.

Yet, for whatever reason the original design doesn’t meet the user’s needs, so the idea is iterated upon and after **several** iterations of changes to the wizard flow you end up with a wizard which has three steps, including one optional.

<ReadMore> Read also: [What Is Digital Transformation And How Can It Change Your Business?](https://selleo.com/blog/what-is-digital-transformation) </ReadMore>

A natural choice was to build on top of existing wizard functionality, instead of starting from scratch. After all, there is already written code that could be potentially re-used right?

And this is true in a lot of cases. However, what is easily overlooked here, is that we’re trying to reuse the code which was **designed** **for a different flow.**

And it is inevitable that as you shape the old design into a new one, the old, legacy design choices will affect the subsequent one, manifesting themself as various quirks to polish or to workaround. The things that just wouldn’t be there if you would just start designing the final solution or at least started further down the road here. The things that slow the programmer down. The accidental, outdated design technical debt.

But why do we all once in a while hear from a product owner a question: “well, you have all the pieces coded right? It’s just about gluing it altogether differently. Should be simple, isn’t it?”. Now you know why it’s not that simple, as you designed your original code with something **different** in your mind.

The accidental technical debt origin points to the **utter importance** of doing proper “homework” when it comes to prototyping and coming up with the solution together with the target user base. Plus the need for the cooldown (refactoring) phase is rehearsed after each iteration of an ever-evolving (possibly successful) web application.

![Img](https://a.storyblok.com/f/86602/720x383/397ac233a7/deliberate-technical-debt.jpg)

### Deliberate Technical Debt

In [“](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)*[The Clean Code](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)*[”](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) book Robert C. Martin introduces his reader to various situations he encountered in his career as a developer or a leader of a team of developers. He often chooses a literary form of a dialogue between hypothetical people, like a conversation between a developer and a project manager.

I found it amusing that one of the typical scenarios he has chosen several times was a story where somebody from management (i.e non-technical person) promised something in terms of software delivery (to the group of stakeholders or marketing department or just client base) and the trouble arose when a developer person in a dialogue informed his peer that “it cannot be done in a given time schedule”.

In these dialogue-stories a management person urges the developer to make a commitment to deliver the software feature in a shorter amount of time than anticipated by that developer. Just as if the provided delivery estimation was a kind of whimsy thing from a developer or a lack of goodwill in terms of achieving some company goals.

The developer in these dialogues is usually presented as a person who is doing good craftsmanship and high-quality code, but also a person of his word, who dislikes making promises and commitments that cannot be met.

<Baner name={contact-us} />

The book author focuses mostly on developer assertiveness (giving tips about that to the reader), with some additions like elements of scope negotiation, but what I was missing during the lecture was people talking about **what it really means to deliver something in one week when the estimation is two** (weeks).

Developer’s strain and poor happix are one thing, but we’ll put that aside. What I would really like to see in such a conversation is a clear message, that the **next time estimation for another would be either higher or less accurate and reliable**, because of the technical debt incurred.

And that reluctance of a developer when it comes to pushing the deadlines (and making shortcuts) is in the **best interest of a running business and its long-term goals.**

A company or an organisation can stay competitive vs other market players only if it **manages to keep the deliberate technical debt in check**. The deliberate technical debt is easiest to manage out of the three types of debts, as you usually **precisely know** when you take it: by requesting it or by imposing it on your developers.

## Summary

Generally speaking, we can say technical debt describes what happens when a development team expedites the delivery of functionality or software which later needs to be refactored. In other words, it’s a result of prioritizing speedy delivery over high-quality code.

We distinguish three types of technical debt: unavoidable, accidental and deliberate and each of them is caused by different circumstances, therefore, can be avoided or limited by taking different actions.

Being on the same page when it comes to what technical debt is and where it comes from enables us to discuss the approach we can take in order to **stay on the right side** of the debt when building and maintaining the software systems like a web application with accompanying infrastructure is.

Now that we have covered the most important aspects of technical debt and the role of proper communication when it comes to that phenomenon, we can move on to covering various techniques I found decent and working when it comes to dealing with technical debt. My next article will take you through those battle-tested methods, so stay tuned if that sounds interesting to you.

Technical debt and the software entropy it brings lie beneath a lot of software making failures. Read this post to find out what technical debt is and where does it come from.

Read our articles on Selleo Blog

Business

Technology

Technical Debt - Identification, Measurement And Prevention

Technical Debt In Software Development - The Definition And Why It Matters

Tell us about your project