Beware Best Practice

Developers love to read about best practices on their favourite technology.

Just look at any popular link curation newsletter in the tech space and I bet a large share of the articles will mention “best practice” somewhere.

I get the appeal. Some trusted authority (either an organisation or individual) has already made this decision so you, the application developer or architect, doesn’t have to. It’s one less choice you have to make when you’re already pressured for time. And because “other people are doing it this way”, you gain some confidence that help should be easy to find if you hit issues down the line.

Don’t get me wrong, I’m all for standing on the shoulders of giants. When making a technical decision in an area you’re unfamiliar with, you absolutely should research how others are doing it instead of just rolling your own solution.

Where I take issue with “best practice” is that I see many folks finding the term beside a recommendation and stopping their research right there without trying to understand the reasoning behind it.

This is particularly rife in the serverless community where many development and architectural practices are still immature and far from being universally accepted.

“AWS say that single-table DynamoDB design is best practice so we’re going to follow that”. But should you?

“BigTechCo use one Git repo per microservice so we should too.”

“Paul Swail says that all your Lambda functions should be single-purpose so I’ll follow his lead.

I harp on a lot about context, but it’s so often neglected in technical decision making.

The producers of technical content and advice (myself included) have an onus on them to provide the reasoning for their recommendations and the contexts from which they came to their conclusion. What type of workloads does this work best with? What type/size of team or organisation is this best fitted for? And so on.

And you, as the developer or architect consuming this content, need to have a critical eye open when reading it. Focus less on the “how” and more on the “why” and “when” of the authority’s recommendation. If these aspects aren’t present, then be skeptical and seek out other sources.

Very few best practice recommendations hold true in the universal context.

— Paul.