Drowning in Technical Debt?

What is technical debt?

Often unhappy developers, who work on code that’s hard to maintain, complain because it was written in a hurry. Their managers struggle to meet their deadlines and clients need everything completed as soon as possible, so they can achieve the particular business goal. Sometimes reaching that business goal is far more important for the whole team, than the current quality of the product.

However, every time quality is sacrificed for speed, the whole team incurs something in the product that’s called technical debt. Quality is not just what the users perceive, but it’s primarily the architecture of the solution - it's same as talking about the facade of the house, rather than the foundation on which the house was built. In other words, technical debt occurs when a flawed short-term solution is chosen that will require a solid fix later.

Because technical debt is the result of shortcuts, it adds enormous friction any time people need to coordinate work together across teams. There’s also the unquantifiable costs associated with being slowed down by your systems, and the price you must eventually pay to redesign and simplify systems. Technical debt and its cost tend to only compound over time.

On the other hand, technical debt is also a heavy burden for companies all over the world, who are embracing digital transformation - the use of new technological capabilities. In order for this transformation to happen and enhance the working process with the customers and assist in surpassing (or keeping up) with their competitors, the companies must invest in getting rid of their technical debt.

Is refactoring worth it?

At first blush, business folks might dismiss technical debt as developers’ headache. However, this assumption camouflages the root cause of the issue. In fact, technical debt is largely connected with how the business is structured, what the company priorities are and how teams develop their own processes for getting their work done. The totality of the technical debt - the disparate processes, added software to accommodate them and added work performed to work around them - will continue to expand until the company prevents the growth of disparate coding. Otherwise, the company will face a technical bankruptcy and will probably have to rewrite the whole application from scratch because the code is so bad.

Refactoring is the way to go. It’s the technical equivalent of reorganising a closet. On the outside, everything is the same, but on the inside, if the clothes are streamlined and put in their proper places, the content of the closet doesn’t change yet it’s organised in a way so that next time it’ll be easier to find a certain item.

Refactoring allows you to clean code throughout the software - it all comes down to replacing smaller systems inside larger systems. In ancient philosophy, the concept of replacing all parts of an item, is known as the Ship of Theseus or Theseus’s paradox - if a ship has all of its components replaced, is it still fundamentally the same ship??

Is it possible to go around all the debt hustle?

In order to avoid both - technical debt and refactoring, there should be an engineering culture, processes and language implemented from the get-go. With this approach, a single shared working style can support all teams involved and, if maintained properly and in a timely manner, productivity will be constantly enhanced.

It’s certainly not an easy undertaking. It requires committed leadership and a powerful coalition of people with diverse skills. To be more specific, the company needs a senior business manager - someone with the authority and intelligence, to recognize the need for a common engineering culture, provide resources and align everyone.