The laziest little pig said he’d build a straw hut.
«It will only take a day,’ he said. The others disagreed.
«It’s too fragile,» they said disapprovingly, but he refused to listen. Not quite so lazy, the second little pig went in search of planks of seasoned wood.
«Clunk! Clunk! Clunk!» It took him two days to nail them together. But the third little pig did not like the wooden house.
«That’s not the way to build a house!» he said. «It takes time, patience and hard work to build a house that is strong enough to stand up to wind, rain, and snow, and most of all, protect us from the wolf!»
The three little pigs
Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution. [definition taken from here]. Like the tale of the three little pigs, software is often written in order to be released as soon as possible, regardless of the medium and long-term implications of those decisions. This is not necessarily to blame the programmer, many times the line is lowered from the top controls in order to meet the expectations of release dates of versions. We can even say that they are not always bad decisions. The important thing is to keep it in mind and not forget it in the voragine of daily work and ambitious sprints.
As with any type of debt, if it is not paid on time, we will have a bigger problem in the long run. There is an excellent article in detail on this topic on the following link: https://www.fluentcpp.com/2020/01/17/technical-debt-is-like-a-tetris-game/
Causes of Technical Debt
There are countless causes that generate a technical debt on a software project. Let’s analyze the most common:
- Business pressures: This is one of the most common. The business needs to release the version and pressures the technical department to meet the date ahead of schedule.
- Documentation: Most companies see documentation as a luxury. But not having a documented code is, without a doubt, a technical debt that in the future will be paid very dearly.
- Last minute changes: It’s impossible to imagine a project where there are no such last-minute changes, they are inevitable. But it’s important for us to consider adding the necessary documentation and code enhancements after the deployment.
- Lack of Design Definitions: when development starts before any design is settle. This is supposedly done to save time, but the refactoring of this code without design generates a great technical debt in the medium or even in the short term.
- Poor Understanding of Technical Debt: this ocurrs when the business is blind to this issue of tech debt and decide to ignore this tasks in all the sprints of the project.
Types of Technical Debt
Martin Fowler distinguishes four debt types based on two categories: reckless vs. prudent and deliberate vs. inadvertent.
So, what is the solution? It’s quite simple: just pay off the debt by doing the tasks you owe the project.
Well… to be fair, it’s actually not that simple. It’s difficult to estimate the amount of work needed to pay off the debt if you lack of a good documentation. In our experience, the best way to do this is to pay off the debt little by little. It is highly unlikely that you will be able to put together 100% dedicated sprints to pay this technical debt, but it is likely that you can include some code improvement tasks in all sprints to shorten the problem. In this way, you will ensure that the interest on the debt does not accumulate, without the project suffering on its schedule.