{"id":35405,"date":"2026-03-03T14:34:40","date_gmt":"2026-03-03T13:34:40","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=35405"},"modified":"2026-03-03T14:34:41","modified_gmt":"2026-03-03T13:34:41","slug":"best-practices-dogma","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/dev-life\/best-practices-dogma\/","title":{"rendered":"The Engineering of the Possible: Beyond the “Best Practices” Dogma"},"content":{"rendered":"\n
When we face a programming problem, we often hear reassuring yet limiting phrases:<\/p>\n\n\n
\"This has already been solved by [insert guru name here], just follow the best practices.\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
On one hand, these words should reassure me: my problem has already been decoded and solved by enlightened minds. On the other hand, they make me feel inadequate, as if I were a heretic unable to see the “light” of the perfect solution, repeating errors long surpassed by hundreds of years of computer history.<\/p>\n\n\n\n
Such phrases lead us to believe that computer science is an exact science, like mathematics, where 2+2 always equals 4. They suggest that if the project is in chaos, if technical debt is suffocating us, or if the client is furious, the fault is exclusively ours: we didn’t correctly apply “The Recipe”. But after years of worn-out keyboards, I start asking myself an uncomfortable question: what if the Gurus’ recipes were a north star, useful for navigation, but dangerous if mistaken for the destination port?<\/p>\n\n\n\n
To paraphrase Accountant Ugo Fantozzi:<\/p>\n\n\n
\"After three months of cursed readings, Fantozzi saw the truth and was slightly disturbed, or rather, he got pissed off like a beast. So they've always taken me for a ride!\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
It’s not about belittling the giants of IT, but understanding that they describe excellence in ideal conditions. Our mission, instead, is the engineering of the possible. A Senior is not someone who survives the mud, but someone who designs a way to reclaim the land, one step at a time.<\/p>\n\n\n\n
The Mirage of “Greenfield” and Strategy in “Brownfield”<\/h2>\n\n\n\n
The “sacred books”, from Extreme Programming to Clean Code, flourish in the “Greenfield”: green meadows where you build from scratch, with top-level teams, elastic budgets, and a culture of failure. Kent Beck, Martin Fowler, Dave Farley, and Robert C. Martin (Uncle Bob) are brilliant minds, but their theories assume a context that in reality is rarer than a unicorn. Memes like<\/p>\n\n\n
\"It must be ready for yesterday\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
are not just jokes, they are the boundaries of our playing field. The reality for most of us is the Brownfield: monoliths layered since 1995, databases with fields named field1, field2, field3 (with a manual explaining the meaning of each) and documentation “in the heads” of former colleagues.<\/p>\n\n\n\n
I remember a project where a trickle of blood came out of my eyes every time I had to understand what was happening in the database. We often work on systems that cannot be touched because “no one knows what happens if you delete that column”. Seniority here is not resignation, it is strategy. Saying “the problem is solved” by citing a book is like suggesting a laser to a surgeon under bombardment. The true professional knows that the goal is not just to save the patient today, but to improve the conditions of the field hospital so that tomorrow the intervention will be easier.<\/p>\n\n\n\n
The Tax on Complexity<\/h2>\n\n\n\n
Test Driven Development is a powerful tool, but if used uncritically it generates convoluted architectures, saturated with useless interfaces used by a single class and fragile mocks that break only because the internal functioning of the program has changed, which remains consistent, but the mock does not.<\/p>\n\n\n\n
The risk is “testable” but unreadable code. For juniors, this pyramid of abstractions is often a source of pride: “Wow, what a fantastic architecture!”. For a Senior, however, there is the bitter awareness that whoever wrote that code might have already left the company before it is necessary to spend nights in production debugging an incomprehensible bug. It is the moment of escape: the code was written to enhance the CV, not to be maintained.<\/p>\n\n\n\n
And Clean Code? The obsession with three-line functions can become a nightmare. I worked on projects where to understand a submission you had to open 18 different files made up of 60% comments inherited like this one taken from the Linux core codebase:<\/p>\n\n\n
The hope here lies in quality as efficiency: 50 lines of sequential code are often more maintainable than a puzzle of abstract micro-functions scattered everywhere, each with a name as long as a sentence and a test that mocks three levels of dependencies. The client doesn’t pay for elegance, they pay for it to work.<\/p>\n\n\n\n
Continuous Delivery vs. Compliance Office<\/h2>\n\n\n\n
Dave Farley teaches us that we should release to production multiple times a day. Deployment should not be an event, but a stress-free “non-event”. Beautiful. But then try saying that to the compliance office of a bank or the security manager of a company handling sensitive data.<\/p>\n\n\n
Ah, you would like to deploy every hour?\nHere is the A-38<\/span> pass to be filled out for<\/span> each release, signed by the department head, the CISO, and the DPO.\nA validated rollback plan is needed and the deployment window<\/span> is Tuesday between 2<\/span> and 4<\/span> AM.<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
The Guru will tell you it’s a cultural problem. But the developer doesn’t have the power to rewrite European banking laws or convince the auditor that “our tests cover everything”. Those rules were born from the blood of real disasters: someone deployed on a Friday night deleting the data of ten thousand clients. Strategic seniority accepts these rubber walls and tries to automate what is possible, without ignoring the constraints of bureaucratic reality.<\/p>\n\n\n\n
Microservices: Scalability vs Simplicity<\/h2>\n\n\n\n
“Monoliths don’t scale”. And so we break efficient systems into 47 microservices communicating with each other with seven different protocols (or direct calls to someone else’s database because there was no time for the API). The dependency graph looks like my son’s drawing at kindergarten when “he liked making circles”.<\/p>\n\n\n\n
Debugging becomes a treasure hunt among desynchronized logs on multiple containers, where tail and grep are considered stuff for poor people. But in my company, we have 100 concurrent users: ONE HUNDRED. A volume of traffic that even a monolith in Visual Basic 6 would handle without sweating. We created immense complexity to solve a problem we didn’t have, just because “Netflix does it like this”. You are not Netflix; you don’t have 10,000 engineers. Seniority is knowing how to say “no” to useless complexity.<\/p>\n\n\n\n
Agile: from manifesto to bureaucracy<\/h2>\n\n\n
\"Individuals and interactions over processes and tools\"<\/span>.<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n<\/figure>\n\n\n\n
Then you find yourself in 45-minute daily standups where no one starts speaking, and when it’s your turn you invent some “gobbledygook” because you’re ashamed to say you lost eight hours of life for a misaligned DB table codepage. We transformed a manifesto of freedom into an industry of certifications, Scrum Masters, SAFe, and KPIs. Agility transforms into bureaucracy with a different vocabulary. The hope is that the essence of Agile lies in the team that truly talks, protecting itself from “ad personam features” dictated by managers asking for estimates based on nothing (or on the feature name itself). Agility is an attitude, not a board on Jira.<\/p>\n\n\n\n
Managing Debt: Beyond the TODO Syndrome<\/h2>\n\n\n
\"Leave the code better than you found it\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
A golden rule, but one that must not become a justification for infinite refactoring that slips deadlines. The Senior knows that adding an “ugly if” is not a defeat if done methodically. It’s not enough to write a TODO that no one will ever read.<\/p>\n\n\n\n
Managing debt means negotiating it: you insert the patch to meet the deadline, open a refactoring ticket, and agree that the technical “loan” must be repaid. Maybe in August, when you have time to think because everyone is at the beach (and you’ll go in September). This is the difference between a Senior and an amateur: the first contracts a conscious debt, the second creates an involuntary disaster.<\/p>\n\n\n\n<\/figure>\n\n\n\n
The Tavernello Metaphor: Scope vs Quality<\/h2>\n\n\n\n
Once they told me:<\/p>\n\n\n
\"If you have 3 euros in your pocket, you buy a Tavernello, not a Barolo.\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
It’s a powerful analogy. In IT, using a product that doesn’t correctly cover requirements can cause bigger problems than those you’d have buying a high-end product. The true compromise shouldn’t be about intrinsic quality (the code must be correct, secure, and tested), but scope (what we do). If you have a low budget, don’t cook a lousy wedding lunch: prepare an excellent pasta with tomato sauce. Simplify the requirements, not the care with which you write lines of code.<\/p>\n\n\n\n
I remember a video where Luca Mezzalira spoke about DAZN: to change the year in the site footers, they edit 4 files by hand. Dirty solution? Maybe. But in 5 minutes it’s done, zero risk, and very low impact. If microservices Gurus do it, maybe it’s not so wrong. That “ugly” code often survives years generating value, while “beautiful” over-engineered code is rewritten after six months because no one knows how to touch it.<\/p>\n\n\n\n
The Gurus sell books, we sell solutions<\/h2>\n\n\n\n
The Gurus are starred chefs who buy top-choice ingredients. We are the cooks who have to feed 200 people in an hour. If you try to replicate the Tiramisu recipe of Iginio Massari without having the time for homemade ladyfingers, you’ll end up with people going home annoyed by the wait. Use supermarket cookies and concentrate on a decent cream.<\/p>\n\n\n\n
We must create solutions based on reality. The Gurus point to the peak, but we are the ones who have to trace the path through the brambles. Excellence is providing the maximum possible quality within the given constraints, not complaining about the constraints themselves.<\/p>\n\n\n\n
So are we old or senior?<\/h2>\n\n\n\n<\/figure>\n\n\n\n
The difference is that the old one has stopped learning, the senior has stopped being a fanatic. The senior has studied the rules so well that they know exactly when to break them to save the project, transforming that exception into a conscious act of engineering.<\/p>\n\n\n\n
They have learned that “it depends” is the most honest answer. That perfect code is the enemy of working code. That delivering 90% on time is better than 100% late. And if this means passing for someone who “lives in the comfort zone” in the eyes of those doing vibe coding with the latest framework advertised on X: I’ll get over it.<\/p>\n\n\n\n
See you in the trenches. We wallow in the mud, keep monoliths standing, and build bridges. Because in the end, the fault is not with the Gurus who made us believe in perfection, but ours if we stopped looking for possible excellence to chase the imaginary one.<\/p>\n","protected":false},"excerpt":{"rendered":"
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-2-nanobanana.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-3-nanobanana.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-en-infografica.png\")
<\/figure>\n\n\n\n