I have been working on it since January 2024. It is based on some posts in my blog, but expands on my ideas quite a bit.
In September 2024, excerpts appeared in Gergely Orosz’s Pragmatic Engineer newsletter, which helped me get a lot of feedback that expanded the book from my initial idea. This half is about what I expected to do before that —- the rest of the book goes into team and CTO practices.
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.
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.
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.
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.
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 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.