Conway's Law, APIs, And People

Melvin Conway introduced Conway’s Law in 1967. It states:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

In actionable terms, it means:

“If you design the org before you design the system, the system will look like the org.”

This is not a good thing.

A few years back, at peak frustration with Apple (after being a complete fanboy for the previous decade), I tried update some credit card details stored in my Apple account. But there was no single, clear place to do it.

I logged into my iTunes account. Nothing. I logged in to my Apple Store account. Nothing there, either. I logged into the support website. No joy.

Somewhere along the way I realised I’d logged into what should have been the same system, three different ways. And yet, by the end, I wasn’t logged into any of them.

Different systems, with similar capabilities, each acting a different ways.

Conway’s Law in action. Today, as a Chrome OS fanboy, my life is much simpler. Ironically, it just works.

I’m hopeful - in an increasingly API first world - the simplicity of Chome OS will permeate every product and service I use. APIs can be the antidote to Conway’s Law.

Zalando’s “Purpose” statement in their excellent Restful API guidelines explains why:

“Great RESTful APIs look like they were designed by a single team.”

APIs are often thought of as “features” with creation, maintenance, and documentation of them silo’d into separate teams. Screens are designed before systems, and APIs become a fast-follow (or slow-follow) consideration. Nothing “just works” as a result.

Thankfully, Platforms can help neutralize Conway’s Law, with even larger Platforms like Microsoft highlighting the need to fight against it. But the war hasn’t been won - yet.