TL;DR These days everyone knows that servers are supposed to be more like cattle than pets. But the same principle applies to the code - caressing it & endlessly tuning it according to completely subjective, quasi-aesthetic criteria is one of the most often committed sins of today's software engineers. Especially as we're speaking about very technical activity that frequently just gets away as it's totally non-transparent for business stakeholders & many managers.
I'll start with a harsh statement: "refactoring" has recently become one of the most devalued terms in software engineering. It became a perfect excuse in conditions that lack transparency - we tend to say ...
"This code needs just a bit of refactoring. Four or eight hours at most."
... whenever we screw up, under-estimate or just try to catch-up after losing time on non-crucial code aspects. Refactoring is a perfect excuse as non-tekkies can't validate its real relevance & if they resist, you can always scare them with mythical (yet tangibly dangerous) beast named Technical Debt ...
But interestingly, even if we truly aim to do a factual refactoring, we tend to easily drift far away from its intended essence - to prove that, let's get back to its definition:
"Code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring improves nonfunctional attributes of the software."
Emphasis (bolding) is mine & it's here for a reason - the whole point of refactoring is to improve the code qualities in an objective, not subjective way. One can endlessly tune a chunk of code left & right by:
- applying numerous patterns & practices (e.g. even more idiomatic implementation of event-driven command handling ...)
- replacing one library/framework with another one, every N weeks
- bumping dependencies every morning to make sure that the most recent nightly build of given framework is being used
- making code more "perfect" / "beautiful" / canonical / adherent to the style introduced by favourite book (or series of blog posts / or conference talk)
... but this does not qualify as real refactoring - this is what I call ... erhm ... code masturbation.
Such practices are neither useful nor beneficial - the only thing they serve is temporal fun & "pumping ego" of their committers ("look how beautiful it is, I've just spent 2 days to refactor these promise-based handlers to ones that used observables, so the code is more reactive now ...").
Who the hell cares?!
"SoftEng Maturity Model"
This is really fundamental - introduced value / improved quality is NEVER based on "code aesthetics" - gods, such a thing doesn't even exist in objective criteria! Refactoring-related decisions have to be made on the basis of well known architecture qualities, e.g. scalability, performance, maintainability, robustness, resilience, etc. And these qualities are supposed to be affected in verifiable, credible & of course beneficial way - without over-interpreting and / or "stretching" the facts.
Let's be blunt here - uncontrolled, excessive code masturb... erhm, making love to code is nothing else than a clear sign of individual's immaturity as a Software Developer. Being skillful in terms of crafting syntactically proper code may be cool & satisfying, but it doesn't prove you're able to effective build complex, high quality systems that provide significant value w/o sacrificing architecture qualities. Focusing on the former only disqualifies (IMHO) an individual (at least temporarily) from aspiring to be a Senior Developer or a Tech Lead of any level.
Birth-control for code ...
What about so-called passionate developers then? Is it wrong to love to code? Does programming have to be boring, crude & minimalist, devoid of any "fun part"? Obviously it's not the point - but professional has to understand the difference between what's OK in skunk project's sandbox & what's OK in production-targeted code. Even for this 2nd category experiments & trials are more then welcome, but:
- in limited quantity and within agreed risk range (at each particular moment in time)
- keeping in mind what are the actual priorities (for ones responsible for the product / service that's being developed)
If you forget / ignore that & ratio between "refactoring" & providing actual value leans dangerously towards the former one, you're basically undermining the trust relationship (which is not something that can recover easily ...) with your business partners - practices I'm describing here may not be visible & clear since the very beginning, but long-term efficiency reduction will at some point get noticed & questioned. Assuming otherwise sounds like treating your counterparts are hopeless idiots, don't you think?
