Coder to Developer: Tools and Strategies for Delivering Your Software

Although most developers I know have started with VSS for source code control, by and large they don’t remain with it. VSS may have been a state-of-the-art system a decade ago when it was first designed, but it hasn’t been seriously revised in the intervening years. Some versions got a well-deserved reputation for corrupting files, which is simply a disaster in the application you’re depending on to keep your code safe. Current versions seem to have fixed that problem, but they still depend on an obsolete file-locking scheme, lack the flexibility of some other products, and have an overall bad reputation.

The main advantage to VSS is that it’s “free”—more precisely, if you own Visual Studio .NET or another Microsoft development tool, you probably own a bundled copy of VSS. If you’re just getting started with source code control, particularly if you’re on a limited budget, you might want to use that copy. But I recommend you look around at the source code control landscape to see what else is out there. In this section, I’ll suggest some factors you can use to evaluate which product to use in your own development.

TECHNOLOGY TRAP: Penny-wise, Pound Foolish? Or, a Fool and His Money Are Soon Parted?

Deciding how much to spend on software tools is a tough question, especially if you’re an independent developer or a small business. Good tools protect you from disasters or make it easy to write good code fast. However, they also come with a price tag, and that price tag can be significant.

For any given tool, the decision may be easy. That $500 expense for a source code control system seems like cheap insurance. The $100 add-in to handle unit testing will save you much more than that in time that would otherwise be spent fixing bugs. But add up enough of these easy decisions, and suddenly you’ve spent $10,000 on tools with no income to show for it.

The key, especially when you’re starting out, is not to make these decisions on a tool-by-tool basis. Instead, come up with a tools budget and stick to it. After you figure out what you can spend, start making lists of all the tools that you want to buy. Go wild at this stage; put on everything that you’d like to have on your desk to help you write better code.

Now figure out what it will all cost. If it’s more than your budget (and it will be, if you’re even half trying), prioritize the list and start looking for alternatives. Do you need unit testing or automatic documentation more? Can you get by with fewer features in your performance-testing tools? Eventually, you’ll either get the list down to something you can afford, or you’ll have an ordered list of tools that you’re not willing to compromise further.

Buy what you can from the top of the list and go to work. If you want more tools, keep the list handy to review after your next big sale. That’s a good time to plow some money back into getting a solid toolset in place for future productivity. Repeat until you’ve bought everything you want.

Price

Prices for these products vary widely. At one end, you have the free open-source products (CVS is the best-known of these). At the other, some of the commercial applications will cost you hundreds of dollars per user, and may have a minimum number of users that you can buy licenses for at one time.

Although cost is certainly a factor, especially for a small shop, I urge you not to let it be the only factor. Source code control is something like insurance in this regard—not buying it will save you money, but in the long run you’re risking much larger costs. Think about what it would cost you to re-create your entire code base if there were a hard drive crash and you didn’t have the code saved safely elsewhere.

Concurrent Development Style

I cheated a bit when I described the basic source code control commands. There are actually two distinct ways to handle concurrent development, and I described only one of them. So here’s the bigger picture.

VSS uses the check-out/edit/check-in style. In this style, a typical editing session works like this:

1. Developer A decides to work on Module 1, so he checks it out of the repository.

2. While he’s editing the module, no one else can check it out.

3. When he’s done with changes, Developer A checks in the module. At this point, Developer B can check it out and repeat the cycle.

By contrast, CVS and some other systems implement the edit/merge/commit style. Here’s how a session might go under this style:

1. Developer A decides to work on Module 1, so he just starts editing it.

2. Meanwhile, Developer B also decides to work on Module 1. CVS doesn’t lock anything, so she just starts editing.

3. Developer A finishes his changes, so he commits them to the repository and goes on to something else.

4. Developer B finishes her changes and attempts to commit them. But the system notices that someone else changed the module in the repository after the last time that Developer B got a copy.

5. Rather than throw away her work, Developer B merges her changes into the copy in the repository. Now she can commit the merged copy, and everyone is happy.

Whether one style or the other of handling concurrent development is superior is one of those hotly fought battles in software development that never seems to come to a resolution. Proponents of check-out/edit/check-in worry about the chaos of having two developers make conflicting changes in the same source code file. Proponents of edit/merge/commit complain about the inefficiency of waiting for files to be checked in so that they can make unrelated changes.

In practice, I haven’t found either one of these issues to be a real problem, at least on small teams. It’s rare to have two developers decide to work on the same part of the same file at the same time. But it’s also rare to have a developer who has absolutely nothing to do but wait for someone else to unlock a file.

If you (or your team) are used to one style or the other, make sure that your product of choice supports that style. Otherwise, you might like to experiment a bit to see which style makes more sense to you.

The Repository

Every source code control system stores the code somewhere. Repository-related issues that you should consider when choosing a system include the following:

• How open is the repository? Can you get the data out easily if you ever switch systems?

• How stable is the repository? Does it use disk files, database records, or some other means to store the code you place in it?

• How secure is the repository? Does it protect source code from people who should not have access?

• How easy to manage is the repository? Does the source code control system offer good administrative tools?

You should also consider the network overhead that the repository adds. Does it require you to set up a separate server? Do you need to buy separate database-client licenses? Choosing the wrong product might involve substantial hidden costs.

Internet Friendliness

If your development team is distributed, you also need to find out how well your source code control system will work over the Internet. Some products, such as VSS, have network performance that is frankly unacceptable. If it takes 5 minutes to check out a file, developers simply won’t bother, and your source code control system will fail at its tasks of tracking and protecting code.

Other products were designed for the Internet from the start, using Transmission Control Protocol/Internet Protocol (TCP/IP) as their communications protocol and passing information in small chunks. Even if you’re not using the Internet to distribute work now, you might want this flexibility in the future.

IDE Integration

Modern integrated development environments (IDEs), such as Visual Studio .NET, support source code control operations directly from within the IDE. Figure 3.4 shows the Solution Explorer window in Visual Studio .NET 2003.

Figure 3.4: Source code control in the Visual Studio .NET IDE

As you can see, Visual Studio .NET lets you get the latest version of a file, check out a file (and later check it in), or compare two versions of a file without leaving the IDE. In this case, I’m using VSS as a source code control system, but the same capabilities are available with many other products. That’s because Microsoft has published the API that it uses for source code control, and this has become a de facto standard across many products and IDEs.

Although IDE integration can be convenient, I’ve stopped using it in my own projects. Only a small subset of source code control commands are available in the IDE, so you need to switch to a dedicated source code control client application from time to time anyhow. Given this requirement, I find it more convenient to do all of my source code control work in one place. You might feel otherwise, of course.

Advanced Commands

As I mentioned earlier, different systems support different advanced commands. If you absolutely must have Cloak, or Pin, or Move, this will narrow down the list of products that you’ll find acceptable.

Cross-Platform Support

A final consideration is whether your development is completely tied to Windows, or whether you might need to do cross-platform development at some time in the future. Some source code control systems, such as VSS, are tightly tied to Windows. Others, like CVS, are available for a wide variety of operating systems. If you need to share files across operating systems, life will be easier if you settle on a cross-platform-capable system in the first place.