Development/Source Code/Build rules

  • Use Source Control.  I use VSS because it comes in the box with Visual Studio .NET.  Yeah, I know about all the problems, but I primarily just use it on the local machine to track changes.
  • Check in all changes before going home.  I must check in all changes to the source control system.  I can't go home unless I do that.  If someone goes home and all changes are not checked back in, they have to come back and resolve the problem.
  • Compile.  Everything must compile at the end of the day.  It doesn't necessarily have to work, but at the end of the day, when I do the three-finger salute of Ctrl-Shift-B to perform a build, if it doesn't build, I can't go home.

What are your rules?

Wally

6 Comments

  • 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

  • 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.

Comments have been disabled for this content.