Thou shalt not build

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