Technical Debt: The Ghost of Shortcuts Past, Part 2

This post is part two of my series on technical debt. You can ready the Part 1 here. This post concerns the difficult task of identifying and prioritising technical debt within an organisation.

Recap on technical debt and why it’s important

In my previous post I discussed the concept of technical debt, and the many ways it manifests inside an organisation.

Technical debt can choke a company and rob it of its competitiveness and productivity.

In many regards its a new concept that is poorly understood in business today.

The proliferation of technologies and automation have made its impact ever more significant in the last decade. Today so much more of an organisation’s productivity depends on its code base and technical solutions.

A buggy or badly designed codebase can prevent a company from growing and iterating, cause it to employ many more technical experts than it’s necessary, and generally reduce productivity.

Why is it difficult to tackle

Technical debt is a pernicious issue for several reasons:

Its new so no formal methodology to addressing it, it is also unclear where the responsibility lies for keeping it in check.

Tackling technical debt requires support from the entire organisation, cooperation is needed between technical and commercial staff, mitigation takes resources from commercial concerns.

It is rarely measured and quantified, organisations start tracking metrics related to growth and market share initially, and have difficulty transitioning, in order to track debt related KPIs.

Its impact is difficult to relate to upper management, the impact of technical debt is not felt immediately, it comes with a delay, by the time its impact is felt the causes might be forgotten.

How do you know you have a problem

The individual instances of accrued technical debt might be hard to track, but eventually the accumulation leads to very tangible disadvantages. When you are feeling pressure from younger & leaner competitors, when production cycles keep getting longer, and no amount of new hires can boost velocity. It may be time to have a serious look at your organisations technical debt.

Types of debt

Broadly two kinds of dept requiring different organisational considerations.

1. Architectural Debt

Architectural debt is accrued by the choice of solutions and how they are utilised and integrated.

It used to be that there were only a few vendors for business tools out there and that you essentially chose one and where locked into their ecosystem, this can be both frustrating and comforting, as it is difficult to move forward, but all your competitors move at the same pace.

Today business tools have exploded there are a multitude of options for any task your organisation needs done. These tools can be integrated and utilised in countless ways, allowing for multiple mistakes to occur.

Causes

Architectural derives from high level or lack there of, a common cause is duplication of solutions and data, when there is no consensus within the organisation on what tool tom use ore what data set is the single source of truth, you end up with multiple datasets that eventually become inconsistent.

Bad choices in tools are also common, solutions not fit for purpose that need to be heavily augmented and supplemented, or legacy solutions that lack the functionality necessary for modern use cases.

2. Low level Debt

Low level technical debt occurs in the code itself it is created by mistakes and shortcuts taken by engineers. Since the organisation owns the codebase where low level debt occurs, it is much more susceptible to numerical analysis and can be tracked with KPIs.

Causes

Low level debt can have a multitude of causes, commercial pressure on development teams being the primary one. As discussed in the previous article adding new features and shipping software inevitably takes precedence to diligence, this generates plenty of debt.

Lack of understanding or best practices within the engineering team are also a common source of debt.

How to Get Started

There are multiple metrics in the literature that can be used for tracking technical debt. However those metrics do not reflect the utility of the solution in question or the impact of the debt on your business. For example a the metrics might show a particular solution or code module as being particularly debt ridden, but it might be used by a small minority of people or it might have minimal effect on your core business. On the other hand the metrics might reflect a low level of debt in a solution that is highly critical and impactful.

This is why when addressing debt one needs to take a much more holistic view.

Understand your technical landscape

The first step in addressing technical debt is to understand your stack at a high level. What are the systems you have in place? How do they relate to each other? Who uses them and why?

A view of your overarching architecture

What tools is your business utilising?

How are they connected?

What are the interfaces?

Who are the teams interacting with or maintaining them?

Once you have created a map of your infrastructure it’s time to find out where it’s breaking down.

A view of the underpinning organisation

The various pieces of software and proprietary solutions have their specific users, and hopefully their business owners. Understanding who is in charge and who uses a specific solution is an important part of understanding the impact of technical debt.

Assess debt from the end user perspective

The first step in identifying where technical debt has the most impact should be speaking to the people in your organisation that use the various systems and solutions.

The friction point in most processes is the human element and how they interact with your tech.

It is best to start on the architectural level and narrow down the systems that need the most attention.

This exercise will help you understand the business impact of various instances of debt, so you can priorities accordingly.

Start with user identify tasks that require most man hours and elicit the most frustration

Where has your organisation grown in the last few years what tools are generate the most support requests or have required work arounds, have changes been requested but are slow to come?

Once you have the end user perspective you can isolate and rank the components of your architecture based on the urgency of action.

However non technical users will tell you little about feasibility of intervention.

It is now time to view these components from the technical perspective

Assessing from the technical perspective

When we have zeroed in on the issues with the highest business impact, you can begin identifying which ones of those issues can be addressed from a technical perspective.

Talk to your technical team in charge of building and maintaining the components identified.

This way you can start identifying the issues that your technical experts believe are addressable.

Prioritisation

Prioritising is important because targeting the wrong system or problem can demand a lot of effort but produce little impact, it is also important to prioritise an entire module or solution rather than the easiest fixes in multiple places. It would make the impact of the effort easier to track.

By the end of this process you should know where you’re where your efforts will produce the most impact. In my next post I will discuss the various techniques for tackling technical debt and reducing the rate at which it mounds.

Next up

In the final chapter of this trilogy I will discuss the various methods and practices an organisation can employ, in order to tackle existing debt and reduce the rate at which new debt is generated.