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