On Technical Debt in the City
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.
“Most systems simply don’t get designed as a whole... Complex projects are more often “grown” than designed.”
“...it is often very difficult to go back and fully understand old code...even if you wrote it yourself! There are just so many moving parts that it can take hours or days just to build up a mental model of how some code operates.”
“Usually customers complain so much about the bad state of things that you’re forced to ‘default’ on your debt and start from scratch. This is a really expensive and time-consuming thing to do, so it takes a lot to make it happen.”
“In my house, I come across something weird or nonsensical in its function ever few days. I usually ask myself “why the heck would the previous owner have done it this way?” But there’s usually not a good answer because the context has been completely lost over the decades.”
“Nobody who takes pride in their work wants to design a bad system. They are usually forced to by someone or something outside of their control.”
“Doing giant projects in one massive effort will almost always result in deadlines being missed and shortcuts taken. When you bite off smaller chunks, it might end up taking longer to finish the project, but you’ll find mistakes and issues earlier. It’s much easier to fix them then.”
