Why Are Developers So Hung Up on Refactoring?

Fabulous hand drawing of a monster truck and a Honda Civic

Are they just obsessive-compulsive?

Are they risk-averse?

Are they afraid of being uncomfortable?

Do they need to grow up?

No, there’s an actual economical reason for this instinct.

To work in a codebase, developers have to build a mental model of it.

It takes energy to keep this model in mind.

(It’s why interruptions are so costly — one phone call or drop-by visit can make the mental model evaporate.)

Some codebases have more complicated mental models than others.

Think of a Honda Civic versus a monster truck.

If you just use your vehicle to get around town, it takes a lot less fuel to drive the Civic.

Like the gas-guzzling monster truck, complicated codebases guzzle mental energy to maintain the mental model.

A developer who’s spending all their mental allowance on gas just to keep the model in mind won’t have much left over to add features or fix bugs.

And just like it’s more expensive to obtain and install parts on a monster truck, adding features to a complicated mental model takes longer and is more exhausting. There’s a higher chance of unexpected bugs. There’s a greater risk of burnout.

The ‘Civic’ mental models are more fun to work with, safer (they cause fewer bugs), and more economical (developers can do more in the same amount of time).

Unfortunately, in software, Honda Civics don’t stay Honda Civics. As new features are added, you have to continually refactor the codebase to keep the mental model simple. If you don’t, your codebase will become a monster truck automatically.

And refactoring “later” is usually much more costly than refactoring when it’s first needed. An ounce of prevention is worth a pound of cure.

So developers are trying to do you a huge favor.

Of course, refactoring is an art. Junior developers often want to refactor All The Things. It takes experience to balance the tradeoffs well.

The key is to have senior developers who are technically capable and have experience addressing business needs. Then give them freedom to refactor when needed.

They’ll be more productive and happier.

If your senior developers are telling you a refactor needs to happen instead of just doing it, pay attention — it may be a sign you’re not letting them do their job.

Want more?

Get notified when I post new stuff.