Get updates by email or on Twitter at @hughdurkin

Measure Twice, Cut Once

Someone once told me a funny story about flying to Canada with their toolbox. They boarded an airplane from Ireland to help friends build a house. Over the years they developed a fondness for their own hammer, saw, and whatever else gets houses built.

Upon arrival in Canada, the border control guy menacingly asked Irish toolbox guy "Why in Canada's name are you bringing all these tools over here?"

His response (delivered with a strong Irish lilt): "Sure I've no idea how the metric system works."

Luckily the border control guy found this hilariously funny, and let him in.

I remembered this story as I read Alex Potrivaev's latest post - Tackling complex design debt: a three-step framework - on the Inside Intercom blog.

It's a great post, with great examples of Conway's Law in action. And working examples of why kicking the API can down the road causes potholes and breaks bridges.

If there's one part of it I might disagree with, it's "moving fast makes you slow." When creating visual user interfaces, this is probably right - as Alex's examples articulate. To quote Alex:

“We had to spend countless hours reimplementing the same features in a slightly different way, leading to a drastic increase in the time to ship”

Yet, thinking holistically through system design first - data structure, how data might interact with other data over time, how operations and actions might transform data - leads to faster product development cycles, not slower development cycles. After all, the famous "Bezos API Mandate" helped Amazon become one of the fastest-moving and most valuable companies in the world.

APIs - built to the same set of standards, and governed well - help standardize communication between small teams in large organisations. Faster communications leads to faster progress.

In Bezos' own words:

"There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network."

This is where an API-First approach works wonders. By describing everything already built, and yet-to-be built, through a common language and framework, rationalization happens before pixels are drawn, and before lines of code are written. As Elizabeth McGuane previously wrote on the Inside Intercom blog "words build a product."

It's not all that different from an Irishman bringing his toolbox to Canada. If two teams are building a house - one working with imperial units, and the other with metric units - it's likely the house will creak and collapse.

You can only "measure twice, cut once" when you know what you're measuring.