What is the Technical Debt?
Can we reduce costs by asking programmers to hurry up and cut corners? Do programmers overreact when they ask more time to clean the code?
Early in this year, I published an article with 5 simple rules to manage technical debt (It is not ok me to say that, but those rules are really effective). In that article, I did not explain what was technical debt, but, after some comments and some conversations, I decided that I have to explain what Technical Debt is.
The General Misconception
Usually, when we talk about Technical Debt, people think of borrowed time. It seems that we can borrow some time to deliver earlier, in exchange for returning that time later. But it is not that simple.
A tool that helped to popularize the term of Technical Debt is SonarQube. This tool analyses the source code of a repository, looks for patterns, and, according to their algorithm, reports an amount of the Technical Debt to repay in time units.
The part about how the Technical Debt is created is easy to understand: developers rush to deliver, take shortcuts, cut corners, and the code ends in an awkward way for developers. But, what happens once the Technical Debt is created? Or in other words: When we have to…
