One to Rule Them All

Software engineers often display a strong preference for compartmentalisation, a place for everything and everything in its place.

With this in mind it might seem like heresy to suggest that all source code for an estate of products should be stored in a single code repository.

Naysayers will scoff at the notion but many organisations that maintain extremely large code bases, namely Google, Facebook and Microsoft, have moved to the concept of a monolithic repository with every line of code in a single place.

Have these development teams taken leave of their senses or could it be that the benefits of having one repository to rule them all are too good to ignore?

A Wonderful View

Having the ability to view a entire code base all at once can enable us to identify patterns across many different areas of code that may otherwise be difficult to spot.

Tools that produce such metrics as duplication, technical debt or even security issues gain a whole new power to deliver insight when they are scanning every line of code you have at once.

Having the whole code base in view will also empower developers to find more ways to share code, by performing even relatively simple searches through the IDE developers will be able to uncover where similar problems have already been solved to the one they are facing.

This increased capacity for collaboration coupled with a more inclusive attitude to code ownership can reduce the need to re-invent the wheel and ensure re-use becomes a default approach.

Atomic Refactoring

Its frequently the case that we are prevented from doing the right thing because of the potential pain in trying to manage the change across multiple code bases.

Once all the code is in a single place not only is it easier to envision the changes that need to happen but it can be implemented in a single atomic operation.

Even a simple yet wide reaching change such as re-naming a class or changing a namespace can be achieved across the entire estate in a single operation.

This can also prevent refactoring getting off to a false start where the true impact of a change isn't fully realised before implementation begins.

The freedom this gives a development team to contemplate refactoring that they would never normally be brave enough to attempt can liberate them to do the right thing on a much more regular basis.

Simplified Dependency

A potential headache in maintaining any code base relates to the management of dependencies.

This can be tough enough when dealing with dependencies on 3rd parties but when we create a large set of interconnected internal code bases we only increase the size of this potential nightmare.

By essentially building all our internal dependencies from source we reduce dependency hell to its smallest possible size.

The benefits of atomic refactoring and a complete view of the code base also make the job of updating a dependency easier and more palatable then may normally be the case.

Many reading this might be thinking isn't this desire for a monolith going against many of our ways of thinking for creating independent pieces of code such as SOA or micro-services.

This is where I feel we need to draw a distinction between how we organise our source code and how we deploy it output.

A single repository doesn't have to mean a vast single solution or project.

It is possible to realise all the benefits described in this post whilst still on a day to day basis working on a small and specialised area of the code base.

The fact that it is possible to load the entire code base doesn't mean that has to be the normal course of operation, but the fact we can if we choose to see our entire world at once gives us the ability to more effectively shape it.

It would be wrong to suggest that moving to a single repository is pain free, it does place extra stress on tooling and all the companies mentioned that have adopted the approach have had to adapt their ways of working, but the potential benefits it can bring are difficult to ignore.