This is actually pretty serious and occurs surprisingly easily and often. Especially IDE-users seem to fall for it, which is probably because the development environments are too smart and try to guess which files need recompiling and which don't.

You see, it is very annoying when you check out the latest version of the code, and then start to code on your changes, only to find out that you can't compile other parts of the software, namely those that someone else modified. Then you'll need to use your time to fix Someone Else's bugs, because if you don't, you can't do your own work.

A typical way of making this mistake is when you compile only parts of the code, but forget that your API changes might require changes in some other part of the code. Since you didn't compile that particular part, you never know it breaks. Until someone calls you with a murderous gleam in their eyes.

There is only one really effective way against this: Recompile everything. Run a make/ant clean, use your IDE, or delete the whole build directory, then recompile everything. If it compiles, then you can check it in. It's okay if it doesn't work (you can fix that later), as long as it does compile.

The other way is, of course unit testing. But that does require recompiling everything, too.

(I've heard that in some companies those who break the build get to wear a special "I broke the build" - t-shirt until someone else breaks the build. During the first few days, the hat travels around pretty rapidly. After a while, you are stuck with it for days.)

Don't break the build. Recompile everything before you commit.

(Oh yeah, this of course works only when your project is small enough for recompilation. Large projects like Mozilla can easily take an hour to compile. Any ideas on how to handle this?)

Basically, it comes down to managing your dependencies. Totally unrelated modules shouldn't break if you make some changes - if so, then you have bigger problems with your code structure/architecture. -- KenLiu

ContinuousIntegration certainly helps.

This practice is now commonly called ContinuousIntegration. On the linked page, I have added links to two open source tools that can be used to manage automated builds:

-- PaulDownes, 11/21/02

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-12) was last changed on 15-Sep-2008 21:58 by