Ward Cunningham
3 HN recommenders · recommended in 15 months, 2009–2023
4:44 · 95K views · Feb 15, 2009
Ward Cunningham explains the history and intent of the debt metaphor, which he coined while refactoring the WyCash product. He says debt means code reflecting an incomplete understanding of the problem, not sloppy programming.
HN links it as the authoritative correction to common misuse of the term technical debt, straight from its originator.
16 comments from Hacker News
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
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]
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
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]
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