When I first heard the phrase “Technical Debt”, I nearly fell of my chair, but recently, a couple of articles have passed me by and I thought I’d have look and think about if it helps address the intractable problem of maintaining legacy technology, but particularly applications code. The problem is that to make changes, one often has to amend code that’s already in use. This increases the cost of the project. The increase in cost to new projects is part of the “Technical Debt”, however, it’s basically a metaphor. Is the problem one that financial management tools, can be used to improve the understanding of? Does this apply better to code that one has development rights to, rather than packages or infrastructure? Here as every are my notes and links.
I have not read all these yet.
- Tech debt: Reclaiming tech equity at McKinsey, a stab at what it is and how to manage it; but I am still questioning if it’s any use as a concept.
- Wikipedia on Technical Debt & Software entropy, which is one of the causes of TechDebt.
- The Tech Devt quadrant, by Martin Fowler, with an insight into a 2×2 box on the cause of TechDebt, plotting Recjkess/Prudent vs Deliberate/inadvertent and here is his writing on Tech Debt itself; it is Fowler who points out to me that it is a metaphor.
- How to measure – and manage – technical debt, at the Enterprisers Project, written by the CEO and an analyst from Tabletop Technologies, who will sell you a value identifying tool, and not surprisingly their technique requires the understanding of how value accrues to the I.T. Assets. I must remember that cynicism is not always right and they do point to SonarQube and Coverity as tools that can help measure Technical Debt. [ It seems that Value Stream Management is a thing!] See also Wikipedia on value stream mapping.
- What technical debt is and how its measured, by Daniel Okwufulueze a medium article which I haven’t yet read.
- Magical thinking and maintenance , by Rachael Colidcott, on the social causes of Technical Debt, the other article that sent me down this rabbit hole.
- https://www.productplan.com/glossary/technical-debt/, not read this one either.
I say …
- Can Tech Debt be identified?
- Is depreciation a better metaphor?
- All software has bugs, even on day 1, how does this fit in?
- Surely we should be putting the cost of the debt on the original projects?
While reading up on this I came across these articles,
- A conversation with Jez Humble on Accelerate: the new book explaining the data and science behind DevOps – management culture is important, burnout should be avoided. This also quotes MacGregor’s Theory X/Theory Y and reminds us that managers get what they believe
- Lean software development , from Wikipedia – one of the conclusions or targets of lean SDLC is to eliminate waste.