Debt Metaphor

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: [VIDEO]

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": [VIDEO] 2) comic strip - "How Projects Really Work": [LINK]

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: [VIDEO]

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 [VIDEO] transcript at [LINK]

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] [VIDEO] (Video: Ward Cunningham on technical debt)

Ward Cunningham disagrees with your interpretation of his metaphor. [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.

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, which is similar to a financial debt. " Here the decision to take on technical debt is a deliberate one. You knowingly taking the quick-n-dirty route because of time constraints, not because you don't understand the "good" design. Here's a video of Ward talking about technical debt (referenced in Fowler's definition) [VIDEO] Here he talks about debt being something that you notice later. You learn more about what the solution should be, and need to go back and refactor your code so it reflects your new best understanding of the code. Debt is something that builds up over time, and you need to pay it off regularly so that the debt doesn't become disabling. At about 3:20 he talks explicitly about the idea of knowingly writing poor code: "A lot of bloggers at least have explained the debt metap

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] [VIDEO]