Hazardous code begets even more hazardous code—eventually.

If you’ve ever heard of refactoring, I doubt that’s a surprise.

Let’s look at the dynamics of adding code to a system:

Hazardous Code is easier now, but harder to deal with later.

When we make a change, we have to figure out what to change. The difficulty of doing that depends on how good the code is (and how big the change is).

There’s usually an easy path:just jam in something that gets the job done, and don’t worry about the quality of the code.

This gets us lots of short-term love: “Done already? Well done! Way to deliver!” It all sounds great.

But we’ve done a disservice to the code base: it’s worse than when we started. It may not hurt us today or tomorrow, but eventually we find ourselves back in this section of code, struggling to figure out what to change.

Figuring out what to change is a little harder now. Our temptation is to make our next bit of code imitate the slightly tangled code from before.

Beware the Hazardous Code Death Spiral: in a few years, your code may become an unrecoverable mess.

It doesn’t have to be this way: the diagram has another half— the clean code virtuous circle.

Clean code virtuous cirle: harder now, easier later

Here, the opposite happens: we identify the needed area to change, we refactor (before and after our change) to make sure it goes in cleanly. We leave the code a little better.

Next time we’re working in that area, things are just a little easier.

Want to make your job easier? Improve the code every time you touch it.

What can move us toward the virtuous cycle?

  • Be sensitive to which path you’re heading down - are you making things a little worse, or making them a little better?
  • Be patient: if you’re just starting to emphasize the virtuous side, it may take a few months to see the improvement.
  • Make team agreements - and consider pairing or mobbing. Jointly give yourselves permission to work in a way that supports the long term.

None of this is news: refactoring has been around for years, and concern for good design and maintainability for even longer. I hope this diagram reminds you to keep improving your code!

Thanks to Arlo Belshee and Chris Freeman for their comments on an earlier draft.