Paul Hammant's Blog: Conway's Observation

Melvin Conway doesn’t intend his observation on dev teams (and the applications/services they build) to be advice or a call to action. Instead he thinks of it as an observation. In his own write-up (that is very much worth reading), he notes that Conway’s “Law” wasn’t even his coin. It has really irritated me that software development organizations teams are choosing to shard their development because they think it is advice, instead of finding ways to not do so shard dev teams.

Dan Woods on Forbes.com (“How Platforms Are Neutralizing Conway’s Law”) gives a good write-up of Joshua McKenty’s great Conway’s observation related presentation and how he thinks differently on teams and whatnot these days. It was at a Redis conference in June. Among many other points, it was suggested Redis was the antidote this org sharding situation See the video of “Death to Conway’s Law” for yourself.

When I imagine the stereotype of Conway’s related thinking, I think of a team (in a meeting room with a shut door) convincing themselves that the thing they are making should actually listen on its own socket, have a wire API, and ship with extensive installation and ownership information. When in fact someone higher up the technical org chart, were they present, would want to say that it should ‘only’ be a library and not a remote service (nor a framework, as that is a resistible direction that teams can head in too).

Redis is a prod-time tool for your application/service. Meaning it finds its way to production with the code that you write. Things like Jenkins, JUnit, Selenium, Maven, WebPack, Git and alike are build-time tools that are not part of a set of things that are in the prod stack. Then there’s development activities and methodologies that affect the thing that goes into source control (that later goes to prod), which is not a tool as such. Writing unit/service/functional tests is dev time activity too. What you do with build-time tools and development activities also informs your Conway’s outcomes. An obvious example is tests that represent other teams’ use cases for the unit in question but are closer your build (and not just in theirs).

Going back to the middle 2000’s: Google had many years of operating their monorepo. While teams could set their own direction they could only do so within some centrally/globally defined constraints for things working in public for HTTP traffic. One was “use cookies, redirects per 1995’s web”. Another was the use of BigTable for storage with ProtoBufs for effective record formats. Back then teams also used Memcached (similar to Redis but more basic perhaps because it was 6 years before it). All of those together allowed teams to cooperate beyond their immediate boundaries far more. So did the build rules that came with Bazel (nee Blaze). So did the related expanding contracting tech that morphed your working copy to suit the inter/intra/extra coding task you were needing to pivot to temporarily. And that cooperation guided by constraints allowed for an observer to say that manifestations of Conway’s minimal and low friction.

Google is a special case though: It’s led by technologists, not business people. It works on alignment through training and sets constraints before granting team autonomy. I think that last is Carl von Clausewitz’s (1780 - 1831) thinking¹, though that’s now coming into business and development.

Anyway, we shouldn’t say it is just platform or a caching tech as the antidote to Conway’s in a development org, although that was part of it.