Wallace B. McClure

Lastly, if you break the nightly build, you not only get verbally accosted by EVERYONE, but you also lose all privileges...like slacking off by putting in 35-40 hours weeks while everyone else is working 50-60...and you become the project leader's "Slave For The Day"...AFTER fixing the build under the watchful eyes of said project leaders. (This rule is called the "You break the build, you FIX IT!" rule...) I've also imposed a mandatory "you break the build, you owe everyone a lunch!" to encourage cautiousness on check-ins. ("Hit 'em where it hurts: their wallets!")

The above might sound a little harsh, but I'm quite serious about it! (At some companies where software might be of "mission critical" nature, and maybe lives are at stake...not just the schedule...or millions of dollars of sales...) You HAVE to impose penalties, because it's simply too easy to let programmers check-in bad code and leave with the attituide "I'll fix it tomorrow!", which leads to schedule slips and poor quality code, since it screws up everyone else in the process.

In former companies, I've had to threaten some screw-offs with official reprimands in their personnel files after a "Third Strike". It seemed to be the only thing that perked up their pretty little ears...

Of course, there needs to be rewards to offset compliance to these kind of rules. (E.g., cash rewards for most bugs fixed in a week/month, movie tickets, sports event tickets, etc. for similar good development habits.)

Other good development rules include: your code must pass all existing unit-tests before checking in, your code must pass all existing unit-tests before a code review (Boy, I just HATE IT when during a code review, the programmer who's code is being reviewed can't demo his code due to a bug that could've been found by running all the unit-tests!), and you must develop and check-in a considerable amount of unit-tests along with any new functional code (i.e,. basic enforcement of TDD guidelines).

Forgot to mention: at past companies, I've actually written SCCS's (from scratch) or modified 3rd party SCCS's to restrict check-ins to ONLY code that would successfully compile. Boy, DOES THAT EVER WORK! (Reduces build-breakers dramatically...)

I've often prayed that someone would develop some free mods to VSS to enforce "verified-compile-check-in" dictum...but haven't run across any, nor have I had the time to look at VSS (i.e., the automation model) to see if it can be modified for such. I'm hoping that VSTS Tem Foundation SCCS has an automation model good enough to implement this easily... (I'm about half-way through installing it, and haven't looked at the docs yet...)

If you can check in all your changes every day before you go home either you are doing maintenance jobs or working on very small pieces of functionality.

Agree that what is checked in should compile... but should also be minimally functional.

Damien,

Yeah, I doing a lot of maintennance work on this one application, thus the rules.

Steve,

If I was in a bigger shop, I guess my rules would be more like yours. :-)

Wally

Yeah, some of my anal-retentive rules were from large companies, but now that I'm at a small company I've found that some of them still need to be used, esp. the "You break the build, you FIX IT!" rule. (That one seems to be universally useful at companies of any size...) The "must-compile-before-checkin" also seems to be useful at small companies.

The unit-testing rules don't usually come into play at small companies, 'cause a lot of them usually don't use TDD (lack the discipline that a larger company can induce) and are cutting corners on testing in general just to meet schedule milestones.

What you've listed is a pretty good set of rules for a small company or consulting group. But, Damien's note about "minimal functionality" is a good one when developing new code. It might be wise to modify one rule: code that contains functional features is exempt from the "check-in all code before going home" rule.

Good luck! (And keep TDD in mind...since it helps to prevent bugs, and helps to alleviate testing to a certain extent. At small companies that are too cheap to have good/large testing departments or don't have adequate testing time, then it becomes a very good "show-stopper"-preventer...)

As an extension of 'check in before going home' and 'compile before going home', at our small company with frequent releases of internal apps, we add 'you can't do a release within two days of going on holiday'.

My company has recently switched to a twice weekly build system to eliminate the outside staff's requests for immediate builds 24-7. The constant interruption was causing so much lost time we implemented this as a first step.

It takes a lot of patience and education to convey the idea that changes will not be available for review until a build has been posted however.