Technical Debt Measure

From GM-RKB
(Redirected from Technical debt)
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.



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.


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.

2015