Musings on Conway's Law and SOLID Design Principles

In 1967 Melvin Conway submitted a paper called "How Do Committees Invent?" to the Harvard Business Review. HBR rejected it on the grounds that he had not proved his thesis:

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."

He got the paper published a year later in Datamotion magazine and it you’d like to read the original it’s available on his website here -- Fred Brooks subsequently coined the name "Conway's Law" when he wrote about this idea classic book "The Mythical Man-Month".

In his article, Melvin asks "Is there any predictable relationship between the graph structure of a design organization and the graph structure of the system it designs? The answer is: Yes, the relationship is so simple that in some cases it is an identity." and he concludes "a design effort should be organized according to the need for communication." The basic point he makes is that the shape of software reflects the communication patterns of the people making it.

When I've heard conference speakers, such as Michael Feathers and Kevlin Henney, invite the audience to consider Conway's Law, their focus is usually spotting problem areas resulting in the code layer rather than the people layer. The division of an organisation into teams and departments can create barriers and interfaces in the software. The effects are usually even worse when multiple organisations are involved and those organisations are in different countries around the world with time-delays introducing inevitable delays into communications. Many traditional software development organisations use “teams” that are a bunch of people reporting to the same line manager but each person taking responsibility for adding specific functionality. These software developers usually have different coding styles and rationale for design decisions. The resulting code can be like a patchwork quilt and hard to maintain due to inconsistent coding conventions.

Agile approaches to software development can be seen as a way of "refactoring" communication between people and improve the software they create. When we adopt XP practices of Collective Code Ownership and Pair Programming, we improve knowledge sharing and code consistency. On an XP team, any developer can work on any part of the code, code is created and reviewed in pairs, this helps the team to produce code that can be understood by any team member. XP seems to be a set of organisational design patterns that works for a small team. Sharing knowledge between teams working on the same code is a challenge so maybe we need to exchange people between these teams in the same way as an XP team does pairing swaps.

As an agile coach, I work more with individuals and teams than on the code. I spent many years as a software developer and enjoy “debugging” people and communication problems. In working with people to simplify and untangle process, I find myself applying concepts learned in software design, such as decoupling interactions and clarifying responsibilities. Information and work flows through a software, information and work also flows through a software development organisation. Are there any design principles that we regularly apply in software that could benefit how we design our organisations?

I thought it might be fun to revisit the SOLID design principles to see if any apply to the people domain. SOLID is a set of Object-Oriented design principles crafted by Robert Martin and the Object Mentor team in the early 00's to help teach OO design to C++ programmers who might be struggling to make the shift. Michael Feathers gets the credit for coming up with the acronym!

The SOLID principles are:

• Single Responsibility Principle (SRP)
• Open/Closed Principle (OCP)
• Liskov Substitution Principle (LSP)
• Interface Segregation Principle (ISP)
• Dependency Inversion Principle (DIP)

Let's look at each of these in turn to see whether they might apply in anyway in the people sphere, at the both the level of individuals and teams.

Single Responsibility Principle, an object should have only one reason to change. A class has a single responsibility; it does it all, does it well, and does it only. The purpose of this principle is to make it easy to understand the class and have a single place to make changes to this behaviour.

If we try to extend SRP to the people layer, this implies each person does a specialised job which is pretty much at odds with Agile software development concepts such as collective code ownership. We know that if we have a single specialist then they can become a knowledge bottleneck and we're in trouble if they get sick or go on holiday. This brings to the surface some constraints that we have to work with in the people layer - we have a limited number of people and they are not always available. In software we're used to a world with virtually no limit on the number of entities we can create with separate responsibilities.

However, we can go down the route of applying SRP for flow of information into the team by establishing a Product Owner to be the gatekeeper for new story requests and set priorities for the team. There is also sense in which SRP might apply at a team level, making one team responsible for all changes to a specific product. This is a core idea in Scrum, one team per product. We understand which team needs to make the changes and they have all the knowledge to make those changes.

On larger software systems, we end up with multiple teams and because of the various technologies involved component teams often proliferate. This may work where there's an even stream of work to keep all these component teams busy. But large agile projects often find that feature teams work better than component teams. So again in the P-layer we're concerned about levelling the workload and avoiding knowledge bottlenecks.

Open/Closed Principle, a class should be open for extension and closed for modification. Again this is all about isolating changes. We can’t really extend or modify people so I’m not sure that there’s a way to apply this in the people domain. At the team level we can add, remove or consolidate teams and having some consistent process across teams makes this easier.

Liskov Substitution Principle, instances of an interface should be wholly substitutable regardless of implementation. Implementations of an interface should behave the same way from the point of view of the caller. They should not require callers to have any knowledge of implementation variances to do the same work. Perhaps this applies to the the communication interface to teams. For instance, those processes used when we send the team new support requests and introduce new requirements. If there is a team that handles support requests, we use the same process irrespective of the individual who is picking up the requests, this is in some sense applying LSP. The team can rotate who is on support duty but the interface is the same.

Interface Segregation Principle, several interfaces with specific purposes are better than one larger interface. It’s better to have many small interfaces than fewer big ones as this allows them to change independently. I think that ISP does apply for software teams, we need to identify the parts of the organisation that interact with the team and agree a pattern for these interactions. I’d say that this applies to cadence of meetings, such as demos, and having a clear agenda for specific regular meetings with different groups. This can be a big improvement on general management meetings that aim to cover several different things and involve one or two of participants in turn during one long meeting.

Dependency Inversion Principle, collaborators should depend upon abstract interfaces, not concrete implementations. Objects should be minimally coupled and know little to nothing about how their collaborators are implemented. I’m running out of steam here but perhaps DIP can be seen to apply to how Scrum handles the separation of the stakeholders and the development team. The team decide how they do the work and owns the Sprint Backlog, commitments with stakeholders are made on the Product Backlog only.

