Hazardous Code Death Spiral (and a Cure)
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:
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.
It doesn't have to be this way: the diagram has another half— the clean code virtuous circle.
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.
every time you touch it. [Tweet this]
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.