Advanced patterns never make up for a fragile foundation

I regularly see posts advocating hexagonal architecture, clean architecture, CQRS. These are powerful patterns, readily associated with “serious”, well-designed projects. But too often an essential element is missing from the picture: good development practice.

A two-thousand-line class inside a hexagonal architecture is still a two-thousand-line class. It is an anti-pattern, and above all the signature of a project nobody is in control of: a team following a trend imposed on it, or choices nobody has justified. The layers are there, the diagrams are beautiful, and the code they frame is the same as before.

You can stack the layers and draw the prettiest diagrams. Without SOLID, without clean code, without automated tests, an application does not last long.

A pattern organises the code; it does not make it good

A dependency inverted towards a three-hundred-line method has inverted nothing at all.

What I notice is that the foundation makes no noise. Nobody writes a post to say that their classes are small, that their tests run in a minute and that their names say what they do. Yet those are the things that, quietly, make a project genuinely solid. Advanced patterns never make up for a fragile technical foundation; they only make it harder to see.

So before adopting a pattern, I ask a single question: does the team already master what sits underneath?

If it does, the pattern will give it a frame. If it does not, the pattern will give it an alibi