3 ms·

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

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.

wellpast 7y ago
>> 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.

wellpast 7y ago

>> 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.