Manageable Code Over Clean Code #

The notion of clean code is confusing. It enforces a set of rules that sound very good on paper but might not be beneficial at all for the project or the team.

It suffers from the same logical fallacy of picking a similar tech-stack as one of BigTech™ does or implementing your own abstract framework similar to existing open source solutions just to get to a similar end result. It also provides the perfect scapegoat for when the inevitable fuck-up happens.

The “What if one day … ?” is not worth the trouble and effort in the software world. The only time a piece of code requires a change is when the scope of what it has to do also changes. It’s a bliss to not have to think about any inherent system degradation that might happen over time.

This is not true in the engineering world where this thinking of starting any project, big or small, only within the standards is the de facto way of doings things. In all fairness, it makes sense to do it this way when you take into consideration that a hardware project has to take into consideration the inevitable degradation of the materials over time. Following a stric set of standards also helps with the maintenance of a project. A bridge might be built a single company but maintained over time by a few dozens. Almost any task performed, be it for some enhancement or keeping things tidy up, hinders or completely interrupts operations. The easier it is to make any change, the better. At this point, building with the maintenance in mind gets you extra points as an engineer.

In comparison, maintaining or even changing large chunks of a codebase is a no brainer task. If a new team, even within the same company, needs to make a change can just do so and deploy the change with a slight inconvenience, sometimes even without anyone noticing. And the best part is it can be done at any scale. And in case the change is not right, the rollback process is just as easy.

Enforcing strict ways of work like Test Driven Development in an environment where change is cheap and and the system can easily be reverted to an operation state will only make everyone miserable but the consultant who got paid a fee for convincing everyone that the problem is how the code is written not how the code is thought about.

So then why adopt practices that solve problems the software world doesn’t have? No other reason other than an attempt to provide a common language across all the coders that will work on a project within its lifespan. But since the any change is cheap in the software world, this is a wasted effort.

Instead of aiming at creating a common language that everyone speaks and forces their project to fit into, efforts would be better spent at improving how to convey meaning into any structure by naming things properly, letting the details be details, encapsulating policies not laziness, and writing code with the head not the ego.

To change our perspective on refactoring from something that nobody wants to do deal with to being the one true advantage of the software world.