Conway’s Law Applied to Quality: The Quality Law

Conway’s Law is an insight into the design and architecture of systems developed by organizations. Specifically, it states that the design or architecture of a system is effectively dictated by the organizational structure (or communications structure) of the organization.

Fundamentally, Conway’s Law is a statement about the impact an organization has on what it builds, just based upon a certain attribute. For software developers, it’s an if…then statement:

if <some structure>, then <some related design>

It’s a great insight into helping organizations understand why they build software the way they do. There’s another insight, to be introduced in this article, that can provide further insight into the expected results from software development within a given organization. Here’s the insight:

The quality of the software product produced by an organization is directly related to the principles (or values) followed by that organization.

If you’ve read The Core Process and Principles, Parameters, and Practices, you’re aware that software is developed following a core process, which is as follows:

Requirements ➟ Build ➟ Publish

All practices added to the above process are added to improve the quality of the software. However, the insight above goes a step further and states that even if you don’t follow a formal process to develop or identify your organization’s core principles or values (and, hence, the ultimate practices you follow), you will still act according to the inherent principles that “culture drivers” within the organization already have.

Culture Drivers

A culture driver is an individual that has sufficient influence to either define policy or to guide behavior within an organization. For example, a Vice President of Engineering is a culture driver by defining policies that all software developers much follow. Typically, upper management (especially at the VP or higher level) act as culture drivers, as they control the budget (this may impact training, office parties, travel, etc.), most policies, and expectations for delivery.

For example, if a VP comes down hard on teams that don’t deliver on their commitment, this drives a particular culture. Engineers will adjust their behavior to deal with this, such as padding estimates or cutting corners. If the VP encourages engineers to spend work time learning, that also impacts culture, such as engineers being more aware of new technology.

It’s also possible to have a minor culture driver on a particular team. For example, a senior engineer who knows a lot about a project, but who holds that information close and treats others poorly, causes engineers to behave in a certain way when working on the project, such as not approaching the engineer, causing the project to slow down

Culture, in this context, represents the experience, work context and expected behaviors of staff created by culture drivers (whether through policy or not).

Inherent Principles

Engineers, just like most people, work in a way to minimize pain and maximize enjoyment. If a VP expects a lot of night and weekend work, for example, engineers are likely to comply (at least for a time). Initially, the pain of being yelled at by the VP is worse than working longer hours. However, done long enough, many engineers will determine that the pain of finding a new job is worth stopping the overwork pain.

Though some policies are defined by law, many are defined by Human Resources or upper management as a way to drive delivery. These policies (written or not) represent the principles or values of those defining them. Hence, even if an organization hasn’t explicitly defined a specific principle or value, they become inherent within the system. These principles or values drive behavior, which drives the overall quality of the software development experience.

This mapping looks the same as Conway’s Law in that it’s a simple if…then statement:

if <principle>, then <related quality impact>

The nuance to call out here, though, is that the quality defined here doesn’t necessarily define only the ultimate quality of the product. It may impact the quality of the development experience. That is, it may be possible to produce a product with few defects (one measure of quality) with a poor experience by the engineers who produced it.

Let’s look at a simple example: going on vacation. Let’s say that company A and company B have similar vacation policies defining the amount of vacation employees can take.

Company A’s front-line managers are stingy about allowing vacation and control it closely, while company B is more liberal, allowing employees to take vacation when they want. As you can imagine, employees from each of these companies will have a different experience when attempting to take vacation. For example, imagine an employee at company A attempting to take vacation with extended family with a limited time window where the manager rejects the request. The employee will most likely be bitter about the rejection, which may impact their engagement and level of commitment to the company. This can easily impact the overall quality of the employee’s development experience and potentially the quality of the product.

It’s easy for companies and organizations to ignore these kinds of scenarios, expecting employees to act professionally at all times, devoting all their energy to the company. However, this misunderstands how people work and doesn’t acknowledge the impact of policies and culture on the ultimate output and quality of a company’s products.

Taking Ownership

Organizations who are able to be self-aware enough to introspect and analyze their own motivations and values are able to identify and document their principles that can better drive their policies and processes to get the quality that they desire.

For most organizations, self-introspection is difficult, and self-honesty is beyond their capability. In these cases, their policies and processes will grow from reality, rather than any stated purpose or documented values. This disconnect between stated values and real values create a hypocritical environment that translates into dissatisfaction within the engineers that can cause disengagement over time.

Given this, organizations have an opportunity to take ownership of their policies and processes and work to define their principles and work to live them.

Just like acknowledging Conway’s Law and the impact to the design and architecture of software systems, understanding principles and values (or, hopefully, defining and living them) will help drive the quality of the software development experience, as well as the ultimate quality of the products produced.