151–159 of 159 posts
Earlier quoted context omitted.
There is no difference. Regular debt is also discharged in bankruptcy.
But that affects your ability to borrow in future, whereas a canceled project doesn't affect your ability to write rushed code in future. Unless you get fired, I guess...
Earlier quoted context omitted.
One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it lon…
Isn't that more of a similarity than a difference? When financial debt gets overwhelming you can declare bankruptcy and abandon the project as well.
Earlier quoted context omitted.
But that affects your ability to borrow in future, whereas a canceled project doesn't affect your ability to write rushed code in future. Unless you get fired, I guess...
You’re nit-picking when I think the analogy is clear but it doesn’t effect your credit if the company you work for declares bankruptcy, so the comparison to the company’s tech debt seems to hold up even if you push it.
Earlier quoted context omitted.
One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it lon…
> One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. This happens with financial debt as well. It's the risk that drives interest rates. Financial debt is abandoned (or restructured) when people or companies file for bankrup…
Two points I really enjoyed: > Not Fixing All the Edge Cases We’ve all seen bugs that occur so rarely, and fixing requires destroying some part of the original design architecture. The ability to acknowledge these types of bugs as not worth fixing is liberating. > Err on the side of building too little because you can always build more later. Build things to be easy to throw away and replace; I find developers tend t…
I love throwing away code! We found a better way to do this - boom, you're gone! I do dislike coding solutions which I know to be temporary, sometimes it's necessary but it feels wrong if we already know something's not going to be adequate. That said it's also very bad to future proof (by which a lot of people mean abstract) the code to be able to do everything you can possibly think of that might be needed in futur…
Earlier quoted context omitted.
One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to. When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it lon…
I think what you're saying is the more common use of "tech debt", basically just using it as a synonym for "bad code". Don't worry about code quality, figure it out later. It ignores the stronger debt analogy -- sure, there is a high chance that the idea fails. But if it succeeds and, all else being equal, you have taken on a less tech debt to get there, you will be able to iterate on and grow it more efficiently. So…
I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt. One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves…
I don't like the metaphor. With financial debt, you get $X up front for $Y (where Y >= X) and pay $Y amount over N months. It's known up front what it's costing you (Y - X) over what time span (N). If the difference between Y-X is low, congrats! You got a great interest rate. If it's large, well, good luck! But in both those cases, the pain is known up front. The discussion here seems to be no one knows what X is, no…
Rather than trying to use the tech debt metaphor to actually calculate the interest rate, I think it's more useful at a higher level of abstraction.
When faced with the product decision to do more work now and build something better, or less work now and cut corners, what are the consequences of doing less? Without some way of conveying the long-term costs, your stakeholders will always push you to do the least work possible to tick the box.
The debt analogy is a universally-understood way of conveying the fact that if you cut corners, you'll likely pay interest later in the form of slower development speed. And if you take on too much debt, then all your spend will be going to paying off your interest, and your progress will stall. Non-technical people understand this analogy, and so it's a useful way of conveying the shape of the problem without having to start from first-principles.
Earlier quoted context omitted.
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 th…
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 inevitab…
>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.
Earlier quoted context omitted.
> 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 p…
>> 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. I would highly recommend this book: https://www.oreilly.com/library/view/managing-technical-debt... Also, read the papers presented at this conference series. https://2019.techdebtconf.org…
The book enumerates some examples of failed software projects and calls their failures "Tech Debt".
I have two issues with this.
The first is how fuzzy this still is. This term is thrown over all of these various kinds of failure. And the examples are also quite varied - most are phrased as mere symptoms of failure not root causes, which gives us little insight.
The bigger problem I have is that these examples are retrospective.
If Tech Debt is simply a term for "mistakes I have made", then by all means use it -- obviously in this form it has no strategic/constructive value.
But the way I've seen it typically used is for people to act as if it is akin to real debt, consciously acquired.
"Oh I didn't make this transactional because Tech Debt."
Etc.
And indeed if Tech Debt as a concept is to have any value it should be able to be used this way.
But my objection is that there is no way it can be used as such, because it is far too nebulous a concept to have any navigational benefit.
It gives no helpful path forward. It is purely a euphemism for mistakes. That's how I've seen it used universally, at least.