Continuous integration seems like a smart choice, right? Why would anyone think that integrating your code into the product as soon as possible is a bad idea?

Let me take you back to August 2000, when a fresh-faced young engineer was starting her first engineering role. She was given a desk, a computer, and a detailed project plan that included a release date three months in the future. As she was writing the code, the QA engineers were busy writing up test plans in preparation for a release candidate to be ready.

After four months of hard work, the engineer and her team sent their code to the CD-ROM factory that would print CD-ROMs to send to customers. Many customers were eagerly waiting for this new version of the software. It had been eight months since the last update, and the bug they reported six months ago was starting to irk them.

The story above is a (mostly) true account of my introduction to software engineering. At the time, the cost of updating the software was huge. It involved long testing cycles and a lot of hard work to make the documentation accurate — screenshots could quickly become out of date but the documentation couldn’t be updated after the software had already been released.

Making a change to a product was hard and the cost of making a mistake was high.

The CI/CD differentiator

Today, things are very different, largely thanks to continuous integration and continuous delivery (CI/CD).

It’s hard to overstate the powerful impact of being able to make changes in the product as soon as they are ready. The feedback loop between engineers and customers is much shorter, and as engineers, we can respond to customer feedback in a way that puts the customer first.

Lowering the cost of delivering changes to the customer means that we can quickly roll back any errors we’ve introduced. It also means having a lot more confidence in delivering changes that might have seemed risky before. Introducing changes one at a time also helps avoid those hard-to-detect errors that come from pushing two features together at the last minute.

The fact that you can achieve a higher quality product by continuously making changes might seem counterintuitive but in reality, it’s the only way to improve.

So, what do you say to a manager who is skeptical of CI/CD? Here are some potential answers to questions that your manager may ask:

What is continuous integration?

Careful not to scare your manager here by saying something along the lines of “putting code into production as fast as humanly possible!”

This could be read as putting unfinished or broken features in front of customers, which is not the case at all. A good answer could be something along the lines of, “continuous integration is breaking our work up into small pieces, sharing our work with our peers, and QA-ing frequently.”

What does CI/CD cost?

The cost to move to CI/CD depends on how much you’re willing to invest in great automated testing. Because of that, the cost varies depending on how far along you are in your testing journey. If you’re doing most or all of your testing manually, the cost may be higher than if you have a rich suite of automated tests including end-to-end tests.

It’s easy to make a case for investment in automated testing. Running automated tests on a CI tool costs far less and is more reliable than paying an engineer to do the same thing. Be aware though that you’re asking your manager to offset this value against feature delivery, which can be a hard decision. Expect that your manager will want to add automated testing incrementally and potentially add a manual QA step before deployment — a step many teams have taken in order to achieve CI/CD.

Life Pro Tip: if your manager asks you about the price of CI/CD and you answer with how many quarters it will cost the team, they will take you much more seriously.

What are the benefits of investing in CI/CD?

While I’m sure that every manager is invested in the happiness of their engineers — I know I am — very few managers can afford to dedicate a significant amount of time exclusively to making their engineers happy. Yes, CI/CD is a great investment because it makes your developer’s job more enjoyable, but engineer happiness is simply a side-effect of a great business decision.

There are also many benefits of CI/CD that go beyond engineer happiness and truly justify the investment.

  1. It is much easier for more than one team member to work on the same feature.
  2. The cost of merging small changes is much lower than large changes.
  3. Team members can evaluate their peer’s changes in a system that has passed automated testing rather than the moving target of a feature branch.
  4. It is much easier for QA engineers to validate small changes iteratively in a consistent system, so detecting the source of errors becomes much simpler.
  5. Features can get into the hands of customers in an earlier state. This means that if we’re on the wrong track, we can change direction after only a small investment.

Align with leadership values to get a ‘yes’ on CI/CD

As engineers, we know that CI/CD makes sense. It means that code quality is higher and features are delivered faster. It introduces a confidence in our production code that doesn’t exist when features are integrated and delivered long after they’re written.

To some managers, this can feel unintuitive. In order to get your manager on board with CI/CD, you’ll need to use the language and ideas that align with their values. I hope this article can provide a good starting point.