Lecture
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.
Common causes of technical debt (maybe several):
"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.
Comments
To leave a comment
Software and information systems development
Terms: Software and information systems development