How tuned is your time machine?

How tuned is your time machine?  No, I am not talking about DeLoreans with Flux Capacitors, but a tool almost all software development groups have but many use poorly, namely source control.  A simple test of how well your source control system is doing is to see how many times a day the average developer checks in code.  The sad fact is that in most development shops I encounter, the time a file is checked out is measured in weeks—as for a library book.Driver development can benefit greatly from a source control system that encourages its use.  It is amazing how many times I hear “It was working, I must have changed something to break it.”  If you use source control all the time, it is easy to back up to prove things worked, find the version with the set of changes that broke things, and quickly resolve the problem.   For a manager, frequent source control is beneficial to scheduling since it gives you concrete data on the state of the work.  Statements from developers, “I’m 80% of the way done” do not mean anything.  Is this 80% coded, tested or what?  Instead, “The current checked in version supports these capabilities and passes these tests” gives you a solid basis for scheduling and for knowing a project’s status.Source control gets out of tune for two major reasons, either the system is cumbersome to use, or developers ignore it.  Many source control systems become cumbersome because release engineering owns them and requires additional input and checks since every check in is part of the release!  Unfortunately, this approach is wrong because developers need to be able to check in often, and that includes versions with diagnostics that will never go into production.If you are a manager stuck with cumbersome source control, consider setting up your own with something like SourceSafe.  Having two source control systems may mean that you as the manager need to take a stable version out of the lightweight system and check into the release system periodically, but having the history of changes I am talking about is worth it.There also needs to be an environment that encourages checking in often.  The common developer model of “I’ve checked it out, I’ll check it in when all the modifications to the module work”, has to be changed.  Encouraging developers to check in after every change can be a challenge.  Showing the value of frequent revisions for debugging will help.  For a manager, looking at what goes into a revision and encouraging incremental revisions is also needed.  Finally, consider using a source control system where only one developer can have the file checked out at a time.   This not only creates an internal push to finish the change and check it in, but also eliminates the error-prone merge steps in systems that allow multiple checkouts.Encouraging incremental revisions of the code, and using source control wisely is one of the best ways to improve quality and find bugs in drivers.  When you are checking your code in often, it is easy to step into your time machine and track down the bugs.

 

Posted: Apr 27 2007, 12:03 PM by DonBurn | with 1 comment(s)
Filed under:

Comments

Steve Dispensa said:

Hear! hear! I wish people took source control more seriously. It has saved me often.

SourceSafe is too painful for words, though; I have had good luck with:

- CVS, for many years, although it's old and showing its age

- Subversion, which is a better CVS, mostly

- Perforce, which I use at work, and which is fantastic.

The first two are open-source, and Perforce is free for 2 users, so if you're a small dev shop, it might work for you. It gets expensive after that, though - $800/user or so.

Commit early and often. Branch for releases. Tag for patches. Your life will be happier.

# May 31, 2007 5:13 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)