It’s continuous integration. As simple as that! But I’m talking about real continuous integration, not the crazy obsession with tooling that has been sweeping the industry. This is a really misunderstood topic, and it’s going to cost the industry an absolute fortune in wasted time and money – I’ve already seen whole projects, and even whole companies be destroyed when they’ve gone all-in on the wrong things here.

When a developer makes a change to a codebase, they need to integrate it with the previously written code with confidence that nothing has broken. When you have more than one developer, and they are working on things at the same time, they need to integrate their changes together. The more developers you have, the more often this happens. The faster they are able to make a change, the more often this happens. If the steps needed to do this take a long time, or are difficult or error prone, you’re going to very quickly hit a limit. You need to make integrating changes so effortless that it could be done continuously with close to zero cost – this is what continuous integration (CI) is about.

There’s a vast industry growing around providing “CI tools” – and “DevOps”, and some widespread myths coming with it. CI and DevOps are both great ideas – when done right – the problem is that this is rare, and there’s lots of money to be made by perpetuating the myths at stakeholders’ expense. If you have deeply understood the underlying principles, got the culture and processes right, and met the other pre-requisites – which you can only do by putting in thought and effort, not by throwing cash at it – then CI tools are great. If you go all-in on the technologies and tools but don’t get the basics right, you’re going to have problems.

The number one mistake I see that stops teams being able to integrate is that the solution evolves in a way that they can’t confidently combine changes together. There are 2 key elements to this:

1) The design/architecture/implementation are such that you can’t be confident that a change in one area doesn’t affect another
2) The testing strategy doesn’t provide a fast and trusted means of proving that a change in one area didn’t affect another

To repeat, both these things need thought and effort. A build script won’t fix this, a CI tool won’t fix this, and hiring a “DevOps guy” won’t fix this. The whole team need to take a step back and solve this by thinking and acting on it. It will help vastly if you have input from someone who’s seen these things done right, who can bring that experience to the group.

However the good news is that if you get these two things right, it unlocks the ability to really grow. If you have a scalable way to add contributions to the codebase, you add contributions more rapidly, or have more contributions being added concurrently – i.e. you can go faster, and/or add more people without just deadlocking. If you try to add people to the team, but haven’t got this right, your expenses will go up, but everyone’s productivity will go down. I can’t stress enough, the absolute worst thing to do in this situation it to try to power through it by adding yet more people, because it will just compound the root problem, while putting your budget under pressure – this can and does kill businesses!

If you’re struggling to deliver, and think this could be a cause, you need to get the team thinking about a solution from the right angle. This is where coaching or an outside perspective can save you a lot of time and money and make the difference, because if this has become a problem already, the chances are that the experience needed to solve the problem isn’t already available within the team. If you can change the way people approach this, it can be possible to make significant improvements fairly quickly – but you need to escape the tooling trap, and put the focus the things that matter.