Daily builds.

Another link to Joel this time on daily builds another of my favorite techniques.  Many people rebel against the idea, especially project managers who like to see release schedules and milestones.  There is nothing in the daily build concept that contradicts good project management process however, its just that the progress towards milestones is tested daily, so that the chance of suprises are reduced and the dependency on key individuals is reduced.  Here is a snipit but please read the whole article if you develop and IT system, and take note that the concept can be applied to all types of development not just software.  I used the daily build concept on one of my projects and I think it was a great success.

Here are some of the many benefits of daily builds:

1. When a bug is fixed, testers get the new version quickly and can retest to see if the bug was really fixed.
2. Developers can feel more secure that a change they made isn’t going to break any of the 1024 versions of the system that get produced, without actually having an OS/2 box on their desk to test on.
3. Developers who check in their changes right before the scheduled daily build know that they aren’t going to hose everybody else by checking in something which “breaks the build” — that is, something that causes nobody to be able to compile. This is the equivalent of the Blue Screen of Death for an entire programming team, and happens a lot when a programmer forgets to add a new file they created to the repository. The build runs fine on their machines, but when anyone else checks out, they get linker errors and are stopped cold from doing any work.
4. Outside groups like marketing, beta customer sites, and so forth who need to use the immature product can pick a build that is known to be fairly stable and keep using it for a while.
5. By maintaining an archive of all daily builds, when you discover a really strange, new bug and you have no idea what’s causing it, you can use binary search on the historical archive to pinpoint when the bug first appeared in the code. Combined with good source control, you can probably track down which check-in caused the problem.
6. When a tester reports a problem that the programmer thinks is fixed, the tester can say which build they saw the problem in. Then the programmer looks at when he checked in the fix and figure out whether it’s really fixed.