© James Edgeworth 2018
Development Published 01 Sep 2017

Technical Debt

Technical Debt is an unknown term to most people, but surprisingly to a lot of developers and web agencies despite its prevalence.

As a basic example - when a developer solves a problem with a quick, tacky solution, the idea is that it causes a debt which must be re-paid further on. This doesn’t directly mean financially, but by extension, this is nearly always the case either to the client, the developer, or web agency.

To illustrate this, let’s assume an e-commerce platform. The client wants shipping to be calculated so that if the customer orders an item from a specific category, it reduces the delivery cost by 10%. The framework is set up so that various delivery methods are written as modules which can be turned on and off via the admin panel. The actual functionality of each shipping module is written in their own classes, or "objects" if you will. When a shipping module is enabled, the framework includes the corresponding class in the carts calculation. This keeps the code nicely separated and relevant to the problem each object is trying to solve.

In our case, the developer implements the requirements by adding the code to the “cart” object as it would take ten minutes to produce the solution there, rather than creating a new shipping method and the various language settings and other bits required by the framework for this to be a proper shipping module. The developer has just created Technical Debt. The solution solves the requirements but will cause problems later on.

Imagine then, that the client wishes to turn off the shipping discount. They can't; they must contact the developer or agency who must comment out the code. If they task another developer on this, they will expect the code to be in the shipping modules and suddenly find themselves with a task of hunting down the haphazard code. This could involve placing test orders and running through the checkout process a number of times whilst narrowing down exactly where the rogue chunk of code comes in which can take significant time. There's a term for that too - accumulating interest. The same issue adds up if any other maintenance is required on this feature. Naturally whoever is trying to solve this will begin questioning what other problems will surface from this codebase.

These problems nearly always happen because the developer has been tasked to fix a bug or quickly implement a new feature without time being correctly allocated. The client didn't specifically ask for it to be a shipping module in this case, but by doing the bare minimum, the developer or agency has caused themselves a bigger problem in the long run.

There are numerous other ways debt can appear which are simply part of the development process - merging branches (and getting code conflicts), developers working in tandem, less experienced developers putting code in the wrong places, a lack of code reviews, and lack of automated testing all of which are better addressed sooner rather than later. The longer the debt exists, the more interest it accumulates.

How to Handle Technical Debt