Although technical debt occurs in almost every software system, for many people it is still a bit of an elusive term. What is technical debt exactly, and can you prevent it from ending up in your systems? AG Connect investigated it based on six questions.
The term “technical debt” was first used in 1992 by Ward Cunningham to make a comparison between technical complexity and financial debt. When you borrow money, you have an advantage in the short term, namely more money. But in the end you have to pay back the entire amount, often with interest.
Pretty much the same thing happens with technical debt. When you perform a technical implementation or create a software design, that will give you some advantages in the short term, such as saving time. But in the long term, that same implementation can cause a delay if you want to change the code or add something new.
“The metaphor is primarily intended to show the importance of software quality, and the costs when your software quality is poor. You can’t keep asking programmers to do something within five hours, because then the quality will deteriorate and it will ultimately cost you more time and money to add something,” says Jurgen Vinju, leader of the Software Analysis and Transformation research group (SWAT) at the Center for Mathematics and Computer Science (CWI) and part-time professor at Eindhoven University of Technology.
Fortunately, you can also redeem technical debt: you can pay off the debt by taking the time to implement the code in a proper and optimal way.
If you are dealing with technical debt, you almost always have to deal with a piece of code that isn’t written or implemented in the best way. “There are so many different ways to add or adapt something to software, but there are only a few high quality solutions. These solutions aren’t often picked by developers,” according to Werner Heijstek, Principal Consultant at the Software Improvement Group (SIG) and lecturer at the Leiden Institute for Advanced Computer Science (LIACS).
According to Vinju, it’s about how much thought has been given to future changes. “If I already know that there is a chance that someone will start using a different database system in five years, I will already make sure that the current database is attached to the software system as loosely as possible,” explains Vinju. “But if you make a wrong estimation or don’t just have the time to even make a proper estimation, then you’ll create a connection which is difficult to disconnect again. In the meantime, more and more systems will rely on that same software. In a few years it will take much more effort to disconnect the database system.”
But there is also technical debt that occurs by accident. “You can divide technical debt into two categories: intentional technical debt and unintentional technical debt,” Heijstek explains. With the intentional variant, a conscious choice is made to create technical debt, for example to save time on a project with a fast approaching deadline. Something else is going on with unintended technical debt. For example, you may be dealing with developers who lack certain skills, and because of that a problem is not solved in the best way. ”
No, technical debt is really something else than an error or bug in the code. “An error will tell you something about the behavior of software. You’ll notice that the software behaves in a way that it wasn’t supposed to,” Heijstek explains. “Technical debt is about internal quality, about how software is created. It is actually the sum of everything that holds you back to optimally work on a software system. ”
Technical debt isn’t therefore necessarily an error or bug: the application can do exactly what it is supposed to do, even if there is a technical debt. However, such a debt can cause errors in a program. If it’s difficult to adjust something, it could occur that you’ll accidentally break something.
Cunningham already discussed the problems technical debt can cause when he first described his comparison. “A little debt speeds up development, provided that it is repaid quickly with refactoring. The danger arises if the debt is not going to be repaid. Every minute spent on code that’s not optimal for the programming task of that moment, counts as interest on that debt. “
Technical debt leads to worse software maintainability. “For example, it costs more money to make a change to a system or you need eight of your ten developers to ensure the system is maintained and continues to work,” according to Heijstek. Moreover, if the code is not quickly corrected, you forget how and why you had done something again. The longer you wait, the more time it takes to repay the debt.
When your system doesn’t score well on maintainability, that also means it can take longer before an error is resolved. After all, if the system cannot be properly maintained, it takes longer for the exact problem to be found and to adjust the code to actually solve the problem. Moreover, a system can ultimately be consumed by so much technical debt that it can no longer be adjusted and will go out-of-service.
Another consequence may be that almost no one understands how the system exactly works, according to Vinju. “For newer staff, It is more difficult to learn this system and its code. So when older staff who still understand how the system works eventually leave the company, nobody knows how the system works anymore. And it also has an effect on your personnel policy: you’re stuck with the people who do understand how the system works. ”
Technical debt can be avoided to a certain extent. According to Heijstek, for example, it is helpful when there are clear and central guidelines about how developers should deal with software development and what exactly is expected. “It is much cheaper to write direct code that is easy to maintain than to write code with a lot of technical debt,” thus Heijstek.
It isn’t often entirely clear what good software quality is. “What good or bad software is, depends very much on the audience,” explains Vinju. “The meaning of high quality for one person is low quality for another. This is partly due to the programming languages you are used to, the lososche paradigms you use and the education you have completed. There is not one universal, objective measure of what is good and bad. “
Heijstek nuances Vinju’s statement by adding that quality can indeed be measured universally. “Different systems can certainly be compared with each other with an objective measure.” In addition, there are tools that can support you, tell both Vinju and Heijstek. These tools indicate, for example, how well the system can be maintained and how scalable it is. However, the tools are not intended to strictly control all code and systems, Heijstek mentioned.
“If you know the facts about risks and code quality, you can act on them. How you act, that’s another question. It’s not about checking. That is not the relationship you want to build with your developers. You have to help them to prevent technical debt. It is important that it is really clear what exactly you want to achieve, and that you use tooling to support the developers. ”
Technical debt is often seen as something bad that needs to be resolved immediately. But that is not always the case. “You should simply ignore the bulk of the technical debt,” Heijstek stated. “Partly because technical debt occurs in your legacy systems. But the presence of technical debt can also be just fine if you don’t need to work on that part of the software.”
Vinju also thinks that technical debt is not always a big problem. “Some people borrow money to do something they would not have been able to do otherwise. That also applies to technical debt,” he explains. “The feedback cycle with a customer, for example, becomes much shorter if you quickly deliver a first version of a product and come back later to improve the code. By then you’ll know if this is what the customer wants. That is much closer to the agile ethos: first make something that works, instead of making something for a future that might never appear. ”
You can also over-design: “If you need to take all different future scenarios into account, you will ultimately be unable to do anything. You’ll need to ask questions about everything. What if the programming language eventually changes? What if we merge? You cannot take everything into account. So you have to think about the context and talk with stakeholders, and make choices about what is and what is not relevant in terms of expectations. ”
When tackling technical debt, it is therefore important to always consider which part you are dealing with. According to Heijstek, three factors are important: “You have to look at which code you touch a lot or will touch a lot, which is of low maintainability and whether there is code with low risk that something will break when you refactored it.” Code or pieces of software that meet these factors are a debt repayment candidate. In this way a shortlist of projects is created, and you can leave the rest behind.
Source: AGConnect – 03/03/2020 (Author: Eveline Meijer, Editor AG Connect)