In Real-World Development we have many moving pieces , for so long we have been hearing about "Technical Dept " when we
take talk about software development especially here, this begs a question, in my opinion "Technical Dept " is a very vague term
which leads into multiple interpretations What in opinion are the the ""Technical Dept " and are these being discussed in your book?
I didn't find any reference to technical debt in the book.
Technical Debt as explained by Ward Cunningham was supposed to be a good thing (see the 5-minute video he made). This kind of debt is what some people call "managed" or "intentional" debt. You take shortcuts so you can get some experience with the running software and learn more about it. Then you take what you've learned and "pay it back" into the software so it reflects your new understanding of what you should have done in the first place.
Unfortunately, the term is more often used these days to refer to messy code and designs. This kind of "debt" is sometimes referred to as unmanaged or accidental debt which is caused by poor engineering practice or other factors that increasingly make the code more difficult to work with as time goes by. This is not a very useful way to look at debt, in my opinion. Bob Martin even goes as far as saying that A Mess is not a Technical Debt.
If you keep adding features to software even though you don't fully understand the code, it gets more complex and more difficult to work with. This is like taking out more and more money on a loan without any intent or effort of paying the debt down.
Many people think that the currency of technical debt is quality, that having technical debt means the software lacks quality. In fact, the currency of technical debt is time. The interest you pay is the time and effort it takes to work with the code. With managed debt, you gain the ability to experience and learn from running software earlier rather than later. This is "borrowed" time because you still have to pay it back by refactoring and making the code reflect whatever you learned from the running software. Cunningham explains that it's wise to go into debt this way but it's essential that you keep the code as clean as possible to reflect your current understanding so that it's easy to change the code to reflect your new understanding after you've had some experience with it.
Therefore, code that has technical debt really has a lack of understanding. If you don't manage that lack of understanding, then your debt becomes total and your progress goes to zero (essentially, you go bankrupt).
The best ideas are the crazy ones. If you have a crazy idea and it works, it's really valuable.—Kent Beck