Clean-obsessed

02 Mar, 2025

Note: This is a translation from the original post in Spanish. I’ve done my best to keep the tone and meaning, but some things might feel a little different.

There are days when you wake up wanting to blow something up.

Do you remember leaded gasoline and chlorofluorocarbons (the famous CFCs)? Both were once hailed as revolutionary advancements, but over time, they proved disastrous for human health and the environment. The case of leaded gasoline is particularly painful, as its toxicity had been known for decades. Its inventor, Thomas Midgley—well-intentioned as he was—never questioned the long-term impact of his ideas. Neither did engine manufacturers and other industry players until restrictions had to be forcibly imposed.

A more recent case: Dr. Alain Ducan in France, who was expelled from the medical board for promoting unscientific practices that endangered patients' lives. Medicine, being a mature and strictly regulated discipline, does not allow individuals without solid empirical backing to dictate how healthcare professionals should work. Nevertheless, many people blindly embraced the "Ducan Method" as a quick way to lose weight.

Both cases demonstrate how the absence of critical thinking toward certain ideas can lead to disaster. In software, although the consequences are fortunately never as dramatic as in the previous examples, the uncritical acceptance of certain dogmas has caused (and continues to cause) havoc in code productivity and maintainability in far too many projects.

We belong to an industry where anyone with a decently worded idea and the courage to format a book can become a guru. It doesn’t matter if their proposal lacks real-world experience; all it takes is a flashy book title and a strong sales pitch. This has happened with the philosophy of Clean Code, Domain-Driven Design (DDD), and Hexagonal Architecture, among other trends. Rather than being useful philosophies to consider in certain circumstances, they have become unquestionable dogmas for many.

Before you keep reading, let me clarify: the point here is to illustrate the lack of discernment when applying ideas. I am not comparing your precious clean and decoupled code to poisoning the planet or killing an insecure fat person.

Embracing dogmas

Like it or not, language carries weight. A lot of weight. Some believe that labeling any code produced by a particular methodology as "clean" will magically make it so. By logical contrast, any code not generated in this way must be "dirty." What they fail to understand is that, just as calling a cramped, foul-smelling airport stall a "restroom" doesn’t make it a place of peace and relaxation, calling a methodology "clean" doesn’t make it inherently superior.

The Clean Code philosophy, popularized by Robert C. Martin, has been interpreted as a set of absolute rules rather than what it really is: a collection of suggestions that may or may not be applicable depending on the context. In many environments, Clean Code has gone from being a mere set of best practices to becoming a dogma applied without question in pursuit of "clean" code (according to its definition, of course) at any cost. Even if that means a tangle of classes, useless abstractions, and unnecessary layers that add no real value beyond the pleasure of the devoted practitioner.

Something similar happens with Hexagonal Architecture and DDD. These approaches are very useful in certain contexts, but they have been imposed as universal truths. They are applied even in tiny projects where a simple layered architecture or a pragmatic approach would be far more efficient. The result: unreadable code, overengineering, and an artificially steep learning curve for any new developer joining the team.

Trivia

Did you know that Bob Martin has spent almost his entire professional life "ideating and evangelizing" and has no known significant projects or code outside of what he has written to illustrate his proposals? Oh! And he has included the word "clean" in the titles of all five of his books written since 2009. A similar case can be found with Alistair Cockburn (another theorist) and his Hexagonal Architecture. However, DDD does seem to come from someone with demonstrable experience (Eric Evans).

Although I have actively searched for a considerable time and have found nothing, I may have incorrect information. I would be delighted if someone could point me to any resource that proves me wrong.

Why do we do it?

The problem is not just the proliferation of these dogmas but the fact that there are clear examples of how pragmatism has led to superior solutions in maintainability and impact.

Projects like Ruby on Rails, SQLite, Redis, Linux, and Go, among others, have demonstrated that simplicity and efficiency can go a long way without resorting to complex architectures. Interestingly, they are the foundation upon which many systems adhering to Clean Code and Hexagonal Architecture principles are built.

Why, then, are they not considered examples to follow by those who promote these methodologies? If their principles were truly infallible, wouldn’t it be logical for the most successful systems to have applied them from their conception? Shouldn’t the industry have naturally arrived at these conclusions after the immense number of man-hours invested in software development?

And yet, the projects and professionals who keep the internet running have always prioritized efficiency and simplicity over overengineering. If major technological infrastructures rely on pragmatic solutions, what sense does it make to impose overly complicated architectures on significantly smaller projects?

The answer is simple: the industry embraces trends and glorifies texts written by people who have rarely built real software with real impact at a real scale. In this industry, an author with good marketing has more influence than an engineer with real-world production experience. And in many cases, the only difference is that one wrote a book and the other did not.

Even worse, these methodologies are not only misapplied in many cases. They are taught as unquestionable dogmas, perpetuating this problem. Instead of training engineers with judgment and the ability to form an informed opinion based on years of experience, they are trained to follow rules without questioning them. Because, who wouldn’t want to write "clean code"? Who would be the idiot who works with a dirty and, oh God, coupled architecture?

When these engineers enter the real world, they replicate these patterns without assessing whether they are appropriate for the context in which they work. In other technical disciplines, methodological errors are corrected with rigorous training and, why not, regulation. In software, this structural correction is not possible, allowing overengineering and inefficiency to spread unchecked.

In our case, the community should collectively have the maturity to naturally reject charlatans: by confronting their rhetoric, leaving baseless trends behind, and valuing real experience over catchy phrases. Instead of elevating those who sell attractive theories without practical support, we should listen to those who have built functional software and learned from real-world problems.

Pragmatism over dogma

Books are meant to be read, analyzed, and to extract the best lessons they offer—if they have any. The problems programmers face have been the same since the early days of computing. If there were a mechanical way to achieve ideal code, the problem would have been solved over 40 years ago: there would be a manual, not an endless list of bestsellers.

Progressing in this profession requires learning to value experience over rhetoric, utility over aesthetics, and pragmatism over blind adherence to methodologies. Software does not need immutable rules. The principles of any methodology should be tools, not commandments. Clean code will never exist, but code with appropriate abstractions and semantics does—and that doesn’t imply overengineering, but balance and common sense.

In my opinion, being pragmatic is neither rejecting nor blindly embracing methodologies. It is applying them when they genuinely add value.