Broken windows

I'm still hogging the Pragmatic Programmer book my company bought for us to share 🐷 #SorryNotSorry.

Entropy

Entropy is the term used to describe how everything in the universe tends towards a state of chaos. Think about a simple example: if you never clean your kitchen, the result is going to be more and more piled up dishes and bags of trash filling up the corner. This is a state of chaos, and it can be rectified by cleaning -- bringing order back.

This job is easier when there's only a little chaos -- just a dish or two in the sink is way less of a task than dishes that have been there all week!

Software undergoes entropy too. Sometimes we give this the name "software rot" or "technical debt". This is when we've had to do something in a way that could be much better. Sometimes we just don't know better at the time; other times, we know, but we're just trying to get this damn thing to work before the deadline!

But stop and think about this for a while: how motivated are you to clean the kitchen that has dished piled up to the ceiling? How much easier is it to clean the kitchen when there's just one dish in the sink? And how nice is it to start a new batch of cooking with no "debt" lying about, in the way, making it harder to get to the tasty?!

One broken window

It turns out there's a good analogy, studied from people who wanted to know what it took to get a neighborhood into a state of decline, where it went from "fancy" to "ghetto".

One broken window.

This experiment was repeated with a car, left abandoned and untouched for a week, until someone broke one window and the car was stripped within hours.

There's a reason for this: when we see something that's already a bit busted up, we tend to care less about busting it up a little more. And the more it's broken, the less motivation anyone has to come in and clean it up.

How do we fix this?

Well, you could just throw the whole mess into a dumpster fire and start again. This approach doesn't come for free: it's a lot of work to start again. But bigger than that, unless we address the issues that got us here in the first place, we're likely to just end up here again. There was a company I worked at where one of their core systems has literally been rewritten 4 times. Same software stack. The problem is obviously not in the tooling, language or frameworks provided -- it's the build-up of cruft that happens when people don't pay attention to the little issues as they arise.

My approach, something I try to spread around the office, is to fix things as we come across them. This doesn't mean spending time scowling at the last developer who wrote this trash -- if you check the git logs, it may well have been you, when you just didn't know better. If you're constantly learning and evolving, it's natural to come back to older code and realise how much it stinks. And appreciate the learning you've had and the fact that that code still does its job!

I tell people:

We don't have to fix the world -- just the bits we come across, as we come across them. In this way, the world is slightly better with every iteration we make. We're learning and taking responsibility for that world that we traverse. We're making it slightly better for everyone else who comes through here.

Strategy:

1. If it's a small thing, especially if you have tooling to help (like an IDE which can do project-wide renaming for you), then fix it now. It's one less problem to deal with.
2. If it's a larger thing, acknowlege it, patch it if possible, and add a red-bin card to your pipeline. A red-bin card originates from Japanese auto assembly lines, where, if a part came off the line in a bad state, the foreman would take the part out of the assembly process and keep it in a big red bin until the end of the day, when there could be a full investigation into the problem: how did it occur? how do we prevent this in the future?
3. "Not my code" is not an excuse. You're working on a team. Deal with it. Your code has caused others to cringe at some point, so you're just paying your dues. Fix up the code that's there, and, if it was made by someone who keeps making that mistake, perhaps they just need some mentoring! Go talk to them. Not as a confrontation, but more as a "hey, so I did this refactor, and this is why..."