Hacker News Reader

Comment by loumf | Hacker News Reader

The analogy I am going for is the water resistance. The debt payment is the burst of momentum you get from pushing off the wall.

I think of tech debt as something you are dealing with all of the time and something inevitable.

I don't like the financial analogy because it implies that you "took out a loan" by taking a short-cut, and that you are obligated to pay it. There is definitely some of that, but mostly, I see it as good decisions that didn't age well. And also, that you may be ok with living with it.

View on HN

The fungible nature of money helps explain why that is the case. One dollar bill is as good as another, something people know from handling cash. Paying down a debt is one kind of investment. Maybe it costs you $100/day to service that debt. If someone offers you a chance to invest that same money that you could have used to pay off the first debt and by investing earn divdends of $200/day, then the fact that one dollar is as good as another is what means that you should do it.

But even then you're also not (yet) getting to the heart of it: what is the value of tech debt? You still make it sounds like a damp rag dragging on you rather than an integral part of an energetic strategy. Money also gives people a clear analogy for why sometimes you want debt -- why and how it can be used as a tool.

In the swimming analogy I would say incurring a debt is like creating a wall that you can burst off of, at the cost of increasing the resistance of the water. Yeah it's a weird analogy. To be more literal, debt buys you the time you need to figure out the optimal direction and especially the critical priorities that will reward work -- will reward investment. It buys time to learn the requirements from experience, and for people to come to some community consensus as to which needs are most imminent. But only if the person managing the debt thinks of it as a tool to be used in this manner.

You go right back to the monetary analogy when you need to explain that focusing on debt created value.

The thing that I think the swimming analogy doesn't capture well is that the resistance of water is fixed. The walls of the pool will be there to push off of no matter what you do. These are the intuitions you're asking people to draw on and they don't map.

I struggled with this. I didn't have the guts to not use "tech debt" in the title and throughout the book. I wanted to coin a new term, but didn't find anything that worked.

There are parts of the debt analogy that (I think) really hurt getting it dealt with. I think that explaining it like that to non-engineering decision makers will make them think they understand it and then quash projects based on some kind of ROI analysis of debt payments. They'll be happy to have the debt.

Debt is the right metaphor. Some amount of tech debt is virtually unavoidable; just like w/ $, a low-interest student loan or mortgage might be a great investment, while using a high-interest-rate credit card, or usurious payday loans, represent catastrophe. Cutting a few corners for the sake of GTM is often the former. Forgoing proper tests, or letting PoCs shape architecture, is more like the latter.

I don't see "swimming" replacing it anytime soon -- and the energy you'd expend trying to shift the metaphor might be better spent elsewhere.

That said, "swimming in debt" still works, as a fairly common and intuitive metaphor. Break-even is treading water, profitability is flying above the waves, and accruing debt can put you in Davy Jones' locker.

Isn't that same resistance the thing that enables you to float in the first place though? I don't really swim so don't understand the analogy I'm afraid.

The debt analogy works because you're taking a shortcut that allows you to eg get to market sooner (Vs perhaps not at all).

For some debt, yes, it starts with a shortcut. I want to talk about other kinds of debt-like problems that have nothing to do with that. Where you did everything right, but the world just changed.

I think most engineers know that doing everything right is reserved for toy problems. In engineering you're always making choices about what problems to deal with today and which to leave for tomorrow. Code is always some kind of simplification of reality: reality is just too damn complicated. The rules of the game of tech debt are the same as the rules of thermodynamics and the game of being alive: you can't win, you can't break even, and you can't even stop playing the game.

Reply on news.ycombinator.com