How about an hourly build?

The benefits of a daily build are well understood by now. McConnell even cites the book Showstopper! as an extreme example circa 1993:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/10/how-about-an-hourly-build.html

It does not matter if the code is in compilable state. If it is not a logical unit of change, it should not be checked in. Your source code repository is not just storage, it is a history of all changes.
If you start pushing people to check in by the end of the day, you will get a lot of meaningless changes.
Besides, if you don’t use VSS, you don’t even know if someone “keeps files checked out overnight”, because there is no explicit check out in the first place.

“If you start pushing people to check in by the end of the day, you will get a lot of meaningless changes.”

The intent is not to get a lot of checkins, but for developers to logically checkpoint their work throughout the day. Eg, develop through a process of accretion, and ensure continuous integration-- so that the team knows what the heck you are doing-- rather than waiting a week and getting a giant hairball of code dumped into source control at the end of every week. The larger the checkin, the less likely it is that other developers will have time to assimilate it, and the less time you will have to explain to other developers what you’re building. Bottom line: people don’t understand what you mean until they see it for themselves. When you check in your stubbed functions, developers will look at your API and say, “ah, so THIS is what you meant” and possibly offer suggestions as well. Without checkin there is no dialog.

I am not arguing that developers should check in broken or incomplete code but rather that they should be building code in SMALL, LOGICAL PARTS. If they cannot possibly see how they can build their code this way, again, I think maybe they have some bad habits that need breaking.

There might be some other way to get developers to do this other than encouraging aggressive checkin, but they would be just as much work if not more (pair programming, maybe?)

There might be some other way to get developers to do this other than encouraging aggressive checkin, but they would be just as much work if not more (pair programming, maybe?)

It looks like you actually want something like this, and not the aggressive checkin policy.
I don’t know what kind of projects you’ve worked on, but the ones I am involved with do not work that way. The design changes hourly (on a micro level, not as a big picture), and personally I do a lot of refactoring as soon as possible.
I have been in a situation where one or more members of a team are working on a “big” change for days. Note that these were already agreed upon by all members of the team, so others do not really need to see my small incremental changes and stub functions.

Generally, we agree on the principle that whenever there is something that could be checked in it should be immediately checked in. Nightly builds are a must, daily and intra-daily if possible.

I simply don’t think that aggressive checkin policy will change anything in the already developed habits of people. Good developers will still do good code, regardless of frequency of checkins while bad ones will, well, do bad again regardless of the checkin policy.

I’m a few years late to the discussion…

I would say the commit frequency should be inversely proportional to the number of developers, including you, depending on the region of code you’re working on multiplied by factor n; where n is the average length of time between commits for your project.

For my current job, n would probably be 2 or 3. This would produce a commit once every day or two.

I’ve always viewed the checkout/checkin model used by Visual SourceSafe as a part of the problem here rather than a part of the solution. Developers have every motivation to check code out (they can’t make any changes to code that they haven’t checked out, and if someone else checks it out first they are prohibited from checking it out) and little motivation to check it back in quickly (if at all).

I vastly prefer the Copy-Edit-Merge model used by Subversion (or more anciently, CVS), in that it switches the motivating factors: you can make changes to any file you want, but if you don’t check it in quickly enough someone else might commit changes that conflict with yours and then YOU have to merge (WAH-Wah-wah). With newer versions of Subversion advisory locking is available if you want to warn other devs off where conflicting changes might be especially hard to merge, but they can break or steal the lock at their own discretion (in the default repository policy).