> Researchers talks and paper published by https://sei.cmu.edu https://sei.cmu.edu is a good starting point Please link to a real paper that explores Technical

> Researchers talks and paper published by https://sei.cmu.edu https://sei.cmu.edu is a good starting point Please link to a real paper that explores Technical Debt. This is just the link to SEI's home page. I'm looking for clarity, not hand waves. > A developer aiming for technical supremacy for its own sake isn't useful in a real-world business scenario. You're straw-manning. We're not looking for technical supremacy at all. (See my point #2 and my emphasis on brutal practicality.) We are looking for business optimization and all of the pragmatism that comes with that. My objection is to using a dodgeball term like "Tech Debt", which in no way helps to carve a pragmatic path forward. It is akin to hand-waving. If you move forward with any degree of efficiency, it will be in spite of your use of the fuzzy notion of "Tech Debt". You can do just as well without this (non-)concept. I would call this "My Thesis" but that acts as if the burden on me is to justify my objection. The burden is on whoever introduces this silly "Tech Debt" notion to 1) clarify what exactly it means and how to measure it; and 2) give a model in which the measurement can correlate with an improvement to the software process. Otherwise you're just talking Santa Claus. I have yet to see anything close to that kind of clarity when one discusses Tech Debt. There are a dime a dozen posts on "Tech Debt" and if you dig just a little you'll see that it is nearly always used to avoid clear analysis. To be fair, clear analysis is hard, so I can understand why people give up and take the easy path. But let's call the spade a spade. "Tech Debt" is a dodge. It's not a constructive tool. Your links are not helping your case either. Fowler's writing explicitly makes a distinction between quadrants of Tech Debt and the only one he calls "Prudent" is the panic "We must ship now scenario." If this is the only form of "good" Tech Debt, then my case rests completely. Because all that is being said then is that "I literally have no idea what situation my code assets are in but I have to ship now, so let's go with whatever's on disk!" Again, this is fair business. Anything is fair business. But this is certainly a position of ignorance and not a position of strategic choice. So if can admit that "Tech Debt" is simply "Ignorance", then we are all in agreement. Admitting ignorance, incidentally, is the only way an experienced practitioner can emerge and reduce the likelihood of being in such positions to begin with. Matters are even worse. Besides "Tech Debt" being a useless concept. For the individual it creates no clarity, no admission of deficiency, and no incentive or need for growth.