Beware Best Practice

AWSArchitectureSoftware EngineeringDaily Email

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.” _

The components of Best Practice

I know I’ve harped on a lot recently 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.

Originally published .

Other articles you might enjoy:

Free Email Course

How to transition your team to a serverless-first mindset

In this 5-day email course, you’ll learn:

  • Lesson 1: Why serverless is inevitable
  • Lesson 2: How to identify a candidate project for your first serverless application
  • Lesson 3: How to compose the building blocks that AWS provides
  • Lesson 4: Common mistakes to avoid when building your first serverless application
  • Lesson 5: How to break ground on your first serverless project

    Serverless Testing Workshop

    Testing is one of the hardest challenges for developers building with serverless on AWS. Event-driven async flows and inadequate local environments make it difficult to write effective tests while maintaining a fast feedback loop.

    In this 4-week online workshop, you’ll learn:

    • Patterns for writing tests for commonly used AWS services
    • What you should and what you shouldn’t write tests for
    • How and when to deploy unit, integration and end-to-end tests
    • How to manage test configuration and maximise test reusability throughout your pipeline
    • Workflow optimisation techniques

    Plus with the weekly group sessions, you get personal feedback on your testing questions.

    The next workshop is in November 2020. Early bird subscribers get a large discount.

    Learn more...