This is the second of a series of posts covering what I learnt at Velocity Amsterdam 2015. During the second day, Mike Amundsen of CA Technologies shared his insights into the works of Melvin Conway. While Conway’s Law may be well known, it is only stated as the thesis of his article “How do committees invent?“. Mike showed that there is much more to be learnt from Conway’s paper.
Conway begins by describing a generalisation of a design organisation. I’ll talk in terms of a software design organisation instead. He goes on to argue that the life cycle of a system design goes through these stages:
- Acknowledgement of the boundaries surrounding the organisation and the system to be designed
- Choice of an initial system concept
- Delegation of tasks according to the concept
- Coordination among delegated tasks
- Merging of sub-designs into a single design
These steps are not necessarily carried out from beginning to end as better design concepts may arise. This brings forward an important statement made by Conway.
“There is never enough time to do something right, but there’s always enough time to do it over.”
It is very easy to jump in and start designing an elegant solution that attempts to cover every corner case. Such a solution could amount to weeks of effort when in fact a simpler solution may be satisfactory. Small, incremental changes can be managed more easily. If coupled with continuous integration, early user feedback can be used to help identify poor design (or sub-design) concepts.
Conway goes on to show how we can describe a system using a graph where nodes represent the sub-systems within the system. Sub-systems can be broken down into finer components until we have a set of sufficiently simple sub-systems. If two nodes x and y communicate, then an edge is created between x and y. The image below shows a system in blue with sub-systems in red. These sub-systems have further sub-systems in green.
If we now consider an organisation’s structure, we can think of nodes as being design groups and edges being coordinators between those groups. Here arises Conway’s second claim:
This seems a very reasonable statement; a design group must coordinate with a second design group if they require that their component communicates with the second. Similarly, a design group is unlikely to communicate with a second design group if they do not require it.
Mark argued that this meant cross-team independence is important. A team should contain all of the members required to produce the component. Organising a team by product makes it more likely for that team of designers, developers and testers to work independently from other teams. If a product is very large, then it may be possible to break it down into sub-systems. These can then be isolated to a point at which the requirement for coordination is minimal, if not zero.
Conway takes the matter of coordination effort further. If a design is expected to be large, there can be a temptation to increase the number of people on the project. Larger teams require a larger coordination effort from management. The greater the number of layers of communication, the greater the opportunity for lack of communication. Not only that, the quality of communication is also at risk. This seems to imply an isomorphism between the designs of the system and the organisation. If the communication structure disintegrates between members of the organisation, then the communication structure between components will also disintegrate (as a well defined interface between components can’t exist without coordination between the teams building those components). This leads on to Conway’s third statement:
“A large system’s structure is more likely to disintegrate during development than a small system’s structure.”
Not only does this reflect between teams, but also between members of an individual team. Dunbar’s number reveals that humans are only capable of managing around 15 close relationships at a time. If a team is too large, the effort required to communicate well with all members will also be too large.
Amazon’s Jeff Bezos gives great advice on this matter:
“If a team can’t be fed with two pizzas, it’s too large.”
Finally, we arrive at Conway’s Law :
“A system’s design mirrors the communication structure of the organisation designing it.”
Ease of communication should be a primary concern. Instant messaging applications and conference calls can help improve communication between distant teams in similar time zones. Wiki style or forum based applications can also be used, particularly if teams work over more distant time zones.
For a system to be flexible in an agile environment, the organisation must also be flexible. Teams must have independence in order to adapt quickly in such an environment. This means having all the resources they need within the team (both human and technological). If coordination is required between teams, it needs to be effortless.
Mark’s original slides can be found here.