Aaron Erickson  🥑

Do you know why Hoarders isn’t on the air anymore? It turns out that hauling everything away and cleaning up the house doesn’t fix people’s habits that led to the hoarding. Most of the show’s partipants, after the show was over, slowly went back to a hoarded house.

A much more successful treatment for hoarding is to work intensively one on one with folks, changing their habits slowly over time, & having THEM clean up the house - one little area at a time. Unfortunately for the creators of Hoarders, this makes very boring reality tv.

Our hoarded codebases work the same way. If you don’t change the habits and incentives that led you to that point, you’ll end up with a tangled mess of services mirroring your tangled mess of monolith code.

And at that point, all you’ve accomplished with the money & time they gave you for the rebuild is to shift your problems to the network layer, where they are way harder to see, analyze, test, and fix. That is not progress. IMO that’s engineer malpractice.

So...is it just impossible to improve your working conditions, when you’re working in a hoarded codebase? Are you just DOOMED to feel anxious every time you need to go near the precariously balanced User class until one day it just...falls over on you?

Ha ha! Of course not! This is where communication skills come into play. Because it is not at all trivial to even _understand_ the incentive structure that got you where you are, let alone to negotiate a new, healthier set of incentives.

The most common “presenting” pathology in the hoarded codebases I’ve seen - by far - is that developers don’t feel they have time and/or permission to refactor code.

Frequently occurring alongside that pathology is another - that developers see “refactoring” as a completely separate activity from building features or fixing bugs. A key indicator of this pathology is seeing stories in the backlog like “refactor user class.”