What Conway’s Law Teaches Us About Engineering
Have you heard of Conway’s Law? It’s an observation put forward by computer scientist Melvin Conway in 1967 about the relationships between designs and the systems they’re created in- specifically:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
It’s a statement that gets software developers excited, who- I have noticed, tend to be a bit more predisposed to systems thinking than civil engineers. This is a bit of a shame, because the insight is just as valid for those of us designing structures and building infrastructures as it is for programmers.
The idea is fairly simple. Consider this fairly extreme example: Two people are building a shed- one person is designing and constructing the walls, the other the roof. Because of an incident at a party five years ago, the two don’t talk. Instead the mutual friend they’re building this shed for is forced to pass messages between them. The result is a roof on stilts with a walling system running around it, wedged together by shims.
The shed reflects the team organisation. The designers were independent and thus created completely separate systems. They were unwilling to trust or work with each other, so therefore the roof and walls were self-reliant; complete structures in their own right. Only the minimum of information passed between the two, and thus only the broad strokes understood by their mutual friend could be communicated- overall dimensions. In the end the friend who asked for the shed still needed to shim the two systems together to get what was wanted.
I’ll grant that the example is a touch contrived (most of the canonical examples are to do with system’s architecture); and you might argue that even the most stubborn of feuds wouldn’t result in a roof on stilts. But the notion that the organisation of a team is reflected in what they create has been academically established. Small, co-located teams create more tightly coupled and monolithic products, whilst distributed teams take modular approaches with more rigid interfaces.
Civil engineers deliver monolithic projects; a tall building is pretty much the incarnation of the monolith! However we typically work in single-discipline, distributed, teams that communicate in coarse-grained units (issues of drawings, long meetings, question and response e-mails.). Conway’s law states that what we deliver is therefore modular and badly integrated.
And I’d argue that’s right. The architect hands down some drawings, the structural engineer attempts to make things work, the building services team then put holes in everything requiring the structural engineer to lay down some heavy handed ‘no-services-zones’; upsetting the architect who then throws up some uncompromising rules of their own. And then they all turn around to the geotechnical engineer and say “make this stand up; don’t change anything”. Not forgetting the now heavily constrained acoustic, interior, and who-knows-what-else designers that end up turning out less-than-optimal solutions in their own silos.
This is an example of systems tension- you are trying to design something that contrasts with the nature of the system it is being designed in. Distributed and modular systems are common in software where the problems are naturally loosely coupled – a complete redesign of Spotify’s phone App has pretty much no impact on their massive data storage systems, and so multiple teams focused on one aspect of the product is a viable (and advantageous) model.
Moving a staircase in a building, changing the tower height of a bridge or moving the centre of gravity over a foundation all have a significant impact on the whole system design. In fact, pretty much every change you make to a structure has to be accommodated by at least someone else, and vice versa; the problem is tightly coupled.
Pretending monolithic structures can be delivered by modular teams might be one of the biggest fallacies in construction.
Conway’s law accepted- the way we manage the delivery of our projects is literally the worse way of doing it. To realise the best solutions with the minimum of compromise (a worse man than me would have used the word synergise there) you need a single, co-located, cross-disciplinary team who regularly work together and have established a trusting relationship.
Perhaps it’s time to start thinking about how we work our projects…