Debt Metaphor

What Hacker News said

Strong rec philbo · 2016-01 · on “Towards an understanding of technical debt”

For the best description of technical debt, you can't do better than listen to the man who first coined the term. Ward Cunningham explains: [this video]

Recommends datashovel · 2014-11 · on “Your developers aren’t slow”

Here are a few of the resources I have used in the past to help explain to non-technical folks some of what a developer needs to deal with when involved in a large project. 1) Ward Cunningham explains "technical debt": [this video] 2) comic strip - "How Projects Really Work": [LINK]

Recommends cratermoon · 2021-06 · on “Tech debt is not a burden, it's a strategic lever for success”

It's kind of a pet peeve of mine around technical debt. Some programmers and places I've worked get it wrong, so I refer people to Ward Cunningham's explanation: [this video]

Recommends cratermoon · 2023-02 · on “The age of cargo cult Agile must end”

While we're at it, let's talk about what Technical Debt really means. A mess is not technical debt. Ward Cunningham explains Debt Metaphor [this video] transcript at [LINK]

Cites sokoloff · 2009-07 · on “Embrace technical debt”

We (or at least I) also think of it as leverage. We also have a very strong 80/20 ethic, so we don't have particular qualms about using the leverage that this debt can provide. We don't do anything magical; there is no secret sauce, noe no spreadsheets with formulae or anything fancy; it's literally just a series of wiki articles and Jira tickets with issue type "Debt" so we can easily find the documented debt and make plans when/whether to retire it. So the concrete formal mechanism is "use your bug tracking system and flag them somehow so you can filter/search for them." I will add some additional links that our top-level debt page references as useful: [LINK] [LINK] [this video] (Video: Ward C

Cites zupatol · 2011-08 · on “A Mess is not a Technical Debt”

Ward Cunningham disagrees with your interpretation of his metaphor. [this video] He explains that technical debt is code written before you have a complete understanding of the problem to solve. You repay the debt by refactoring it when you have a better understanding. This only works if the code is clean enough to be refactored.

Cites adrianhoward · 2012-09 · on “Everything Gets Painful & Slow as You Scale”

Interesting that this repeats Martin Fowler's definition of technical debt ( [LINK] ). While Fowler references Ward Cunningham as the originator of the term I think he gives an interestingly different definition. Fowler says "You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy - you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, wh

Cites RKoutnik · 2014-09 · on “It's called “Ship” not “Shit””

This reminds me of the Humbug in The Phantom Tollbooth, who is described as "[someone] who always managed to be the first with the wrong answer" and later tries to argue that it was the question itself, not the answer, that was wrong. It's a shockingly good lesson that I seem to re-learn every six months or so. Being first is never a virtue in and of itself. MVPs that sacrifice quality for speed (instead of sacrificing scope) always end up as painstaking rewrites at best, and slow slogs to failure at worst. Something I think most miss is that taking on this technical debt is ok when you don't know which direction to go [0]. Get something to market to learn , not to be "first" or "right". [0]