Most of the projects we start from scratch; we usually start with a build time of less than 2 minutes with all the unit tests, code analysis metrics and reports. If you have heard about the parable of the boiling frog, then something similar happens over the course of few months when the code has gradually grown in a large size and increasing the build time with it. My observation in one of the teams few years ago was that we got used to build taking longer and which was considered more of a break from an hour or two of coding. What we did not realize was that subconsciously we were aware that the build is taking longer and hence we accumulated a large piece of code before checking instead of smaller chunks. This had an observable problem that there were build breaks just before we were heading home and developers sometimes take good amount of time merging code before checking in.

It was not until we reached a tipping point that the entire team realized that the build time has risen to a point where it hampers a smooth churn of development. To our surprise it was only few hours effort to get the build to under 4 minutes from 12-14 minutes. From there on some of us keep a conscious watch on the build times and have a 5 minute unwritten blanket rule to jump on fixing it before it grows too large. Usually the problem was a monolithic code base which keeps the build time too high. Some frameworks like GWT will compile JavaScript for all browsers which might not be required to be done for every build. Making use of the multiple cores now available so widely is also an option to consider. Ramdisk is also another option.

The lesser the build time, the more it encourages us to check in code often which reduces merge conflicts; eventually leading to a mature continuous integration. A mature continuous integration ensure reliable and effective delivery.