Don't tell me what to do

Do you know what’s wrong with articles or solutions saying that you should ditch your ORM, abstract everything from the framework, create six layers of abstraction and break you app into dozens of microservices? There’s no silver bullet.

The problem is that developers that advocate a more complex architecture assume that everybody has the same deep knowledge about software design. And that’s simply not true. Sure we have to raise the bar and make less experienced developers improve their game, but you can’t just say what they should do. You don’t know the context of the company. You don’t know if proving a business model is more important than having the perfect software design. You don’t know if a self-taught developer can even understand the implications of what you’re advocating.

And without this context, developers may try to follow your advice and create software that is worst than before, because they just don’t know how to correct apply the patterns you’re promoting.

Every single architecture, every single design pattern, every single solution has pros and cons. Ditching your ORM may have benefits? Maybe. But it also has problems. And here lies the problem. When you’re advocating something, you’re more likely to hide the bad parts of the solution you’re advocating, leaving this exercise to the reader, that may or may not be able to balance these implications.

If you’re advocating something, be honest. Say how your solution is better than other solutions, but also be clear about the implications and known problems.

As a friend once said, don’t tell me what to do, just show me what you did.