I posted this answer, in response to a question posed by Sonya Natanzon, on LinkedIn
Noteworthy: Sam Holiday, PhD, offered a definition which focuses on the strictly monetary/cost aspects
I've created a poll on LinkedIn that may be of interest.
 |
| [source: Kelvin Meeks, LinkedIn poll] |
My proposed definition:
Technical Debt (noun):
1.
A consequence of the accrual of one or more intentional trade-off
decisions - or the unintentional absence/lapse of governance, oversight,
and maintenance.
2.
Technical Debt may arise from poor design choices, or exigent
decisions, that were contrained by available time, skill, or budget.
3.
Over time, Technical Debt may exhibit unexpected secondary aspects -
such as brittleness, cascading system failures, security
vulnerabilities, degraded performance, incompatibilities, failure to
meet regulatory and compliance requirements, etc.
4.
Technical Debt is usually a symptom of deeper underlying root causes.
- For example:
- Absence of governance;
- Insufficient budgets for long-term maintenance;
- Absence of a technology roadmap;
- Absence of necessary-and-sufficient Application Portfolio Management protocols;
- Absence of End-of-Life (EOL) management;
- Absence of Security protocols for technology management (static code analysis, vulnerability monitoring, vulnerability remediation, etc.);
- Absence of Principles, Policies, Standards, Specifications;
- Absence of appropriate Enteprise Governance mechanisms
(e.g., Technology Governance Board, Technology Reference Model, ...);
- etc.
- Consider
governance in the context of a forcing-function. In the absence of
governance functions (at multiple levels, in multiple dimensions) -
there's only the willingness and initiative of the individual. Judicious
application of governance - can help ensure a minimal consistency in
how some safeguards can be established (and enforced) - to
minimize/avoid unconstrained levels of Technical Debt from accumulating.
When something is no longer supported, constitutes security vulnerabilities, or is no longer compliant - it becomes a type of technical debt.
- Consider if a company selected Java 8, or Windows Server 2008 (at some point in the past), but refused to ever upgrade. Over time, that decision - reflects a type of technical debt (e.g., in which there are consequences, such as: it has security vulnerabilities; it is no longer being actively maintained; security patches are no longer supported, etc.). It isn't a strictly monetary expenditure per month consideration. However, upgrading to a newer version (that is supported) is the technical debt remediation that is required.
-
Not upgrading to the supported version of [x] - which may have
negligable productivity impact - but may expose the company to an
incalculable level of fines, penalties, monetary losses, and reputational damages - if there
is a security breach tied to a known vulnerability that would have been
remediated by upgrading.
6. Technical Debt, by my definition - is not a purely monetary consideration of ongoing costs - but encompasses a more holistic viewpoint of the consequences of failing to remediate some deficiency with respect to the technical aspects of design or implementation - that is a consequence of actions taken, or actions avoided.
Suggestions, discussion contributions, and other perspectives:
I thank the folks that have participated in the public LinkedIn discussion threads, or granted me permission to share these private exchanges, of their thoughts on the definition of Technical Debt:
- [a suggested addition, with respect to governance] "...a lack of understanding or practice of risk management- acceptance, avoidance, transference, etc. Unless a proper risk assessment is done, it is difficult to make financial decisions."
- Jeff Zygmunt
- 2024-05-30, private LinkedIn message exchange (shared with his permission)
- "Current technology or lack of technology that, due to age, negligence, or changes in standards represents the risk of a monetary or opportunity cost."
- Chris Henry, CISSP, CCSP, C-CISO
- 2024-05-30, private LinkedIn message exchange (shared with his permission)
Suggested Background Reading:
Standards:
- ISO/IEC 25002:2024 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality model overview and usage
Articles by others:
(articles in order of expected reading value)
- https://en.wikipedia.org/wiki/Technical_debt
- https://www.sonarsource.com/learn/technical-debt/
- Holt Hackney:
- 2024-06-13: New Research Suggests Architectural Technical Debt Is Most Damaging to Applications Amid $1.52 Trillion Technical Debt Crisis (Architecture & Governance Magazine)
- Rafalin: "Today’s technical debt reduction measures like code quality and performance observability tools and code vulnerability scans don’t focus on architectural technical debt."
- "The research study surveyed more than 1,000 U.S.-based architecture, development and engineering leaders, and practitioners at large enterprises as well as smaller digital-first companies."
- https://vfunction.com/resources/report-microservices-monoliths-technical-debt/
- McKinsey Digital:
- 2020-10-06: Tech debt: Reclaiming tech equity
- By Vishal Dalal, Krish Krishnakanthan, Björn Münstermann, and Rob Patenge
- Ward Cunningham's c2 wiki
- Martin Fowler:
- Posts tagged: "Technical Debt"
- 2009-10-14: Technical Debt Quadrant
- 2019-05-21: Technical Debt
- Henrik Kniberg: [LinkedIn]
- 2013-10-11: Good and Bad Technical Debt (and how TDD helps)
- Gerben Wierda: [LinkedIn]
- 2018-09-08: Agile, Dirt, and Technical Debt
- neopragma:
- appenwarr.com
- 2023-06-05: Tech debt metaphor maximalism
- Adam Tornhill: [LinkedIn]
- YouTube, GOTO 2019: Prioritizing Technical Debt as if Time and Money Matters
- Expected watching value: low-medium
- Primarly focuses on just the software aspects of Technical Debt
- Georgiana Gligor: [LinkedIn]
- Today Software Magazine (Issue #47): Paying Technical Debt: a Top-Down Approach
- Steve McConnell: [LinkedIn]
- Aaron Erickson:
- 2009:10-10: Don't "Enron" Your Software Project
- Gene Hughson:
Books on Amazon.com (in descending order of publication year)
- Unveiling Tech Debt: A Business Leaders Guide to Measuring and Managing Enterprise Tech Debt Leverage (2024)
- Estimated reading value: Very Low?
- Of possible note, see Chapter-6 Measuring and Managing Tech Debt, starting on page-70: Quantify Your Tech Debt.
- Pages: 88
- Technical Debt Management in software projects using Scrum: An Action Research (2023)
- Estimated reading value: Low-Medium
- This book's value may primarily be as a bibliography to other works - as it has a copious amount of citations.
- Pages: 84
- Additional links:
- https://www.linkedin.com/in/frederico-zenoglio-de-oliveira/
DOI:10.1109/Agile.2015.7 - https://www.semanticscholar.org/paper/Managing-Technical-Debt-in-Software-Projects-Using-Oliveira-Goldman/10e8eaf24a5247526a35211e9c0149370bf2f5e6
- https://speakerdeck.com/fredericooliveira/managing-technical-debt-in-software-projects-using-scrum-an-action-research
- See last slide, where he offers to send the full paper.
- https://ieeexplore.ieee.org/document/7284597
- https://www.researchgate.net/publication/305865096_Managing_Technical_Debt_in_Software_Projects_Using_Scrum_An_Action_Research
- https://www.agilealliance.org/resources/research-papers/managing-technical-debt-in-software-projects-using-scrum/
- "Because of project time constraints and ease of use, we reduced the use of the proposed metrics to two:"
- "Principal"
- "Current Amount of Interest"
- Technical Debt in Practice: How to Find It and Fix It (2021)
- Estimated reading value: Medium
- Covers variations of Technical Debt outside of just the software/source code
- Pages: 288
- Understanding Technical Debt: Your Guide to Navigating in the Age of Digital Disruption (2021)
- Estimated reading value: Medium
- In particular, see Part-3, for the section on "How to measure it?"
- Pages: 168
- Sustainable Software Architecture: Analyze and Reduce Technical Debt (2019)
- No Preview or Table of Contents available
- Primarly focuses on just the software aspects of Technical Debt
- Pages: 307
- Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering) (2019)
- Estimated reading value: High
- In particular, see Chapter-8: Costing Technical Debt
- Pages: 272
- Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, 1st Edition (2018)
- Estimated reading value: medium
- Primarly focuses on just the software aspects of Technical Debt
- Pages: 276
- The Mikado Method, First Edition (2014)
- In particular, see the discussion in Appendix A: Technical debt
- Pages: 240
- Refactoring for Software Design Smells: Managing Technical Debt 1st Edition (2014)
- Estimated reading value: Low-Medium
- Primarly focuses on just the software aspects of Technical Debt
- Pages: 258
Research Papers:
- Towards the Definition of Enterprise Architecture Debts (2019)
- "In the software development industry, technical debt is regarded as a critical issue in term of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. However, despite the vast research contributions in technical debt management for software engineering, the idea of technical debt fails to provide a holistic consideration to include both IT and business aspects. Further, implementing an enterprise architecture (EA) project might not always be a success due to uncertainty and unavailability of resources. Therefore, we relate the consequences of EA implementation failure with a new metaphor --Enterprise Architecture Debt (EA Debt). We anticipate that the accumulation of EA Debt will negatively influence EA quality, also expose the business into risk."
- arXiv:1907.00677
- https://doi.org/10.1109/EDOCW.2019.00016
- Technical Debt Management in Agile Context: A new framework and case study in a large financial institution
- SAC '24: Proceedings of the 39th ACM/SIGAPP Symposium on Applied ComputingApril 2024, Pages 826–833
- https://doi.org/10.1145/3605098.3635946
- Hidden Technical Debt in Machine Learning Systems
- Advances in Neural Information Processing Systems 28 (NIPS 2015)
- https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
A few possibly useful tools/techiniques (as 2nd/3rd order proxies) for approximating some aspects of potential Technical Debt magnitude:
Frequency/Cluster Analysis of bugs/defects, per source code file, or per line of code:
- (tools to be listed...)
Line Counting tools:
2024-07-13 Sat
- cloc
- line counting utility
- codescene
- ohcount
- line counting utility
- sonarqube
- tokei
- line counting utility
Cyclomatic Complexity Static Code Analysis, Software Measurement tools:
- (tools to be listed...)
Dependency Analysis tools:
- (tools to be listed...)
Lifecye Analysis: End-of-Life (EOL), End-of-Support (EOS)
- Flexera Technopedia
- See the Veterans Administration's Technical Reference Model (TRM) - for an excellent example.
- Note, in the Decision tab of their UI (see example: JDK Oracle Java Standard Kit Edition) - the Lifecycle information, provided by version - within a timeline context.
Addendums:
2024-07-13 Sat
- A very thoughtful LinkedIn post by Michele Sollecito (Director of Software Engineering, Element Materials Technology), enumerating 14 points about Technical Debt.
2024-09-26 Thu
- CDW HealthTech Magazine: What Is Technical Debt, and How Is Healthcare Managing It?
2024-10-12 Sat
- David Bassett (LinkedIn Post): Enterprise Debt vs. Technical Debt: Key Differences
2024-10-29 Tue
- Michelle Currie MS, RN, CPHQ, CPHIMS (LinkedIn Article): The Rime of the Ancient Mariner
- Scrum Alliance, article: Avoiding Technical Debt with These "Core Four" Practices
