Technical Debt Measure
(Redirected from Tech Debt Measure)
Jump to navigation
Jump to search
A Technical Debt Measure is a organization measure of the opportunity cost of not performing some specific IT enhancement project.
- AKA: Code Debt.
- Context:
- It can (often) reflect the implied cost of additional rework caused by choosing a simpler solution now instead of using a better approach that would take longer.
- It can range from being a Narrow Technical Debt Measure to being a Holistic Technical Debt Measure (that is cross-organizations
- It can be reduced by a Tech Debt Reduction Program.
- It can be correlated to Software Development Productivity.
- ...
- Example(s):
- Estimated Effort Measure: How much extra work will be required to develop systems in the future by not investing in the technical framework.
- Estimated Delivery Delay Measure: The delay that will be introduced in future projects due to unresolved technical debt.
- Tech Debt Quality Impact Measure: The potential degradation of software quality due to shortcuts taken in the current development process.
- ...
- Counter-Example(s):
- Scalability Performance Degradation Measure: System X is slowing down because we have twice as many customers as it was designed for.
- Scalability Limit Measure: The system cannot support adding more users or features due to architectural limitations.
- See: System Design Limit, Software Entropy, Debt Measure, Software Architecture, Codebase, Continuous Improvement.
References
2021
- (Wikipedia, 2021) ⇒ https://en.wikipedia.org/wiki/technical_debt Retrieved:2021-9-9.
- Technical debt (also known as design debt or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate "interest", making it harder to implement changes. Unaddressed technical debt increases software entropy. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g. as a proof-of-concept) is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the ramifications, which results in insufficient prioritization of the necessary work to correct it.
As a change is started on a codebase, there is often the need to make other coordinated changes in other parts of the codebase or documentation. Changes required that are not completed are considered debt, and until paid, will incur interest on top of interest, making it cumbersome to build a project. Although the term is used in software development primarily, it can also be applied to other professions.
- Technical debt (also known as design debt or code debt, but can be also related to other technical endeavors) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer. As with monetary debt, if technical debt is not repaid, it can accumulate "interest", making it harder to implement changes. Unaddressed technical debt increases software entropy. Similarly to monetary debt, technical debt is not necessarily a bad thing, and sometimes (e.g. as a proof-of-concept) is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the ramifications, which results in insufficient prioritization of the necessary work to correct it.
2016
- https://www.sei.cmu.edu/community/td2016/
- Technical debt is a metaphor that software developers and managers increasingly use to communicate key tradeoffs related to release and quality issues. The Managing Technical Debt workshop series has, since 2010, brought together practitioners and researchers to discuss and define issues related to technical debt and how they can be studied. Workshop participants reiterate the usefulness of the concept each year, share emerging practices used in software development organizations, and emphasize the need for more research and better means for sharing emerging practices and results.
- Techniques and tools for calculating technical debt principal and interest
- Visualizing technical debt.
- Analyzing technical debt.
- Measuring technical debt.
- Relationship of technical debt to software evolution, maintenance, and aging
- Economic models for describing technical debt.
- Technical debt and software life-cycle management
- Technical debt within the software ecosystem
- Technical debt in designs and architecture
- Technical debt in software models
- Concrete practices and tools used to measure and control technical debt
- Technical debt is a metaphor that software developers and managers increasingly use to communicate key tradeoffs related to release and quality issues. The Managing Technical Debt workshop series has, since 2010, brought together practitioners and researchers to discuss and define issues related to technical debt and how they can be studied. Workshop participants reiterate the usefulness of the concept each year, share emerging practices used in software development organizations, and emphasize the need for more research and better means for sharing emerging practices and results.
2015
- (Sculley et al., 2015) ⇒ D. Sculley, Gary Holt, Daniel Golovin, Eugene Davydov, Todd Phillips, Dietmar Ebner, Vinay Chaudhary, Michael Young, Jean-Francois Crespo, and Dan Dennison. (2015). “Hidden Technical Debt in Machine Learning Systems.” In: Proceedings of the 28th International Conference on Neural Information Processing Systems (NIPS-2015).
- QUOTE: ... Machine learning offers a fantastically powerful toolkit for building useful complex prediction systems quickly. This paper argues it is dangerous to think of these quick wins as coming for free. Using the software engineering framework of technical debt, we find it is common to incur massive ongoing maintenance costs in real-world ML systems. ...