My theory of tech debt is that housework is the correct metaphor for the thing we call tech debt, but we can't use it because tech has been made up of people who don't do housework, or manage housework being done.

The point of debt is to package risk. The point of financialization is to package risk to make it more palatable to different markets, hence able to be bought/sold/traded.

Most tech debt projects/conversations/discussions are difficult because the debt metaphor hides that the risk is not even for different actors.

I think housework is a better metaphor because it allows you to ask questions like, "Is this 'not cleaning the bathroom' bad, or 'running out of toilet paper' bad?"

Or even "We don't have guests, and the guest room bathroom is mysteriously out of toilet paper. Can whoever is using that bathroom please make sure it's restocked?"

The thing with tech debt is that in order to have a useful discussion, you need to be able to talk about *who* is affected and how -- who is going to be woken up, be pulled off other work, be unable to perform some critical function, etc. You can't hide risk and have that talk.

Right now, one of the failure modes I see in tech debt discussions is that everything has to be framed in terms of effects on the business. That is important, but if we take How Complex Systems Fail seriously, we know "catastrophe requires multiple failures".

How Complex Systems Fail: https://how.complexsystems.fail/ 

I have seen people argue all sorts of things, up to and including syntax linting, is tech debt critical to business outcomes. This kind of rhetorical inflation is not helpful. You say "tech debt" and people zone out, because they assume it's some engineer going on about ...

... the evils of the ternary operator or whatever. And sadly, very often, it is.

As anyone who has ever argued about housework knows, housework arguments are disturbingly specific. It's always "Who minds the most?" and "I don't use that," and "Who's going to do the work?" and (rarely) "Who's going to manage getting this done?"

Bringing some of that uncomfortable specificity to discussions of tech debt could be really useful. We need to be able to talk about who minds and why and where the work should live.

We also need to talk about how what we do affects other teams/people. Team A can decide not to worry about concurrency right now, but they might be sticking Team B with that work down the road.

Right now, with the financialization metaphor, no one cares, because we know "down the road" might never happen. But: that means we don't think "Hm. We're not going to develop in-house expertise on concurrency in a hurry. Maybe we should hire/send people to training/support ...

... people who are interested in this kind of thing doing some study?" or any number of other things to spread the load when the time comes. We don't think about what work Team B might need to put down in order to pick up the problem that everyone knows has been brewing forever.

We don't think "Team A took on this debt because they didn't know how to do the right thing and they had to do something. Not their fault, but...that wasn't good."

Whereas if we thought of it as more like housework, we could think "ok, the kids made this mess, now someone has to clean it up, can we get some of the kids involved since they have context for what they did, and it'd help everyone to get context for what to do next time?"

The debt conversation assumes a kind of statelessness, because that is the magic of financialization and financial metaphors. Anyone who has ever dealt with tech debt in an org knows that it's not stateless.

Housework is stateful. You don't get a clean slate. You often end up moving stuff from Place A to Place B so that you can clean and tidy Place A properly. And people have state (feelings) about it. O boy do they have feelings about it.

We picked a metaphor for "tech work that is about cleaning up old stuff instead of making new stuff" that *sounds* like something that would make sense to The Business, but (a) it's not clear it does, and (b) it confuses *us*, thereby falsely constraining our options. /fin