Putting together an continuous-integration-style automated build and deploy halfway through the project is exponentially more effort than starting off with one. At some point in the project, it may even be that the effort outweighs the gain.

The automated build run at least daily, more often is better, is ideally the release point of the project. Whatever the result of the process is considered the most recent version of the software, and the last good build is the current best version. At the beginning of the project, the result is extremely minimal, but it is working and can be considered the product. A later introduction of continuous integration misses this benefit. Instead of starting with a simple working build and nurturing and growing and evolving it with additional build tasks and deployment steps, the effort begins with a potentially massive and intricate set of components to thrash out. Early in the project, the codebase is small and there are not many pieces to build, and the changes are confined to a smaller range. Later, the changes are widespread and come fast and furious. At the beginning of the project, getting all the code to successfully build and run is easy, and the team can begin to get used to the idea that this is an ideal state.

Having a working, if incomplete, product seems to encourage efforts to keep it working. Developers soon discover that checking in small, specific, changes as often as possible, say on a per-task basis, is the best way to ensure the build doesn’t break. Team members not already familiar with small check-ins after every task and seeing the build as the heartbeat of the project will not gain from a mid-project introduction of continuous integration.

Later in a project that does not have an automated build of any kind, it’s not unlikely that the code in the repository is impossible to build without local tweaks. Each team member may be able to get it running on his or her workstation by ignoring broken bits or setting various options, so the fact of the entire system is broken may not occur to anyone. Whatever product that might have been handed off to testers of for demonstration purposes came together as the result of an individual or team effort on the workstation of whoever seemed to be most able to make it work.

This “but it builds on my machine” mentality hinders acceptance of the automated build as the “gold standard” against which progress is measured. The team’s rhythm has been set and become accustomed to another build process. In addition to getting team effort towards the build process, there is the task of weaning and migrating the team away from the habits already in place.

Without the will and desire from all members of the team the task is not only of questionable value it is also not going to get appreciation.