Happy Friday!

I was thinking the other day about some conversations I've had with former clients and at various jobs, and in my mind, they kept coming back to a single point. There was one behavior that was natural to me that I was encouraging them to adopt.

Strangely, this behavior is a pretty tough one for folks to take on. I consider that point pretty interesting on its own. In the end, I expect you'll wonder what's so hard about that, too!

Now, I'm about to explain the "Clean House" fallacy. I made this up, so it's a little weird.

When we had our first kid, like many parents, everything in our lives got put aside if it didn't directly help our new baby. Our sleep was ruined, laundry was overwhelmed with baby clothes, we would eat on the run, etc. After a little while, our home was just in shambles, and with no energy the idea of cleaning up was daunting.

My wife would be paralyzed by how messy the whole house was, and she would accomplish very little. I, on the other hand, would pick up one room. Just one foot away from the room I cleaned, it would be a disaster, and in a few days, the room I cleaned would be a disaster again, too.

This is the origin of the fallacy of the clean house. The idea is that unless you can clean the whole house, cleaning one room won't help.

It turns out engineering teams suffer this all the time. They see problems in their code an infrastructure, and at some point it feels like unless they can re-do some huge portion of it, nothing small could help.

This leads to the code getting buggier and messier. Infrastructure is becoming less instrumented, non-performant, and plagued with outages. It leads to spending more and more time trying to keep things operational instead of moving ahead.

The folks suffering from the fallacy believe nothing short of a huge project will save them. Folks like me just make small improvements every time we work nearby. Let the small, good things accumulate.

Seems obvious, right? Some folks call this behavior "Boyscouting" which is shorthand for "Leave things better than you found it." I think this is the actual behavior that is required to keep technology well maintained.

So what specific behaviors do I recommend? I tell folks to add one more test. I tell them to do a small refactor in code that is messy. I ask them to rename a variable that is otherwise not descriptive.

There you have it. The clean house fallacy and how I try to help combat it. Though remember, this is one of those behaviors that is p pretty hard to get moving in folks, but well worth it.

Sincerely,

Ryan