Debt Metaphor

Original sources by Ward Cunningham are not too hard to come by... > I became interested in the way metaphors influence how we think, after reading George Lakoff and Mark Johnson's Metaphors We Live By. An important idea is that we reason by analogy with the metaphors that have entered our language. > I coined the debt metaphor to explain the refactoring that we were doing on the WyCash product. This was an early product done in DigiTalk Smalltalk, and it was important to me that we accumulate the learnings we did about the application over time by modifying the program to to look as if we had known what we're doing all along, and to look as if it had been easy to do in Smalltalk. > The explanation I gave to my boss, and this was financial software, was a financial analogy I called the debt metaphor. And that said that, if we fail to make our program align with what we then understood to be the proper way to think, uh, about our financial objects—then we were going to continually stumble over that disagreement: and that would slow us down, which is like paying interest on a loan! With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money, you'll be paying interest. > I, uh, I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea. But that of course you would eventually go back, and as you learn things about that software, you would repay that l

in “How to approach and prioritize technical debt” · View on HN

'Technical Debt' in contemporary terms has certainly become a container holding far more than originally intended by Cunningham. The fundamental debt metaphor was about the need for ongoing re-factoring of past code and systems to match today's understanding , and the accumulating cost of failing to have the discipline and taking the time to do so. Cunningham's specific quotes from the video [0] linked in the article: "...accumulate the learnings we did about the application over time by modifying the program to look as though we knew what we were doing all along, and to look as if it had been easy to do" , and "If we fail to make our program align with what we then understood to be the proper way to think about our financial objects then we were going to continually stumble over that disagreement, and that would slow us down" . This problem is fundamental to software systems and how they change over time, and is not about making poor choices, tradeoffs, or generally poor engineering to ship code faster. A system or feature is initially built based on the requirements that were known at that point in time . Requirements are frequently not static though: that original set of requirements may continue to evolve over time, either as we better understand them after implementation, or when requirements are added, refined, or removed by the stakeholders or organization. Additionally, we can't view each feature or requirement in isolation over time: only when we see the overall set

in “Technical debt is not debt; it’s not even technical” · View on HN

Except that technical debt is not about writing bad code, and the author of this article gets it completely wrong. "The metaphor of debt is sometimes used to justify neglecting internal quality... Teams who do this end up maxing out all their credit cards, but still delivering later than they would have done had they put the effort into higher internal quality."[1] "the whole debt metaphor, let's say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem"[2] "write the best code possible given a partial understanding of the problem so later when you do understand it better you improve the solution"[3] 1. [link] 2. [link] 3. ▶ this video

in “Nobody cares about your clean code” · View on HN

I enjoyed the article, although I disagreed on some minor points, some of the broad strokes seem solid to me. Very thought provoking. I think it's interesting to contrast the thrust of the article with Ward Cunningham's original definition of technical debt: ▶ this video Wards definition is much more about the differences between the current implementation of the software and your understanding of the problem, particularly as your understanding changes over time. He explicitly says that "tehcnical debt" is NOT an excuse to write known-to-be-poor code, which is why I disagree with the //TOBECLEANED approach. This change in perspective shifts the point of view quite a bit. In some ways this problem defines a startup, your biggest problem is that you don't understand your problem. It's somewhat likely that you won't even have the same problem you'll successfully solve later. The first points are salient here, focus your engineering efforts on the things you don't understand yet, and the minimum support it needs to be viable. Shorten your feedback loop as you navigate the things you do not yet understand. In this light, a startup is actively SEEKING technical debt, because it represents gaining understanding about a problem, and exploring that space quickly. This doesn't mean you have to "cut corners" and do things you know to be flawed, but it suggests focusing on small 'forays' into the unknown, gaining understanding quickly, and being willing to throw away your exploration for a ne

in “How to Leverage Technical Debt” · View on HN

>Knowing when to release a feature and go into technical debt is one part art and one part science. let Ward Cunningham itself explain what he thinks about taking shortucts and calling it technical debt ▶ this video

in “Technical Debt Is a Good Thing” · View on HN

It's a metaphor: ▶ this video Essentially how well you can write a program to reflect your understanding of a problem. Though it has come to more generally mean writing crap in a lot of cases.

in “Ask HN: How often does technical debt lead to the failure of a startup?” · View on HN

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] ▶ this video

in “It's called “Ship” not “Shit”” · View on HN

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) ▶ this 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

in “Everything Gets Painful & Slow as You Scale” · View on HN

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.

in “A Mess is not a Technical Debt” · View on HN

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 Cunningham on technical debt)

in “Embrace technical debt” · View on HN