We Are What We Code

In 1967 Melvin Conway introduced an idea that would eventually become known as Conway's Law.

"organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations"

At the heart of this statement is the realisation that producing software is a collaborative exercise between many areas of an organisation, and as such the effectiveness of that collaboration will be evident in the software that is produced.

To fix your software you need to fix your organisation.

Trash Talk

In order to not produce monolithic software any reasonably complex system is usually broken down into any number of sub-systems.

Once this happens then the nature and structure of how these systems interface with each other must be defined.

In large systems produced by large organisations it will often be the case that different teams will be reasonable for different sub-systems and as such engineers across those different teams must collaborate to define these sub-system interactions.

Ineffective communication between these teams will lead to badly defined or misunderstood requirements that will become evident once these systems go live in the amount of failure recorded or in the amount of inefficiency in achieving outcomes.

To avoid this limit the barriers placed between engineers, let the techies talk to each other whenever the need arises in whatever informal manner they find most effective.

Idle conversations between individuals will very often prevent untold pain in production and also acknowledge the fluidity of implementation meaning not everything can be figured out in advance in a formal setting.

Hierarchy of Needs

All large organisations have a necessary hierarchy to avoid chaos, functions that need to be performed and work that needs to be accomplished is divided among different teams and individuals.

However very often this structure can be manipulated to best suit the needs or wants of individuals, this in turn shapes internal communication and can lead to software being produced that is structured in such a way as to suit the needs of the implementors and not necessarily the users.

Teams should be structured so that they are aligned to the needs and wants of users, in this way what is best for the users will more naturally align with what makes things easiest for those working on the product.

If certain teams are frequent collaborators but have barriers around their interaction because of the way an organisation is structured they will find ways to work more independently, this may not be in the best interests of the user who wants the sub-systems each team is responsible for to interact seamlessly.

Process over Problem Solving

Processes within a large organisation are necessary for many reasons, to enforce consistency, to ensure goals and outcomes are meet and simply to allow for smooth operation.

But a critical mass can be reached where teams and workloads exist solely to service process for its own sake.

The end goal of any process in relation to the purpose of the organisation, and the users it serves, should always be clear and concise.

We don't deploy software for its own sake, we do it because software is a tool to solve problems, all structures and processes within an organisation should be aligned to that goal.

When this isn't the case a stagnation can exist that prevents software delivery, and hence problem solving.

If your organisation isn't structured around slick software delivery it won't deliver software and it won't solve problems.

Its often easy to be critical when software is deemed to not be fit for purpose, its also very easy to see this as purely a technical issue, why aren't our engineers producing better software?

In fact the question to ask is why isn't our organisation producing better software?

Engineers are only one cog in the machine that brought that software to market, much communication will have taken place to lead to that point and ineffective software can nearly always be seen to have its roots in ineffective communication.