Thou shalt not build

Thou shalt not build

StrategyDaily Email

As software developers, there is something fundamental in many of our DNA driving us to build, or to at least have that as our default starting position — “We’ll build our own unless we find a tool or service that does exactly what we need”.

Building is our comfort zone, creating something new with code brings us satisfaction and choosing to build doesn’t lock us into any unwanted constraints in the future. After all, we can always build our way out of them!

If you haven’t read them yet, the 10 Commandments of the Serverless Manifesto are worth a minute of your time.

The first commandment turns this innate default position on its head:

  1. Build only what differentiates you, outsource what doesn’t.

Outsourcing here means cutting the time spent by your in-house engineering teams and moving it elsewhere. Some examples:

  • Using a publicly available runtime library or framework rather than writing your own implementation
  • Using a publicly available deployment tool or framework over writing your own bash scripts
  • Renting a service from your cloud provider over provisioning and hosting your own infrastructure
  • Renting a specialised SaaS product over composing your own cloud services
  • Hiring a third party contractor to build/operate part of a system instead of doing it all in-house
  • And my personal favourite: moving the idea to your project icebox after deciding it’s not that important after all. Life is short and opportunity cost is real.

Outsourcing has its own costs, of course:

  • the direct financial cost of paying for the service
  • overhead to your organisation of selecting the right framework/service/partner and managing its ongoing maintenance/operation/relationship
  • you have to live with missing or imperfect features and accept that the resolution of service degradations, breaches and bug fixes are generally out of your own timeline of control

So how do you decide if these outsourcing costs outweigh the control and flexibility you get by building your own implementation?

Put differently: how do you identify what differentiates your company or product? That’s something I hope to write about soon.

— 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 starts on November 2, 2020. Sign up by October 26, 2020 to get a 25% discount.

    Learn more...