Show HN: Swimming in Tech Debt

The swimming analogy is not a strong start. You disavow an obvious and strong analogy to monetary debt right away while dumping us into this strange metaphor that depends on us having an intuition for how you think and feel about swimming, and specifically swimming laps? Instead of setting the stakes high right off the bat you've lowered them and lost my attention with this wandering train of thought that has no clear relationship to the topic you wish to discuss...

Thanks for the feedback. The reason that I put up half the book and offered it for $1 to start was to make sure that people that didn't like it wouldn't buy it.

I struggled with this opening and it definitely could have been better.

I'm reading a bit more now and you're realizing that your debts are real and cost something all the time so that you will have to pay them. Nothing about swimming explains why this might be, though monetary debt sure does.

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.

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.

Sorry, I'm a notoriously harsh critic. That probably comes from being homeschooled by two English major parents (a poet-professor and a journalist).

No worries at all. I really do appreciate constructive feedback. I put every draft of the book out there that I could, and this is my best version of making the book I wanted to make that resonated with at least some people.

I totally get that it's not for everyone.

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.

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.

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

I think people are being extreme pedants at best, disingenuous at worst. I think your analogy is clear, and the people that can't connect because they don't understand swimming is in the minority.

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.

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.

Monetary debt is often a useful tool. Technical debt in many cases is just shortsightedness in throwing delayed time bombs around. It is built on the hope that you won't need to return on this minefield again (the product dies sooner).

This is a good insight. The real gambles behind tech debt are not taken on the same way a company would take on real debt. If there is analysis of it, and it's not just a sneaky shortcut by a dev (either being lazy or working to a deadline), then it's not considered in terms of future cash flow or any other kind of meaningful metrics that matter over time. It only comes due if you want it to; you only pay interest on it when you interact with it. Sometimes it really is Good Enough for the slapdash thing you're working on. Sometimes more crap on top of more crap is just how the thing you're working on goes, and trying to fix it is tilting at windmills... especially if it's just to make your employer rich by mildly improving efficiency on their ad delivery platform.