Technical debt
Technical debt or technical fault ( english technical debt ) is in the computer science common metaphor for the possible consequences of poor technical implementation of software . The technical fault is the additional effort that one has to plan for changes and enhancements to poorly written software compared to well-written software.
The term "technical debt" is used by computer scientists such as Ward Cunningham , Martin Fowler , Steve McConnell or Robert C. Martin to make it clear to managers and other stakeholders of software projects that postponing measures to ensure and improve technical quality does not accelerate software development, but slowed down - the longer the more.
Technical debt differs from anti-pattern insofar as the decision to run into technical debt can also be made consciously and after weighing the pros and cons, while anti-patterns are always a result of laziness and unprofessionalism.
Examples
| inconsiderate | prudent | |
|---|---|---|
| deliberately | "We don't have time for design" | "We have to deliver quickly and take care of the consequences later" |
| accidentally | "What is a layered architecture?" | "Now we know what we should have done" |
Martin Fowler differentiates between the following types of technical debt: those that you consciously took on, for example to reach a milestone, and those that you unknowingly entered into, for example because the teamdid not followcommon design principles . He also differentiates between prudent and reckless entering into technical guilt. Combined, this results in four quadrants for the classification of technical debt:
The following technical debts are usually included in software development projects (prudently or recklessly, deliberately or accidentally):
- Postponing or not updating technical and specialist software documentation
- Lack of technical infrastructure such as version management , data backup , build tools , continuous integration
- Postponement, waiver or insufficient implementation of automated module tests and regression tests
- Lack of coding standards and code ownership
- Disregard of TODO , FIXME or XXX information in the code
- Disregard of code repetitions and other code smells
- Use of programming anti-patterns
- Disregard of compiler warnings and results of static code analysis
- Failure to correct large or complex code and design
- Incorrect definition or implementation of the architecture due to close coupling , cyclical dependencies of the components or the lack of suitable interfaces and facades
causes
Typically, a combination of the following factors causes technical debt:
- Technical pressure when the client exerts pressure on those involved in the project to have new technical skills delivered quickly and before technical clean-up work is completed. This pressure could take place, for example, through a timely product release .
- Inadequate quality assurance processes if there are no quality assurance processes in a project (or these are not implemented) that continuously measure the technical fault and initiate improvement measures.
- Insufficient technical knowledge to be able to make technical decisions that do not increase the technical debt and, in the best case, reduce it.
- Insufficient communication of the chosen technical solutions and their background. Communication can be done in many ways, such as self-explanatory code, documentation, diagrams, videos, etc.
- Parallel development in your own branches (for example feature branches) leads to increased consolidation costs and thus technical debt.
- Back-to-back refactoring , if further technical aspects are implemented in code parts that are in need of improvement without first implementing the improvements. The more these necessary refactorings are delayed, the more time-consuming they and the implementation of technicalities become.
Technical guilt also builds up - albeit to a lesser extent - if none of the above factors apply. Technical errors arise in software development as well as technical errors. If they are not counteracted by quality assurance measures, the technical debt increases involuntarily with every change and expansion of the software.
"Law II - Increasing Complexity: As a program is evolved its complexity increases unless work is done to maintain or reduce it."
"Law II - Increasing Complexity: As software continues to develop, its complexity increases unless efforts are made to maintain or reduce it."
Alistair Cockburn shows that taking on technical blame goes against one of the core values of agile software development , that of sustainable speed.
history
Meir Manny Lehman's Law was the first to point out in 1980 that unless efforts are made to counter this, complexity grows over time. Ward Cunningham was the first to draw parallels between the complexity of software and guilt in the sense of debt :
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite ... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. "
“Writing software is like taking on debt. Taking on small debts speeds up software development as long as the debts are quickly repaid by a new implementation ... The danger arises if the debts are not paid back. Every minute you spend with incorrect code counts as interest on that debt. Entire development facilities can be brought to a standstill under the debt of an unadjusted implementation (regardless of whether it is object-oriented or not). "
In his 2004 book Refactoring to Patterns , Joshua Kerievsky called the cost of neglected architecture design debt .
Effects
Technical debt has a direct effect on the maintainability of software and thus on the effort for maintenance and further development of the software. In software development, one usually expects that in the course of a project the effort for new or changed functionalities will increase by 60 to 100 times.
Technical guilt is one of the most important factors why milestones in software development projects are not reached or not reached in time. It is therefore assumed that it makes sense to keep the technical debt constantly low in order to achieve predictable milestones and release cycles.
Measurement
It is difficult to calculate exactly how much effort has to be made to work off the technical fault of a software. Every change to the software inevitably increases the technical debt by an indefinite amount.
Software is available to calculate an approximate estimate of technical debt based on quality metrics. For example, SonarQube can calculate the technical debt in monetary units.
Web links
- Ward explains debt metaphor - YouTube (video) and Ward Cunningham's transcript on the origin of the term
- Managing Technical Debt Webinar - Steve McConnel's webinar on technical debt and how to deal with it
Individual evidence
- ^ Robert C. Martin : A Mess is not a Technical Debt. September 22, 2009, accessed on March 30, 2012 (English): “A mess is not a technical debt. A mess is just a mess. Technical debt decisions are made based on real project constraints. They are risky, but they can be beneficial. The decision to make a mess is never rational, is always based on laziness and unprofessionalism, and has no chance of paying of in the future. A mess is always a loss. "
- ↑ Original meaning of the term technical debt
- ^ Martin Fowler: Technical Debt Quadrant. October 14, 2009, accessed on March 31, 2012 (English): “So the useful distinction isn't between debt or non-debt, but between prudent and reckless debt. .. Not just is there a difference between prudent and reckless debt, there's also a difference between deliberate and inadvertent debt. "
- ^ Meir Manny Lehman: On Understanding Laws, Evolution, and Conservation in the Large-Program Life Cycle . In: Journal of Systems and Software . No. 1 , 1980, p. 213-221 , doi : 10.1016 / 0164-1212 (79) 90022-0 (English).
- ^ Alistair Cockburn: Agile Software Development . Ed .: Pearson Education. Addison-Wesley, 2002, ISBN 0-201-69969-9 , The Agile Software Development Manifesto, pp. 222 (English).
- ↑ Ward Cunningham : The WyCash Portfolio Management System. In: OOPSLA '92 Experience Report. March 26, 1992, accessed March 30, 2012 .
- ↑ Joshua Kerievsky: Refactoring to Patterns . Addison-Wesley, Munich 2005, ISBN 978-3-8273-2503-7 (English).
- ^ Roger S. Pressman: Software Engineering . A practitioner's approach. Ed .: Thomas Casson. Mc Graw Hill, 1982, ISBN 0-07-365578-3 , 1.4, pp. 14 , Figure 1.3 (English).
- ↑ sonarsource.com ( Memento of the original from April 26, 2012 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.
