Three Kinds of Good Tech Debt

> Researchers talks and paper published by 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.

For [3], it seemed pretty clear in the post that the limit was 'arbitrary' in that there was business reason to impose some limit, but no specific limit was motivated by any reasonable "intentional" or "clear" thinking, and that, moreover, trying to discover some kind of reason was unnecessary and thus wasteful to even try. The author clearly points out that, apart from the limit, there is no need for "transactional correctness', i.e. no other part of the system required that the limit be strictly enforced.

And if that was some day no longer true – if they realized later that they really did need "transactional correctness", then it still seems like they may have made the correct decision in incurring technical debt, especially given that the author mentioned that the limit was never exceeded in production.

If that system did in fact require a hard limit then they probably would have focused on implementing "transactional correctness" as that would have then been a core feature of the system.

I can certainly sympathize with your comments in this thread. But all of your examples rather seem to confirm the utility of the analogy/metaphor as it's certainly, clearly, true that some people incur too much technical debt and are never able to 'pay it off' later when it comes due. That's not a knock against the analogy but instead a mark in its favor – debt should be taken on mindfully and carefully.

Contrary to what seems to have been your experience, I've seen technical debt incurred to great benefit.

Totally agree. How many times have I seen Tech Debt as a task to be completed in some future sprint (ya right), or seen it as the title of a category in a dev schedule containing missing product features.

Tech debt is such a general term it does more harm than good, and is often abused by people that have no clue what their actual tech debt may be..

It also implies that someone knew what the price tag was in the first place to accrue the debt, which they most likely didn't. No one knows what needs to be built or how to build it beforehand, except maybe NASA, this evolves along the way.

What you're saying is no one has perfect forsight.

That's a given.

You don't need the notion of "Tech Debt" to deal with that.

It is a complete given at any given time, during any given sprint, that all the features in the queue are ASSUMPTIONS.

That's just a tautology.

"Does my system need to handle 1M concurrent users?"

Maybe you answer Yes or maybe you answer No, but you have to answer something to make decisions about the work ahead of you.

The worst possible place is to be in the fuzzy middle saying fuzzy things like Tech Debt and rolling along fuzzily.

Many teams -- especially teams that love this term "Tech Debt" -- do exactly this.

But they are willfully navigating in the dark and "Tech Debt" is just a term that makes one feel psychologically okay with their ignorance.

But it's euphemism, that's all it is. It does not aid in rational navigation.