Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Grow with Conway’s Law, Not against It

Grow with Conway’s Law, Not against It

This item in japanese

Jason Goth, Micah Blalock, and Patricia Anderson of Credera explained at SpringOne how they used Conway's law to tailor a client's technical architecture and processes to reverse falling productivity and accelerate the production of high-quality code.

Conway’s Law states that “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”. This means what your team creates is dependent on how your organization communicates internally.

In creating a custom analytics platform for their healthcare client, Credera learned that the architecture and processes that worked for one or two parallel teams of software developers quickly ground to a halt as part of scaling up five parallel development teams. Credera’s solution was to tailor the technical architecture and processes to its implementation of Conway’s law to redefine the problem. In the end, because of their efforts, Goth, Blalock and Anderson were able to reverse a downward productivity slide and build quality code at an accelerated rate. Credera shared their experiences at SpringOne in August 2016.

Credera’s found initial success building code on two parallel Scrum teams. This led to additional work assigned by their client. This new work required adding several more parallel development teams and address simultaneous deadlines. Unfortunately, their development efforts stagnated as the result of this growth. Simple code changes cascaded through multiple downstream services. Meetings took over work time as coordination between teams grew exponentially. The different teams’ workloads varied dramatically as some team members left early and others worked late into evenings. Morale declined and deadlines passed unanswered.

Technically, the Credera team retooled its software design to fit its own communication structure. It applied the open/closed principle to the code to optimize partitionability. This reduced the cost of having multiple teams working on similar code but caused teams to write duplicate code, a practice they called GARY (Go Ahead, Repeat Yourself). To decouple much of the code, they created horizontal surface area that avoided many pitfalls associated with the resulting duplicate code caused them to “refactor ruthlessly” several times.

Organizationally, Goth, Blalock, and Anderson made changes to stop working against Credera’s Conway’s law. Code standards were deprioritized other than to provide the framework for developers to quickly migrate from one code set to another. One member took on the role of team lead across all teams for a scrum and facilitated inter-team communications. Another senior member, Blalock, became the “sacrificial lamb” who dealt with customer meetings and interactions with legacy code. While not common, team members migrated between teams during sprints. The result was meeting frequency came down. Their teams’ workloads normalized and morale improved. And finally, deadlines became less onerous.

The team referred to Fred Brooks’s book The Mythical Man Month as inspiration. From that text, they determined that coordination costs plus partitionability of the work equals the efficiency of change. Only when the work can be partitioned can you achieve efficiency by adding team members.

The team employed the Spring platform with microservices as part of this project. They wrote their code in Angular and Java.


Rate this Article