If you’re part of a large team developing a large project, there’s a good chance that one day, at least two of your team members discovered they were working on t he same piece of code at the same time. This situation leads to confusion, at best, or disaster, at worst.
“At some point in the project it’s doomed to get insane,” says a programmer for an analysis-software startup firm in Cambridge, Mass. about team development.
“When you have half a dozen coders who are all desperate to get the project finished on time, working 100-hour weeks and therefore not at their peak, it’s bound to happen that one is going to step on another’s toes.”
Another programmer, who supervises database products for a large retailer on Michigan Avenue, likens the week before software ships to the scene in “The Andromeda Strain” in which, “that woman had the answer right in front of her, staring her in the face, but she was too tired from working so many consecutive hours to see it.”
Those of you who learned how to program on VMS systems may remember (like a particularly bad nightmare) the voluminous files created by multiple edits of the same piece. Perhaps myreport.txt;147 was an improvement over myreport.txt;146. The question was: how could you tell them apart?
Of course, you couldn’t. The reports had to be printed out and checked for their differences to be discerned. This problem is more prevalent for programmers than report writers, so a series of version-control tools have emerged in recent years for all platforms, from DOS to supercomputers. The idea behind these networked tools is to help members of a team automatically trace changes-think of it as a high-end version of word-processing redlining-and keep different parts of the code in different states: read-only, editable, editable only by certain people, and so on.
We spoke to a dozen of Silicon Prairie’s usual suspects regarding which version-control tools they use and the most common answer was, well, none of them. Even the programmers we queried from large companies like Sun Microsystems and John Hancock said that they had explored several of these tools but found them, as one put it, “inflexible. We’re not going to build our programming practices around a piece of freeware. Sure, we have a version-control system. It works very well. It’s called a white board.”
Others use more basic software programs, like Microsoft Project, to track the overall progress of a project, but not to handle version control. Said a programmer for 3Com, “When you come down to it, it’s all about annotation. If you need an automated tool, there’s something wrong with your programmers. New software isn’t going to solve that.”
Do you use version-control software? We want to know.
