6 ms·
Debts, Tech and Otherwise
- rkaregaran 2y agoreforge has a great post where they classify the various types of debt in digital product development: maintenance debt, developer efficiency debt, stability debt, security debt, technical product debt, decision debt. https://www.reforge.com/blog/managing-tech-debt https://www.reforge.com/blog/managing-tech-debt
- wrs 2y agoThe survivor bias section at the end is summed up by a favorite response to premature scaling work at a startup: “We would be very fortunate to have that problem.”
- hnthrow90348765 2y agoFeels like we're stretching the metaphor when we apply it to things that won't necessarily compound in complexity or time required to fix it. This is often the case with technical stuff because things can depend on one another, but if you drop a bad process step, the time saved is probably linear since rarely do other teams need to change their process because you changed yours. Debt is scary as a metaphor because the interest compounds and the bank can repo things, but if you just owe a guy $10, he's not gonna come after you years later with a $300,000 bill. Non-compounding bad decisions are "you owe a guy $X" while the compounding ones are "debt". Maybe we should use "fees" and "debts" to differentiate these.
- dijksterhuis 2y ago> Debt is an obligation that requires one party, the debtor, to pay money borrowed or otherwise withheld from another party, the creditor. > The term can also be used metaphorically to cover moral obligations and other interactions not based on a monetary value. For example, in Western cultures, a person who has been helped by a second person is sometimes said to owe a "debt of gratitude" to the second person. https://en.wikipedia.org/wiki/Debt https://en.wikipedia.org/wiki/Debt "debt" means owing something to someone. non-compounding debt is still debt. i don't pay back a "debt of gratitude" with compound interest. i also don't pay back friends I owe money to for a restaurant bill with compound interest, even though i was in debt with them when they covered my part of the bill. compounding/non-compounding is fine. don't over-complicate it.
- heavymetalpoizn 2y ago[dead]
- 0xbadcafebee 2y agoI can call an ink pen "a sword". I can even justify this by saying some nonsense like "pens are used to wage war". But if I rush headlong at a Samurai with nothing but a Bic Rollerball, I should not expect to come out of the encounter with all my limbs, much less the expectation of injuring the Samurai. Just calling it "a sword" doesn't mean it has anything to do with an actual sword. "Tech debt" isn't debt. It has nothing to do whatsoever with the concept of debt. What people mean when they say "Tech debt" is really "I'm putting off work I know I should be doing now, until later, and I'm doing something else instead that I know I'lll need to undo" That's not debt. That's procrastination. That's delaying the inevitable. It ain't debt. You don't pay off a car loan with procrastination. You don't decide to put off painting your house and then call that a loan. "Tech debt" has nothing to do with interest, with a lienholder, a creditor, a payment plan, etc. There is nobody to call in the loan. There is no incremental payment. There is no credit. There is nothing whatsoever to do with the entire concept of debt, much less any of the actual practical real-world implications, actions, or actors, behind debt. Please let's stop perpetuating this cargo cult myth. There is no such thing as "tech debt". There is only compromises and procrastination, and justifying regrettable decisions by pretending there's a good rationale for them. There isn't.
- fluoridation 2y agoAre you aware of this thing called a "metaphor"? Do you also find it aggravating when someone tells you about a program that is "running" because it's not using its legs to move along the ground? Or when someone says that they're going to "take a rain check" on an activity that doesn't have an entry fee? >You don't pay off a car loan with procrastination. Following the metaphor, the car loan itself would be the result of procrastination (i.e. you procrastinated when you decided to put off paying for the car by taking on debt). >You don't decide to put off painting your house and then call that a loan. I mean, I don't see what would prevent you from doing that, as long as everyone understands what you mean.
- normie3000 2y ago> Or when someone says that they're going to "take a rain check" on an activity that doesn't have an entry fee? Wait, what is a rain check?! Does it involve money?
- uuddlrlrbaba 2y agoTech debt is such a flawed concept. There is no world where requirements 10 years later are the same as the MVP, or even foreseeable. You can never pay it off. Software is always changing. Even if it were debt, debt is a tool to get you what you need today. And then you likely roll it into something down the line. Maybe you pay it off (and even then the asset still requires maintenance) Like a starter home, then upgrading to a larger home to start a family, etc, etc. Requirements and resources are in constant flux.
- andrekandre 2y agotech debt is rarely "payed off" all at once, its more like paying it off over time so your "monthly bill" (productivity loss/slowdown) doesn't bankrupt your project > Requirements and resources are in constant flux. this is precisely why over time you pay off that debt - that keeps your project rolling at a good pace - is the point
- 8note 2y agoi take out debt to build a thing that satifies today's requirements. its irrelevant whether the requirements change. the debt is still taken out in the code or whatever other solution debt for requirements that arent there anymore should be forgiven, and the system deleted. thats different than paying off the debt
- burakemir 2y agoIn an attempt to get a more general version of a debt metaphor, let's look at ingredients: - there is a time interval - we have a utility function, or at least desire one or want to pretend we have one - there is a decision - there is uncertainty From here there are many paths... "Deliberate vs inadvertent" describes whether we know about the effect the decision has on the utility function. "Reckless vs prudent" describes whether we are rational and realize that decisions have consequences. It is also possible that we don't actually have a utility function. Or different people involved in the decision have different utility functions or don't feel the same responsibility towards the outcome (not unheard of when it comes to maintenance/design/architecture vs feature). What makes the debt metaphor very attractive is that it evokes an image of being in control. We may not have spelled out the utility function but everyone agrees it is bad now so we can pretend it was a rational choice we had. The alternative that we did not take any decision when we could have or were too distracted to see the consequences is much harder to accept. So now that we have debt, let's talk about whether we choose to pay it back or now. Rather than working hard to create this faux image of control, I wonder how often teams may be better off having an honest discussion about what the utility function is or should be, which decisions will make the group move in the right direction and how the team can keep oneself accountable that the effects that one had in mind actually took place.
- potatohead00 2y agoI really liked Yvonne's reframing of tech debt as house work: https://mastodon.social/@yvonnezlam/112474946704366947 https://mastodon.social/@yvonnezlam/112474946704366947 no metaphor is perfect, but I think figuring out who is impacted and how by decisions to rush or skip things is important.
- strken 2y agoI really hate that framing. "Tech is made up of people who don't do housework" is an insulting and largely incorrect framing, and my vast experience of cleaning my shower has taught me that it's almost completely unlike tech debt. The cost of not doing it is...it looks bad and it's harder to clean next time. And maybe I need to get out the real bleach and the safety gear. This cost is not at all like tech debt, which has downsides that multiply together in unforseen ways and fuse together into critical outages. Deferred maintenance of other engineered systems is a better metaphor because it includes severe consequences. If you ignore problems in an aircraft, the aircraft doesn't just look slightly gross: it has to crash land in a river, severely injuring 8 people and killing 2. Similarly, the long-running transactions in that batch job you didn't fix + the fact you delete info from other systems within the batch job before the transaction commits + the job retries on an aggressive backoff + you only have a single database with a limited number of available ports, can all multiply together into a significant outage and data loss.