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.

▲

loumf 6 days ago | parent [-]

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.

	▲	chrisweekly 6 days ago \| parent [-]
		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.