Last week, I received a blog comment that I'd like to dig into further. Here's the comment from Strong Towns reader, Derek Hofmann:
"Very rarely does a code prescribe what it wants to see in the city. Rather, it is a tome dedicated to preventing the worst thing from happening, inspired by bad experiences. When it fails to do that, it adds another arcane rule."
Software engineering has a metaphor called "technical debt." It's when someone takes a shortcut when writing software due to schedule pressure or whatever. It's called a "debt" because it costs something until it's fixed properly in the same way that a debt costs interest until it's paid off.
Arcane rules in the zoning code sound to me like technical debt, because every time somebody has to read such a rule, it costs them time. Even just scrolling past it costs time. It shows up in search results, which themselves take longer. If it's ever printed out, you have paper and toner costs. There are storage costs, network costs, and if anyone ever tries to figure out why it exists, you have communication and meeting costs. Then there are costs to train law/code enforcement and costs to actually enforce the law. And lost tax revenue from tourists who disagree with the law, from resources spent on conforming with the law (parking requirements are a big one), and so on.
But if you can "refactor" that rule, like replacing a "no gun chewing in public" law with a more general "no littering" law, then you've paid off that debt and no longer have to pay interest on it.
This struck a chord with me because I recall listening to a conversation about technical debt a few short weeks earlier and nodding my head at the metaphor. So I asked my partner Ryan, and our friend Brendan, both of whom work in software, to explain technical debt a little further. I've screen-capped our chat in the gallery below (took some liberties to reorder in a sensible way). I'll let you draw your own conclusions as to the similarities in city-building policy.
All photos by Gracen Johnson.