Want Better Software? Focus On Communication.

In 1968, a computer scientist named Mel Conway authored a paper titled “How Do Committees Invent?“. At the end of his paper, Conway presented this thesis:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure."" - Mel Conway

Have you ever had moments in your life where you remember exactly where you were when you learned something? Conway’s Law is like that for me. For years, I struggled to find myself in the crazy world of software after spending the first part of my career in strategic communications.

In 2015, I had the opportunity to attend the “big” Agile conference (wearing my 10-month old baby, but that’s another story). One of the sessions was Michael Feathers, who I think of as the godfather of Legacy Code, presenting about how software teams can use Conway’s Law.

”One of the most apparent effects we’ve seen of Conway’s Law is the appearance of microservices…we can have team structure align with code structure.” - Michael Feathers

My mind lit up — I had a place. I belonged. I understood communication structure and I had never before considered how big of an impact communication had on the code my team was producing.

Let’s break down the thesis so it’s even clearer.

Your company is an organization and the system it is designing is your codebase. The structure of your codebase will be a copy of the communication architecture you use in your company.

So if you want to eliminate your technical debt, communication HAS to be a critical component of your efforts. If you’re struggling to break up your monolith and move to a microservices model, the first place to look is how your team is communicating. Command and control silos will result in monoliths. Self-organizing and autonomous teams give rise to microservices.

We see this in our work constantly, which is why we’ve adopted a series of communication protocols that we try to execute when we manage projects. Here are some examples of communication principles Corgibytes implements to ensure we execute good communication regularly.

Point to Many, not Point to Point

In our contracts, we require the use of a point-to-many communication system (we use Slack) to discuss projects. We actively coach teams on how to stop managing their projects from email. The clients who insist on continuing to use email have a great deal of difficulty making any traction or change as compared to the ones who embrace group communication.

One of the best examples I’ve seen of the value of point to many communication is from the U.S. space program. In his book, Team of Teams, General Stanley McChrystal describes how the success of the Apollo program largely depended on the ability of NASA to “link its teams together by disregarding the ‘need to know’ paradigm and widely broadcasting information.”

Real-time dashboards, control rooms and radio “loops” replaced the rigid protocols that existed previously. Again from Team of Teams:

“NASA engineering talent was temporarily redirected from building rockets to designing an enormous set of radio “loops” that allowed teams to communicate with one another fluidly. “I think we had 250 channels [on which people could talk] in Complex 39,” one official at the Kennedy Space Center recalled. “You could tune into North American 2, and you’d be listening to the guys working the engine. If there was a problem there, you could hear how they were handling the problem.” At launch time, every team was put on the same loop. “You got instantaneous communication up and down,” the official marveled. “[ It was] probably one of the biggest loops ever put together … instantaneous communication, instantaneous transmission of knowledge.”

Slack enables that real-time communication, putting executives, business teams, developers and product owners in the same “comm loop.” Individuals can adjust notifications and opt in and out of teams as they desire. This model mimics the loops that NASA implemented, allowing information to move at a rapid pace.

Unfortunately, these communication protocols were scrapped for a more “efficient” command and control system in the 1980’s. The United States space program lagged behind in innovation and started to observe bloated budgets and more mistakes as a result.

Synchronous and Asynchronous Balance

In a few weeks, we’ll be heading up to Boston for the third annual Mob Programming Conference. We’ve been a gold sponsor since the beginning because we recognize the value mob programming brings, especially when you’re trying to solve complex problems.

Mob Programming’s creator, Woody Zuill, describes mobbing as a “software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.” At Corgibytes, we have structured mobs for each client on a weekly basis and encourage teams to spin up mobs whenever they feel it’s appropriate.

When we work asynchronously, there are several practices we follow to ensure quality communication. First, we practice leaving quality communication artifacts throughout the codebase by the way we name things, comment on pull requests, commit to source control, and more. We use Empathy Driven Development to actively think about who else will be interacting with what we produce and proactively structure our content in a way that considers what other people need. We also are careful about context switching, asking our team mates about their “inception level” instead of seeing if they’ve “got a sec.”

Align Strategic & Tactical

One of the biggest challenges we’ve observed across teams is how to separate signal and noise for business and technical teams. After a lot of experimentation, the protocol that we’ve implemented at Corgibytes revolves around capturing the details of a project every day and then synthesizing for more executive teams. Our regular communication protocol consists of:

• Daily Stand-Ups (posted asynchronously in Slack)
• Daily Journals (posted in a GitHub Wiki)
• Weekly Retrospectives (both internally and with each client)
• Weekly Activity Reports
• Test-Driven-Development (we encourage the business teams to write executable acceptance tests using an automated framework such as Gherkin)
• Regular Prioritization conversations (the cadence varies by client)
• Regular Progress Reports (a narrative of how the project has gone over a length of time)
• Regular Executive Check-Ins (to align budget & ensure activities are matching up with strategic initiatives)

By sharing this information with the group, we ensure that information is bubbling up and down so as to not create a divide between the folks working on tactical things and those in charge of more strategic direction.

What are your thoughts? Have you observed how communication has made an impact on the quality of your codebase? What have you implemented that worked well? What did you try that didn’t work out as planned? Let’s keep the conversation going in the comments!