« I, Robot: Disappoint... | Main | Linksys WRT54G +... »
20040729 Thursday July 29, 2004

Must Check in Code a Lot More Often

The project that I work on right now has a highly distributed team. We have developers in a couple of locations in the US, we interface with developers throughout the US, Canada, France and the UK. And we have our contingent of engineers based in India at our India Engineering Center.

I am currently running a small campaign within the developers to check in code to CVS a lot more often than they had in the past. I am getting good success with the developers that are based in the US. Articles such as Keep Changes Small: A Happy Jack Story have been helpful.

I just cannot get the IEC engineers to checkin their code often. When they do check in the code, it is after they are done with 5 different CRs, 30 seconds and a half before the code freeze time for a build. More often than not, the check in isn't done properly, and there are some stressfull moments going over diff outputs trying to figure out what the final result should look like.

I have tried to argue with them. I have tried to give them the benefits of doing so. I have threaten, I have ordered. I have huffed and puffed. With no results. The only thing I haven't tried yet is to fly to India with whiffle bats.

I need a bit of help then... Please let me know if you have ideas or advice on how I can convince these engineers to check-in often.

Thanks!

-- Fred ( Jul 29 2004, 10:13:20 AM MDT ) Permalink Comments [6]
Comments:

xp, as in extreme programming, professes many good disciplines among them "integrate early and integrate often." folks, like me, either equate xp to "practical advice" whereas others like to debate it to the end of time. i think the name puts people off as it could very well be called "practical principals" as it is neither extreme or programming. then again, one wouldn't sell so many books with such a practical title :)

Posted by gonzo on July 29, 2004 at 10:32 AM MDT #

Hmmm... Is it a philosophy, or a best current practice.

One of the things I really hate about most environments is the desire to build "tip". This is wrong and the heart of most of the problems with VCS. Developers need to have the ability to check in all kinds of code, working, work in progress, completely broken, prototype, whatever.

From there use a labelling system that allows other developers to pick up the correct level of change - developing, stable, build (individual build labels as well)

My personal philosophy is that version control is my backup system - I want version control to backup what I am working on, what I am thinking about, whatever. Don't worry about deleting things, moving things, whatever - it is still somewhere in VCS. One of my pet peeves is #if 0 - why not just remove it and pull it back out of VCS if you really need it (same goes for #ifdef DEVELOPERNAME stuff too)

Does this help - probably not, like most things philisophical you have to get screwed by the system first (my change came when I had a hard drive with 2 weeks of work fail on me before I got it out to VCS - took better than a week to get my work back. Never again)

Posted by Bill Strahm on July 29, 2004 at 11:59 AM MDT #

The desire to have a "buildable" repository is the very thing that I am fighting with some developers, even on the US side. I have stopped counting how many times I asked developers whether they had checked in their code only to get a "I want to get through my [unit|regression|functionality] testing before checking in". The problem in this particular case is that anyone who is dependent on this code is slowed down.

Some one at work stopped by my office and suggested that oversized boxing gloves might also be a less painful alternative to the whiffle bat ;)

-- Fred

Posted by Frederic Jean on July 29, 2004 at 12:14 PM MDT #

What's in it for the developers? I can see what the benefit to you (as someone who wants to resolve the inter-project dependencies are) and I can see what the benefit to other developers is (i.e. they can test their code against the dependent piece), but the original developer knows that, as soon as the code is committed, the phone/email will start to ring/beep with people going "Hey! Your code doesn't work!" - not much incentive to release early.

One of the better answers to this problem is to separate the development tree from the release engineering tree with the understanding that the development tree may be broken or in flux at any time.

Automated builds and tests should be against the release engineering tree; API tests can be against the development tree.

Unfortunately, the choice of CVS makes this sort of environment really, really difficult to setup, automate and maintain. Teamware and/or BitKeeper do this in a much better way.

As for the commit at the last minute problem, just mandate an RTI date that is well ahead of the code freeze date, then enforce the RTI date freeze. Once a developer has had to find a senior manager to mandate an opening of the RTI freeze because they couldn't get their act together a couple of times, management will start to apply the needed pressure because that developer is becomming a real pain. (The motivation for the developer is one of saving face if not their job.) Conversely, if they do get their act together, you have the time gap between the RTI freeze and the code freeze to resolve all the nasty integration and paperwork issues that arise.

-david-

Posted by David Haynes on July 29, 2004 at 02:06 PM MDT #

consider cruise control: http://cruisecontrol.sourceforge.net/ better yet, wrap it all under maven: http://maven.jakarta.org there derivatives/copies/peers to the above. invaluable assets.

Posted by gonzo on July 29, 2004 at 02:43 PM MDT #

Proper use of CVS branching gives you both (a) the freedom of allowing (and actually encouraging) frequent commits of experimental/in-the-works/not-fully-debugged code, and (b) the ability to keep the main "trunk" buildable and stable. Yes, developers will not commit often if they think there is a chance that they will break something.

Posted by Peter Schow on July 29, 2004 at 06:14 PM MDT #

Post a Comment:

Comments are closed for this entry.