Technical debt: a detailed overview of the good, the bad and the acceptable
Each person has their own beliefs about technical debt, but the whole discussion can be summed up in only a few words: new technical debt is good and old technical debt is bad. “If only it were that easy,” some insinuate.
Technical debt is, more often than not, seen as a huge no-no in any development process. Although a growing pile of technical debt does suggest that a project is not going well, it doesn’t always predict a headache. There are many reasons why technical debt may occur, but one that is usually on every developer’s lips is “pressure,” especially if there is business sense in writing code that is not clean or maintainable, which means that to attain a short-term goal, one is allowed to write code that is not so good and fix it later.
Technical debt —Going back to its roots
The term “technical debt” was coined by Ward Cunningham in 1992 and referred to being ok with releasing software earlier. The advantage of releasing an incomplete product is the early feedback which allows project members to understand not only the domain, but also the users’ actual needs. Ward explained that the benefit gained by releasing the software before it’s ready (from a qualitative perspective) is like taking out a loan which will have to be repaid by refactoring the domain model at a later time. Interest will be paid in the form of constantly slowing development until the refactoring occurs.
How to solve technical debt
The first step in putting an end to technical debt is to acknowledge its presence, even if it is legacy code that got you into trouble. Another simple solution is to ask yourself how you feel about the quality of your code; you know what needs to be changed and you know if you have already collected some technical debt without realizing. A third solution would be to rely on the people with stellar skills in writing clean code and a fourth fix would be to give pair programming a chance. Regardless of your choice, what matters is to know that you have technical debt and to take care of it as soon as possible.
When is technical debt good?
The cost of accumulating technical debt is sometimes less significant than the cost of having to release the product at a later time. If your team must release a product in time for a holiday, implementing something fast is the right thing to do —better than missing a possibly huge opportunity. The other side of the coin is that questionable code quality will inevitably result in a slower recovery process.
SEE ALSO: Technical debt is not a unicorn
As long as you know the amount of debt you already have and how long it would take to get rid of it, there is no tragedy in accumulating some debt. Tracking legacy code will come in handy at a later time because it will not stand in the way of future developments. However, the longer you allow your code to be unclean, the bigger the repercussion it will have, starting with more bugs and ending with the natural process of forgetting how it was originally implemented. The problem with legacy code is that one cannot really pinpoint the good code or the parts that are causing all the problems. Therefore, it’s harder to solve the problems.
If the members of your team understand that sacrificing the code’s quality for the sake of a short-term goal should be an exception and not a habit, technical debt should not be seen as a burden.