Refactoring as a Means of Lowering Cognitive Load
Tags:
October 26th, 2022

Code bases accumulate rot over time. The problem space is explored, the solution is better understood, the original kludges ever more unsightly. But less talked about is the cognitive load that an ancient code base puts on its authors. Every minute adds up, every change ever fraught with tension.

In my last post, I mentioned that moving quickly is invaluable for an organzation. There's almost no price too high to pay. An awful code base blunts your ability to move. It means more must be understood to make any one change. It also means more can go wrong, especially as teams shift and the maintainers leave, taking their wisdom with them.

Refactoring code therefore, perhaps counter-intuitively,  becomes crucial for a fast moving organization. It keeps the code base lean and understandable so features can be developed and shipped more quickly.

As an analogy, let's suppose our business was a restaurant. As we cook food for our guests, we accumulate dirty dishes. These need to be cleaned. Sure, we could wait until morning to clean them but then they'll be even harder to clean. Not only that, we'll be less likely to even want to cook because we have the burden of cleaning them all first. Better is to clean them at the close of day so we're fresh and ready in the morning. This is why we refactor.  

And its best to refactor soon because you can only have so much time. I once had a friend work for a very old legacy firm. They had a four hour deploy time(!) This was mind-numbing, boring, and demoralizing. It had come about as "death by a thousand cuts": every little request that resulted in "only five more minutes"  added up over the decades this process took shape in.

My friend had proposed to refactor this deploy process. Several tangible ideas were put forth. "Surely managemnet would accept this" he thought "Cutting down on deploy times would mean less pressure and less anxiety."

But alas, no. How could you blame them? Management didn't want to change a process that had existed longer than any of them. Nobody knew where the skeletons were kept so any change might unintentionally unearth them. Whomever originally created this was no longer at the company. With so much at stake if a deploy failed, the ugly four hour process stayed.

So refactor. Before its too late.