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: ▶ 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

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

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

No sorry that is just bad encapsulation and goes under poor programming.Technical debt occurs when you write a good program to your current understanding of the solution knowing that the full understanding of the solution will come later, and that you need to do something now to get to that learning point later, and so you have to repay your partial understanding at the beginning with refactoring later. Here, heed Ward words directly, poor programming is not debt, and debt doesn't cover "whatever reason programmer may have" but has a specific well defined scope: ▶ this video

The paper uses the term "technical debt" without defining it. From the context the term is used in its popular sense in which the primary source of debt is writing code poorly. Ward Cunningham, who coined the term, did not mean it in this way [1]. Wikipedia defines it as "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer" [2] which is more aligned with Ward's intention. The problem with the current understanding of the technical debt metaphor is that it justifies poor code quality. Apparently it's like taking out a loan to make a sound investment. 1. ▶ this video 2. 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

'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

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

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

>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

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.