At Agile Coach Camp Barcelona, I lead an Open Space discussion around the implications of Conway’s Law. I started the session by stating Conway’s Law as:- "Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure." More details can be found here.
We were outside by the pool and it was a little breezy so we taped a single sheet of paper to the easel, I then attempted to squeeze in all of our notes on it. Looking at the photo of those notes (below) it looks like a jumble of words! Here’s an attempt to unpack some of our discussion, I hope anyone who was there will add their own comments to this post.
Conway's Law appears an obvious conclusion for anyone to make in organizations where a team is responsible for (and in many cases is named) after a technology layer or component of the system. You’ve probably also worked with organizations where teams are organized around skills with front-end, server-side, and database teams. These organizations often also split out specialist functions such as QA and Support from development and teams are considered resource pools for multiple ongoing projects. When teams and system are organized in this way it’s pretty typical for those teams to try to resolve problems in the area/layer which is easiest for them to influence (the immediate one they have control over) therwize they become blocked on waiting for another team. Such organisational structures often leads to bloat in the code as data/logic builds up in the area the team controls rather than the place it's supposed to be.
Agile software development attempts to combat bottlenecks that build up around resource constrained areas by creating cross-functional teams with access to all the layers they need to change. Agile teams are then free to implement vertical slices of functionality across these layers iteratively. Now teams can more easier put data/logic in the appropriate place as they have access to the full stack and don’t have to wait for another team to help them out.
However, each Agile team tends to invent its own preferred solutions for problems that are common to other teams, such as user login, logging, etc. As each team is encouraged to be “self-organising” communication between teams and to shared stakeholders becomes more fraught. Teams often adopt different favours of agile and tools that impede moving functionality between teams. All we’ve done is turn things sideways!
For larger scale systems, we hit limits of understanding and separate systems more formally so that we can delimit ownership. We might attempt to form Feature Teams that can work across systems to deliver one giant feature after another. However, we then run into a “tragedy of the commons” where no one wants to own responsibility for keeping hairy areas of the code free from cruft. Feature teams tend to be focused on short term functionality not longer term health of the system. Soon “broken windows” start appearing because developers don’t have to live with the code they write.
We may need to introduce big-picture architects and low-level component guardians to care about the macro and micro state of the code. But for large systems, communication becomes a time-consuming nightmare. Either the code stagnates as decisions take ages to get signed-off or after months or years neglect a system gets too messy to maintain easily. The inevitable slowdown pushes an organisation to consider a big rewrite (everyone wants to work on the new greenfield and choose shiny technologies) or a massive clean-up operation that may stall all new feature requests and require expensive education of developers about refactoring. Annoyingly developers often move on and so neither of these approaches last very long, we’re soon in the same mess again.
On a small scale, I think that it's possible to work with Conway's Law. I’m a great believer that XP practices such as Collective Code Ownership and Pair Programming improve communication and make it more likely for code changes to be made in the appropriate place. However, once you have multiple XP teams you need to pay attention to lines between them and find ways to share knowledge to keep architecture evolving coherently. One technique that we’ve tried where I work is to rotate team members between teams - very slowly (switching a team member with another team every few months).
For Agile and XP teams who work more collaboratively there are other implications that coaches might want to think about. Implications of Conway’s Law go much deeper than comparing org charts and power structures to system architecture. Communication paths which don’t necessarily map to the official org chart are also reflected in our codebases. Going even further than that I believe the quality and frequency of communication between individuals on the same team affects the design. Team size makes a big difference to that as does approach to hiring.
Here are a few more insights and observations from our discussion around the pool. I've tried to summarize as we went off on a few tangents!
- The XP practice of Metaphor is about synchronising the communication with the design.
- Geert Hofstade’s work on cultural differences might be impact the quality of communication and thus the system design. For instance, in Denmark there’s a short Power-Distance.
- Extrovert-Introvert differences within a team might transpire in use of code comments and naming. Extroverts often talk over others and rely more on communication than introverts.
- The quality of communications with customers may reflect how much an organisation values and cares about system construction/design.
- We have different tastes in design similar to liking different music styles. Rg, heavy metal, techno. Personality differences of individuals can impede communication and be reflected in software design approach taken. Some of these battles between individuals on teams cause a lot of unnecessary churn in the code. Brings up the question of whether teams should be formed of like minded individuals.
- Where we have different native languages this can impede communication and have an impact on the design. This can be an issue where we have some members of a team who speak same native language and others who are working in a second language. Often an organization is working in official language such as English with some team members from local country and others who are migrants but may have other colleagues from their home country with whom they can have richer communication.
- Lines of property/ownership can also bleed into system design when we have long term employees working with contractors who have a short-term interest. Power struggles erupt in the code.
As coaches, we need to understand something about the shape of the systems being built as that gives us insight into where communication may need to be improved. We might even be able to illustrate communication issues with code smell examples.
Going a step further, ask WHY is Conway’s Law the case? Because, our knowledge about the code universe and system/domain universe is what is reflected/mirrored in the system. Conway’s Law all comes down to system/code design depending to what information we have access to (known-knowns and know-unknowns excludes inaccessible unknown-unknowns and the future). As coaches we can create opportunities to share knowledge within and between teams.
As coaches we can help team build a greater sense of ownership so that members can give more consideration to shaping design. Exploring multiple options helps team members understand what stories are worth implementing and when it's time to kill/retire features that are not.
Another thing that can help build confidence to make changes is improving skills around refactoring. Coding Dojos can be safe places to practice gnarly refactorings and bringing legacy code under test.
Simple social events such as lunch together can have a big impact on improving communication between teams and may make it more likely for systems to be built more coherently.
I believe that there are organising principles that we can apply to build maintainable software systems. However, unlike software there are human constraints that we need to pay attention to such as:
- how many people we can maintain relationships with?
- how many email and in-person conversations we can keep up with?
- how much context switching can a person cope with before their creative problem solving skills are impacted?
This is not an exhaustive list! Please do post your thoughts as I'd be interested to hear from you.
Recent Comments