PC#5 - The Inevitable Law Governing Software Design

Not many laws exist in the world of software development.

That’s because building software is a highly contextual activity where it’s not easy to generalize stuff.

However, there is one law that has stood the test of time (in terms of scope and impact)

It’s called Conway’s Law.

Here’s what it states (in the exact words of its author Melvin Conway):

What does Conway’s Law look like in practice?

Let’s say your organization has 3 departments - inventory, invoicing, and shipping.

According to Conway’s Law, the software design that’s likely to emerge for handling the work of this organization will consist of 3 software systems:

• Inventory Management

• Invoice Management

• Shipping Management

Moreover, the quality of integration between these systems will depend on how well these departments communicate with each other.

This is because coupling between software systems is a product of human communication.

Here’s what Conway’s Law looks like in action:

We see it all the time in our own teams and organizations.

If we can easily talk to the author of a module, it’s simpler for us to build a rich understanding of that module. This makes it easier for our code to interact with that module and share the problem domain.

At this point, you might wonder whether Conway’s Law is good or bad.

And how can you get around it?

There are 3 ways organizations and teams react to Conway’s Law:

• Deny that it exists

• Accept and not go against it

• Use it to your advantage

In truth, the first step to dealing with Conway’s Law is to NOT go against it. Your goal should be to work with it and if possible, use it in your favor.

Here are a few things you must keep in mind:

1 - Location matters more than you think

Even placing teams working on the same system on separate floors of the building drastically reduces communication. Just imagine the impact on teams spread across cities and time zones.

If that’s your situation, the components developed in different time zones must have a well-defined and limited interaction.

You can’t rely on the creators of these components to communicate easily with each other to iron out differences.

2 - Avoid Technology-Based Departments

It may sound tempting to divide your teams based on the software layers (such as frontend team, backend team, or DevOps team).

However, this only increases the friction because each business feature will need a close collaboration between the layers.

The same is the case for dividing people based on the phases of the software life-cycle such as analysis team, design team, coding team, and so on.

Consider the number of hand-offs required to get a feature to production.

3 - Leverage the Conway’s Law

Since organizational structure impacts the design of the software system, you can build a structure to support the desired software design.

For example, if you want to build a monolithic system that can be taken to market quickly, keep your team in one place with informal communication channels for seamless collaboration.

On the other hand, if you are looking to build microservices, it’s better to arrange your developers into small, self-sufficient teams focusing on a particular business capability.

4 - Team Structure is Not Just a Management Matter

Conway’s Law proves that organizational structure impacts the eventual software design.

In other words, the person determining how teams must be arranged and who should report to whom is actually taking decisions about the future architecture of the system.

Not all managers are equipped to make those decisions.

The role of an Architect becomes even more important in creating a team structure that can make the desired architecture a possibility.

How to Improve as a Developer?

I haven’t met a developer who doesn’t want to improve in their craft.

Of course, some don’t want to admit it because it makes them feel inadequate.

But it’s not that hard to continue growing in your developer career.

Here are a few simple steps that have worked extremely well for me:

• Keep stacking skills (tech as well as non-tech). Learn new programming languages, frameworks, or tools. But don’t ignore soft skills such as communication and teamwork. And yes, they are also skills that you need to work on.

• Build your domain knowledge. It might be difficult to become a 10x coder. But it’s not so hard to be a 10x partner to the business if you just listen to their problems and try to solve them.

• Start networking outside of your team. If anything, this will expose you to new ideas and learning opportunities.

• And lastly, on a lighter note, don’t deploy on Fridays 🙂. Keep your weekends free so that you can spend time learning new stuff.

In short, the below tweet summarizes the main points:

The Power of Lowly Tasks

When you are new to a team (whether a fresher or an experienced developer joining a different team), you might get to work on so-called lowly tasks in the beginning.

Don’t treat that as a setback.

Think of such tasks as training wheels meant for learning the ropes and getting the hang of things.

While doing them, you learn the processes of your team and the team learns more about you.

You’ve got a better chance of growing within the team if you perform such tasks with high energy.

Remember - The way out is through. Not around it.

That’s it for today!

Have a great weekend and see you next week.

In case you want me to cover any specific topics in future editions, please fill out this form to suggest ideas.