Johanna Rothman, questions “How Much Building is Too Much?” in a recent article in StickyMinds. In it, she clearly seems to take the position that, for most projects, the more often you build your software, the better. I very much agree and I’d also like to address a few points a reader makes on this topic.

How often you build may be based on the needs and culture of your project. I wouldn’t always suggest that a project immediately move from never building their software to Continuous Integration (CI) - building at every change to the SCM. A more incremental approach to CI may work for effectively in gaining acceptance in the group. One of the readers indicated that:

One of the biggest issues we had with frequent builds is that it encouraged poor development practices and poorer requirements definition.

I highlight this because I’ve heard this before as an excuse for not performing frequent builds. I’d suggest that ineffective programming practices, not building frequently, had everything to do with these problems. In this case with frequent builds, they were simply finding out sooner that there were problems with the software. This is actually a good thing; By using this feedback effectively, you can spend time on integrating quality practices into the group, such as writing automated tests, performing reviews or pairing, and/or running software inspection tools to highlight deficiencies.

Rothman also makes a good point that the testers serve a specific function and it is not feasible to have a tester test every build in an environment that performs frequent builds. There may be discussion amongst the development team on which builds the testers will focus their efforts.

Finally, remember that you should script every part of your build process so that you can execute it early and often. If you don’t have a repeatable way to build or test your software, there isn’t much else matters.