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
- Give the client options. Don't assume they always want the fastest possible solution. There is nothing clever about solving an issue in ten minutes if it causes hours of problems later on. In the shipping module example, the client most likely wanted to be able to manage the shipping module themselves; much like all the other shipping modules in the system. Whilst they may have accepted the quick solution, they aren’t yet aware of the problems later on. Why would they be?
- Give yourself time to solve the problem. It's a simple and obvious point, but it's tragically common for a developer to be tasked with fixing a bug without time being allocated to it. This is not fixing a typing error in a word document, but modifying a process which the client relies on for their business. Any code tweaks naturally need testing, and this testing time certainly adds up.
- Strictly monitor the house styles of the framework you are using. Ensure that code is placed in predictable places and adhering to the patterns of the framework. The more developers are involved, the more management is required on this, but ignoring the issue leads to codebases which eventually no one wants to touch.
- Be aware that a time estimate is an estimate. A developer may give an estimate for a problem but unforeseen circumstances can affect this. To use the fabled car analogy, if a car mechanic gives a time estimate to fix a clutch but they find the bolts have been rounded off, it is going to take more time and you will not get the car back later that day. It is not the mechanics' fault. Codebases are complex; libraries go out of date or lose compatibility with one another, computers have problems, and developers are human.
- Don't reward a culture of fixing the most bugs, or solving bugs in the shortest time.