Beyond 'Conway's Law'

When I'm "out and about" talking to people about software recently, it always seems that I circle back to "Conway's Law."  It's been on my mind quite a bit recently.  I'm continually stunned by the number of people who haven't heard about it.

 In a nutshell, 'Conway's Law' is a maxim named in reocognition of Melvin Conway.  He said that "...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."  In many restatements of the law, the word "constrained" is replaced with "doomed", but that is another story. 

The gist of the law is that people and social structures are a non-removable part of the development picture.  It's nearly impossible to have separated teams in a large project without someone developing some sort of a narrow software interface between the code that each team is working on.  And, that makes sense.  You communicate more with the people on your team and less with the people "over there."  As a result, you are more likely to ask yourself "what's the piece of that other system that I need to know about" and the people on the other team start thinking "how do we provide some way for teams to use our stuff without mucking around in its internals."  The result of the clash of these two forces is often an API.  Oddly enough, even if people aren't thinking consciously about it, they still arrive at something which approaches a rough API.

When people first hear about Conway's Law, they often get a jolt of recognition and then a sense of doom. They remember all of the big systems they've worked on and they realize that, in a way, their architectures were much more at the mercy of organizational politics than they had hoped.  But, there is a bright side.  When an organization is aware of Conway's Law, it can leverage it to build great systems.

So, oddly, when I started this blog, I didn't want to talk about Conway's Law.  I wanted to talk about something slightly beyond it.  Conway's Law is about software structure mirroring organizational structure.  I think there's a corollary related to process - the way that we work.

Peter Provost at Microsoft related some stories in 'The Butterfly Effect', a presentation he gave at Agile2010.  He described the effect of having a quality-oriented culture that attempts to solve quality problems by making it harder to check in.  These sorts of cultures aren't uncommon.  I've run into quite a few of them.  Often things have to get pretty bad before a high "checkin-gate" is put in place, but sometimes it's just a response to scale.  If you have many developers on a project, you want to have some control, and requiring code reviews, and QA reviews, and style checks, etc can be a way to do it.  How can that be bad?  Well, for one thing, people do respond to disincentives.  When you put a time and frustration tax on checking in code, people just don't do it as often.  Transparency of work suffers and, quite like a dropping a pebble in a pond causes ripples, you can have delays of higher duration rippling out from that slow cadence of commits. Interestingly enough, quality can suffer as a result. Chalk this one up to the 'Law of Unintended Consequences', but still it's not quite what I was aiming to write about. 

 The thing I wanted to write about is how all of this affects the code.  In the day, I used to visit a lot of teams that used an "honest to god" waterfall process.  I know that some people today think that the waterfall process is some sort of a myth, but you know, it really happened.  All over the place.  The thing is, there was a studiousness to a lot of the code that I saw back then.  Today, we'd probably call it over-engineered, but it did seem like was shaped a little bit differently from a lot of code I see today.  More macro coherence than micro coherence.  It's hard to get at what it is without over-generalizing so I'll spare you.  But, really it should just stand to reason that this is true.  Our cycle times for change are far more rapid than they used to be and that has to have some influence on shape.  The thing that has me very curious right now, is how 'continuous deployment' might affect the shape of the design of our code.  When you are in a continuous deployment environment there is even more pressure toward small steps, and people are more likely to use devices like feature toggles when they want make larger changes.  And, well, that's sort of like a tax also.  We shouldn't be surprised if our code ends up having a different shape.

So, back to Conway.  I think there's a related law that has to do with process, but I don't think it's as a simple as Conway and I don't think it is as simple as saying that designs mirror the process structure used in their production.  Perhaps, over time, we'll know more.

 

Comments

[Serverdude]

How much are we then doomed to build software by the layout and convolutions of the languages and IDEs we use?

When I'm trying to think in FP after ages of OO and imperative languages it makes me question my abilities to get anything done.

Reading this post and having just earlier seen Ward Cunningham talk about wiki spaces http://www.wikisym.org/2009/10/22/wikis4se-workshop-on-wikis-for-software-engineering/ - would that help? Unless, of course, people simply stick to their named spaces.

[Brown_note]

I thought Convey's law was more about the client org structure and that the Dec team's structure was secondary. Certainly looks that way when I look around.

[Ronald Woan]

One of the most interesting applications of Conway's Law is I am told that there are to be no synchronous transactions between the services of Amazon development teams... Not sure if this is strictly true...

[iPhone contacts backup]

thinking about it and do practice with the method

[cheap clothes]

181 What a fun p tern! It’s great to hear from you and see what you’ve sent up to. All of the ojects look great! You make it so simple to this.Thanks!
http://www.clotheswholesalecheap.com