Comment by aeorgnoieang | Hacker News Reader

Comment by aeorgnoieang | Hacker News Reader

Parent Full thread

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.

You're letting him off the hook for [3]. Unless the PM's are saying "Generally try to limit the number of items to 10 but it's okay if there's 11, 12, or so. And if there's some case where there's a 100 that's okay..."

Sure, fine, the PM can give this as the requirement and all can go ahead. But you're gonna have a crap time trying to analyze and test in staging, making sense of load testing scenarios, validating this feature in anyway, etc.

And I think you know this, or you intuit that this is not very good but you're not quite sure why so you say hmm let's slap a label on this that effectively covers my spidey sense that it is crap even though I can't quite articulate why. What should we call that... hmm... oh, let's call it:

"Tech Debt."

This is precisely how "Tech Debt" is wielded. It's a fuzzy term to apply to a fuzzy understanding of our design choices.

And there you might say, Great, that's it, that's what Tech Debt is. But I can guarantee you -- from long experience -- that not understanding the consequences of your design choices means that you have NO IDEA the cost of that misunderstanding. It could be 10 units, it could be 1000 units, it could be 10000.

"Tech Debt" is akin to saying "I don't know." This is a big reason why the concept is useless. It's fuzzy, it's akin to saying "I don't know" and therefore there is no way to quantify the impact.

And not being able to quantify the impact means that the analogy to other forms fo debt (eg, financial) is completely disjoint and unhelpful.

Bad design choices cost you over and over again. Universally when someone has called Tech Debt on something, it almost inevitably reflects their suspicion that something is not quite right about the design but their inability to say what and quantify the cost. Otherwise, you simply would not need such a fuzzy term; you'd have a much clearer analysis and articulation of your situation.

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

Write a paper then and show me the money, so to speak. Quantify this. Because the only "great benefit" I've seen of the term "Tech Debt" is to the ego of the individual or team that invokes the fuzzy term.

I can only understand [3] based on what the author wrote. But it certainly seemed like it really was the case that generally limiting the number of items to 10 was fine. And, based on their subsequent observations, there was no practically realizable situation that would result in more than 10 items, let alone 100.

Lots of terms – really, every term – is fuzzy at some resolution and thus all understanding is inevitably fuzzy too.

Empirically, you seem to be almost entirely wrong about people not understanding the consequences of their choices. It's absolutely true that sometimes people are wrong about the consequences, but that's true even with financial debt – maybe the interest payments on some debt that should have reasonable end up being the straw that broke the financial back of the organization.

> Bad design choices cost you over and over again.

In the sense in which you seem to mean this, this is a ridiculous statement because every design that's not perfect, and none is, must then be a "bad design choice". That's just not true in any reasonable interpretation.

It's also unclear why invoking 'tech debt' precludes a clear analysis or articulation of the relevant situation. And regardless of whether anything is quantified, it's also inevitably 'fuzzy' too. Why would quantification itself be good?

Take the first example from the article – implementing a 'bad' version of the component to actually send emails. They did this, consciously, because they wanted to test the editor component first, before implementing the more robust email-sender version. And they did supposedly quantify a lot of that 'technical debt' – they estimated how much time they'd need to implement the initial throwaway code and how much time doing that would save in terms of them being able to more quickly test the editor. And they seemed to have a very clear idea about what exactly was wrong with the initial version and thus an approximate idea of the costs of not eventually replacing it with a better one later.

> Write a paper then and show me the money, so to speak. Quantify this. Because the only "great benefit" I've seen of the term "Tech Debt" is to the ego of the individual or team that invokes the fuzzy term.

The blog post for this very thread is a good example of the great benefits of thinking in terms of technical debt! You should write a version of the same blog post, using all of the same examples, and clearly indicate why using 'technical debt' is pernicious and furthermore how exactly you'd have dealt with all of the same issues and considerations mentioned.

>> Bad design choices cost you over and over again.

>In the sense in which you seem to mean this, this is a ridiculous statement

The point is to acknowledge the Cost. There is tremendous cost in design choices. No design choice will be perfect. Nobody is perfect.

The whole point is to optimize. To minimize bad design, to minimize Cost. That's the game.

And my whole point is that by using a fuzzy term like Tech Debt you are completely side-stepping the game. You are completely avoiding a best-effort at solving the optimization problem, so to speak, by waving your hand and saying Tech Debt something.

We already have clear terms for dealing with problems, solutions, axioms, risks, etc. There is already a clear vocabulary for problem-sovling that includes all the pragmatic real-world admission of imperfection.

But by avoiding these clear terms in favor of an umbrella kitchen sink, we are most definitely opting out of optimizing and into ouiji board mode. Which is fine for many people and the euphemism "Tech Debt" makes them feel good about this. But that's all it's doing; anyone leaning on "Tech Debt" as a concept is operating at sub-sub-optimal productivity.

> You should write a version of the same blog post...

In my original commment I broke it down point by point. 1) and 2) do not need a new term. There are already clear terms for these strategies, Prototyping and Scoping -- and these have much much clearer meanings than an umbrella term like Tech Debt.

So then we're left with 3). And I try to demonstrate the flawed reasoning behind this choice, as the author explains himself.

I'll take another stab using your statement:

> And, based on their subsequent observations, there was no practically realizable situation that would result in more than 10 items, let alone 100.

This is the famous last words that I've seen over and over again.

The simple fact of the matter is you will see 100 in some environment. Perhaps six months from now when you decide to load test your system in staging. Etc. And you are in no position to say how much that will cost you at that point.

But what I can tell you is that if you have a professional on your team, you can solve this OP's problem in very little time right out of the gate. You won't even need to have to try to do this impossible calculus.

Reply on news.ycombinator.com