I’ve written this article for XPDay magazine as a recent topic I’ve been pondering and hope to discuss this topic at the Open Space there. I’m also posting this article on my blog because I’m interested to hear your comments. I've written this in rather a hurry and I'm sure that there are other ways that SOLID principles might be seen to apply to software development organisations.

Comments

[Jwgrenning]

Nice article Rachel

Let me add to the discussion re OCP/LSP. I think an anti-pattern in organizations is treating people as plug replaceable programming units. OCP/LSP for organizations means shifting people around as if they are plug-replaceable or adding more 'resources' to late projects to extend the teams ability ability and capacity.

[Dave Nicolette]

Solid thinking, as usual (no pun intended).

I might quibble about the word "refactoring" in this context. If the goal is to change communication structures so as to improve the organization, then we are after behavioral changes, not only implementation changes. With that in mind, I wonder if "transformation" would be more to the point.

Regarding the apparent conflict between "agile" methods and the individual specialization implied by SRP, it seems to me that the "agile" approach treats the team, rather than the individual, as the unit of labor. (The other sections in your article also focus on the team; only the bit about SRP focuses on individuals.) In that case, a standing team whose purpose is to support a given set of technical assets satisfies both the SRP and "agile" preference for multi-skilled, cross-functional team members who freely cross traditional role boundaries. So, I think SRP can be applied to the people domain in an "agile" context with no conflict.

[Björn]

Classes should be open for extension but closed for modification, not the other way around.

Interesting take on teams here, thanks. Björn ACCU

[Rachel Davies]

Thanks, James. I agree with your comment about treating people as replaceable programmable units. The idea of applying design principles to people and organisations seems to ignore the fact that each person is unique in their experience and that their personal motivations and choices need to be factored into any decisions. However, I think attempting to streamline communication and work flows can reduce people being overwhelmed by too much work and make meetings more relevant to the work at hand.

Rachel

[Rachel Davies]

Thanks, Dave. You're right, this is more than refactoring, it's change with the intent of improving. For the copy of this article in XPDay magazine, I've changed it to say "improving" as I tend to associate the word "transformation" with magic applied from the outside. Coaching is change applied from the inside by working directly with individuals concerned, directed by their choices.

Regarding SRP you could think of individual developers as being instances of Developer - agile approaches set up pools of autonomous individuals with clear interfaces about how they engage with the rest of the organisation.

[Rachel Davies]

Thanks for the correction, Björn! I've made that correction now.

[Allan Kelly]

Interesting idea, I think about Conway's Law a lot in my work, and Reverse Conway's Law when the org becomes a copy of the system. The homomorphic force works in both direction.

SOLID for teams is an interesting idea but I'm not sure it takes us anywhere. I'd rather think about what we want from teams and then decide what the mnemonic would be.

Continue this at XP Day

[Arjen Uittenbogaard]

Hi Rachel,
Nice topic! Coming from an OO background, I've been applying the OO principles quite a bit on organisational level. I wasn't aware of the SOLID acronym, but it's a nice summary of good OO principles. My two cents:
* I'm sure more can be said on each letter, but I'd like to go beyond your comment on the Open/Closed Principle. You say people cannot be extended. However, as a trainer/coach I tend to disagree - isn't learning new skills and behaviour some sort of extension? I also like to point to improvisational skills, which help 'extending' ones behaviour! The 'Closed' part of the principle, I would translate as: but stay yourself.

* Secondly, I'd like to point to remarkable (or maybe not so?) similaraties between the three principles Dave Snowden stresses for resilient organisations: distributed cognition, disintermediation and finely grained objects. A concise summary of what OO is all about, if you'd ask me :-)

[Ruud Rietveld]

Nice article! I think the SRP applies to teams in the way that they should be wholly devoted to their project/product, and not be distracted in their work, which is also what Scrum advocates.

[Juanjo Fuchs]

Great article! It's an interesting point of view, taking into account that the team is a unit and meetings are interfaces through which the team communicates with others.

As I understand this post:
* SRP: As Dave pointed out, one team, one product.
* OCP: I agree with Arjen, extend people's abilities by learning, but do not change/replace them, avoid affecting the synergy of the team.
* LSP: The way the team accepts user stories and returns deliverables should remain the same, independently of the nature of the request (i.e. feature, user manual, etc.)
* ISP: One meeting, one purpose.
* DIP: Don't quite understand the correlation yet.

It's my point of view, hope it helps. I'm exited to see how this evolves!

[Craig]

I recall a conversation a few years ago where enterprise architects were talking about designing the whole org around OO principles. Never saw anything come to fruition though.

I am with Dave. If you find time I'd be keen to see you do this over with your sights set directly on the team as the unit of construction. I'd also be interested in seeing your thoughts at the whole org level and not worry so much about scrum teams as a specific exampls.

[Gupster]

"Open/Closed Principle .... We can’t really extend or modify people"

Can we not? Surely we can cross train people and we can help people get on better together and deliver a better work product through coaching and behavioural feedback.

[Curtis Cooley]

How about this:

The spirit of DIP stems from how those new to OO tend to create systems with a lot of concrete objects all dependent on each other. DIP says to invert those dependencies and depend on abstractions instead.

Traditional development has team members depend on architects for design and management for organization. Agile says the best designs, architectures, and requirements come from self organizing teams, so we need to invert the dependencies and allow team members to depend on each other.

[Lloyd Holt]

We can certainly apply Conway's law to the current state if afairs in Washington, DC.

No communication No workable systems being designed