14   Integrate Early, Integrate Often

the very end of the development phase, or at least until development is well underway. After all, why bother integrating code unless it’s done? You’ll have plenty of time

As we’ve said, a main aspect of agility is continuous development, not episodic. That’s especially necessary when it comes to integrating code you’ve written with code the rest of the team has been working on.

Most developers would like to postpone integration for several good reasons. Sometimes the mere thought of working with more code or another subsystem may be too much to bear right now. It’s easy to think, “I’m already under pressure to get things done, and the last thing I need is more work and trouble with other people’s code.” We’ve also heard excuses such as “I do not have time for that” or “It’s quite an effort to set that up on my machine, and I don’t want to do that now.”

But integration is one of the major risk areas in product development. As you let a subsystem grow, unintegrated, you’re exposing yourself to greater and greater risk—the rest of the world is marching on without you, and the potential for divergence will just keep increasing. Instead, it’s easier to address risks as early as you can, while the risk and the relative pain level remains fairly low. The longer you wait, the more painful it will be.

In Venkat’s early years in Chennai, India, he used to catch a train to school. Like any big-city, rush-hour commuter in India, he invariably had to jump in and out of trains that were already in motion. Now, you can’t just leap into a moving train from a standing position; there’s a very painful lesson on the laws of physics to be learned there. Instead, you first start running alongside the train and then get hold of it while gaining momentum. Finally you make the leap onto the train.

Software integration is like that. If you continue developing your code in isolation and one day suddenly jump to integrate, don’t be surprised at the beating you’ll get. You’ve probably seen this happen on your projects, where the time toward the end of the development phase becomes very frustrating. People spend days and nights integrating. The only positive aspect is the free pizza you enjoy while being stuck at the office.

There’s a tension between the need to isolate and the need to integrate early. When you develop in isolation, you’ll find development quicker and more productive, and you can nail down problems more effectively (see ​Attack Problems in Isolation​). But that doesn’t mean you should avoid or delay integration (see the sidebar here). You should generally integrate your code at least several times a day and probably never go longer than two to three days at most.

By integrating early, you get to see how subsystems interact and interoperate, and you get to evaluate how information is shared and communicated. The earlier you understand and address these issues, the less work you’ll have to do fixing them. That’s true for 3 developers on a 50,000-line code base, and for 5,000 developers on a 30-million-line code base. If instead you postpone integration, then these issues may turn into difficult tasks that require significant—and far-reaching—code changes, causing delays and general chaos.

Integrate early, integrate often. Code integration is a major source of risk. To mitigate that risk, start integration early and continue to do it regularly.

What It Feels Like

When you’re doing it right, integration stops feeling like a separate, onerous task. It’s just part of the regular code-writing cycle. The problems that arise are small and easily addressed.

Keeping Your Balance

• Successful integration means that all the unit tests continue to pass. As per the Hippocratic oath, “First, do no harm.”

• Normally you want to integrate your code with the rest of the team multiple times per day, say at least five to ten times on an average day and maybe much more. But there is a point of diminishing returns if you integrate every single line of code every time you make a change. If you find yourself spending all your time going through the motions of integrating code instead of writing code, you’re doing it too often.

• If you don’t integrate often enough (say you integrate only once a day, once a week, or worse), you may find you’re spending all your time working out problems caused by integrating code instead of writing code. If your integration problems are large, you’re not integrating often enough.

• For prototypes and experimental code, you may want to work in isolation and not waste effort on integration. But don’t stay isolated too long; once you learn from the experience, work toward integration quickly.