Refactoring as Anxiety Relief

2 min read Original article ↗

There’s a meta code smell I’d like to now dub the Anxiety Rug. It goes like this: a long file provokes your sensibilities, so you swipe it under the rug into a tree of files and folders; a shrunken scrollbar portends bad omens and demands a slew of micro helper / manager / servicer classes; a server has the audacity of trying to respond to more than one request, and is quickly shoe-horned into its rightful place as a cog in the machine. This is reminiscent of “In Smalltalk, everything happens somewhere else”.

On the flip side, two eerily similar but not quite the same functions are turned into one basketcase of conditionals and edge cases; a wrapper is introduced to orchestrate several functions and, little by little, accumulates fat and configuration options inbetween their seams; A group of services is identified as having some common functionality, and authority is rolled over to a common governor which suddenly does too many things.

The cycle continues. On Mondays we say Don’t Repeat Yourself, on Tuesday Everything Should Do One Thing and One Thing Only. A large part of programming is an inane battle of semantics. There is no free lunch in understanding a new codebase. No Zen in an all-in-one monolith, no bliss in a swarm of micro-services. In between, a million different configurations, and no one will agree with you on the right one. Take a month, and you won’t even agree with yourself.

Some things – especially at the edge where software meets the real world and its needs – are inherently complex. Nothing you can do about it. No amount of mixing and mashing will take it away. It’s just the way things are. Some things are problems, and they can be solved. Others are difficulties, and they can only be recognized, alleviated, and endured. Understanding which is which helps in dealing with the anxiety and saves pointless reorganization exercises.