Technical debt - debt coding - a problem arising from the presence in the present of the fact of unfinished work in the past

Technical debt (also known as coding debt ) is a metaphor-neologism, denoting a problem arising from the fact that there is unfinished work in the past, or postponing the future work that needs to be done in the present. Also, technical debt is the inevitable consequence of poor forethought of the system structure, poor software architecture, or poor software development, as a result of which, the work done already requires rework. Debt can be considered in the form of work that needs to be done until the task can be considered completed. If the debt is not repaid, it will continue to increase, which will complicate further development.

As soon as there are changes in the program code, it is often necessary to make changes related to them in other parts of the code or documentation. Other necessary but incomplete changes are considered a debt that must be “paid off” at some specific point in the future. Just like a financial debt, these unfinished changes impose a penalty, which can make the further development of the project more time consuming. Although this term is used primarily in relation to software development, it can also be applied to other areas.

Content

• 1 Reasons
• 2 consequences
• 3SM. also

The reasons

Common causes of technical debt (maybe several):

• The pressure of a business , when a business requires you to release something before all the necessary changes are made, an accumulation of technical debt will appear, including these unfinished changes.
• Lack of processes or understanding when a business has no idea of ​​technical debt, and makes decisions without taking into account the consequences.
• The absence of loosely coupled components created , when the components are not based on modular programming, the software is not flexible enough to adapt to changing business needs.
• Lack of tests - encouraging rapid development and risky fixes (“crutches”) to correct errors.
• Lack of documentation , when the code is created without the necessary supporting documentation. The work required to create supporting documentation is also a debt that must be paid.
• Lack of interaction , when the knowledge base does not spread throughout the organization and business performance is affected, or younger developers are incorrectly trained by their mentors.
• Parallel development at the same time in two or more branches can cause an accumulation of technical debt, which ultimately will need to be replenished to merge changes together. The more changes that are made isolated, the greater the final debt.
• Deferred refactoring - while project requirements are being created, it may become obvious that parts of the code have become cumbersome and need to be reworked to support future requirements. The longer the refactoring is delayed and the more code written using the current state of the project, the more debt is accumulated, which will have to be paid at the time of the subsequent refactoring.
• Lack of knowledge when the developer simply does not know how to write quality code.

Effects

"Interest payments" appear both in local development and in the absence of technical support from other project developers. The continued development of the project may in the future increase the value of "debt repayment". Payment of debt occurs through the simple execution of unfinished work.

The accumulation of technical debt is the main reason for exceeding the deadlines for the implementation of projects. It is difficult to estimate exactly how much work needs to be done to repay a debt. An indefinite amount of unfinished work is added to the project with each change. Deadlines "burn" when the project comes to understand that there is still much more unfinished work (debt) than time to complete it. In order to have predictable release schedules, the development team must limit the amount of work to be done to one that would minimize the amount of work that was not completed (debt).

“While the developing program is constantly changing, its complexity, reflecting the deterioration of the structure, increases until the work on supporting it is done.” [1]

- Meir Manny Lehman, 1980

While Manny Lehman’s law of increasing complexity has already argued that the constant development of programs increases their complexity and deteriorates the structure while they are being worked on, Ward Cunningham made the first comparison between technical complexity and debt in a 1992 report:

"Creating a first time code is like going into debt. A small debt speeds up development until it is paid in time in the form of rewriting ... Danger arises when the debt is not repaid. Every minute spent on a not-quite-correct the code is taken into account as a percentage of this debt. Entire engineering organizations may be involved in downtime due to the debt load of unconsolidated sales, object-oriented or other. "[2]

- Cunningham, Ward, 1992

In his 2004 article, Refactoring Using Templates , Joshua Kerievski presents, as an argument, a comparison of the expenses spent on resolving issues related to architectural negligence, which he describes as “structure duty.” [3]

Actions that may be delayed include documentation, writing tests, paying attention to “TODO” comments, anti-compiler warnings, and static code analysis warnings. Other cases of technical duty include a knowledge base that is not distributed within the organization and a code that is too confusing to be easily modified.

In open source software, postponing the posting of local changes to the main project is a technical matter.

see also

• Bus factor
• Big lump of dirt (eng.)
• Data degradation (eng.)
• TODO, FIXME, XXX (English)
• Software Entropy (English)
• SQALE (eng.)