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).
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) thinking1, 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.
Clausewitz credits Napoleon, Frederick II, Gustavus Adolphus, Caesar, Hannibal, and Alexander. I’m sure Sun Tzu through them if not explicitly. Helmuth von Moltke the Elder is there too distilling and refining the science (alive at the end of Clausewitz life). In the military modern era, “Command Intent” is it (this 2010 HBR article does it well), and Stephen Bungay summarizes/distills it all for development folks with The Executive’s Trinity courtesy of InfoQ. I’m listing other writers here because this stuff is quantum entangled with Conway’s observation. ↩