When a development team is thrifty or rushed in software development or IT infrastructure planning, these savings end up being paid off in the form of technical debt. Technical debt refers to the consequences of deliberate or inadvertent negligence, mistakes, or deficiencies in relation to the code. Subsequent corrections and maintenance measures slow down productivity and generate high additional costs . What must be taken into account to avoid technical debt in software development?
In 1992, Ward Cunningham, programmer and co-author of the Manifesto for Agile Software Development , introduced the metaphor of technical debt. With this concept, Cunningham wanted to illustrate the importance that refactoring, that is, the regular correction of the code, has for the software. Only in this way is it possible to avoid that a software always generates more debt due to the growing operational and structural deficiencies ..
The term debt also implies interest, since technical debt is relevant for the contracting companies especially from a financial point of view. Technical debt not only means more effort and lower productivity due to subsequent maintenance measures, but also more costs. The more a team's management neglects to maintain a faulty IT infrastructure or application, the more interest the debt generates and the more expensive the code corrections become.
With technical debt, deliberate or inadvertent errors, gaps, and deficiencies in the code that are generated by lack of communication, team management, qualification, or hasty product release and that are constantly increasing due to lack of refactoring are defined ..
According to Ward Cunningham, the technical debt arises due to deficiencies in the code that, due to lack of time or budget , force a faster solution to the problem, although it is deficient. Thoroughly and thoroughly written code is laborious and time-consuming. For this reason, developers sometimes go for dirty code in order to save time and effort. But this saving is paid for with debt.
For Cunningham, this economic aspect of programming is not unusual or unnatural. In the event that technical debt is not offset by refactoring and code is not regularly optimized, development will eventually be interrupted or halted due to metaphorical interests..
Martin Fowler, author of Refactoring: Improving the Design of Existing Code , concretized Cunningham's metaphor and subdivided technical debt into four types, which he represented in the technical debt quadrant :
Reckless debt
Prudent debt
Deliberate debt
Involuntary debt
According to Cunningham and Fowler, technical debt can be generated both deliberately and inadvertently. Since technology and programming include continual revisions and improvements , it is virtually impossible to avoid code stench and code erosion . The software also ages and, in the absence of updates and refactoring, it also creates debt. In most cases, however, technical debt is due to financial decisions or deliberate or inadvertent programming failures.
Although technical debt generally always has the same effects on software development, the causes can be very varied. Here we present them:
Ward Cunningham not only defined the metaphor of technical debt, but he is also a co-author and first signatory of the Manifesto for Agile Software Development . The goal of this software development philosophy is to encourage more flexible and productive application development and publishing through principles and axioms.
Rather than spending long periods of time tied to large projects, smaller, more independent teams strive for shorter work phases and faster releases of smaller projects such as applications, program parts, and updates. .
Agile software development results in teams writing and modifying code in small steps, and work phases being completed faster. When the focus is on speed and productivity, the danger of producing dirty code and thereby racking up technical debt increases . Especially when agile software development doesn't go hand in hand with refactoring, debt inevitably increases.
The effects of technical debt correspond to those of loans in the financial sector. If the debt is not reduced on a timely and regular basis, interest is earned , which is shown in the form of slowed development, decreased productivity and increased costs.
Therefore, it is in the interest of customers to accompany the long-term development with a comprehensive quality management process , so as not to have to pay for the speed and savings in production and product publication with costly post-correction of errors or even a stop in development.
Due to new technologies and evolving approaches within software development, it is not possible to avoid technical debt completely. In fact, it is even accepted in order to publish programs and applications regularly and quickly and not to tie teams to projects for a long time. However, there are preventive measures to avoid or reduce the generation or growth of debt:
