Filling Your Toolbox

Software developers are certainly awash in tools. But what makes a tool worth using from the standpoint of improving the development process?

• By Mike Gunderloy
• 06/01/2001

Broadly, we can divide software tools into two types. First, there are those tools that you must have to do your job of application development. Second, there are those tools that you can do without, but that will make you more productive.

Into the first group fall such tools as the compiler you're using. You don't really get a choice about this. If you're writing code in Microsoft Visual C++, you're going to use the Microsoft Visual C++ compiler. While many diatribes have been written about compilers, linkers, and so on, I don't propose to re-fight the language wars here. I'll just assume that you have the tools you absolutely need to turn your ideas into working code, and leave it at that.

The second category is more interesting. There are undeniably tools that will make your work easier or more productive. Some of these you can snag for free; others cost substantial amounts. Amazingly, I find many developers who don't use any of these tools, not even the free ones. There seem to be folks who feel that Microsoft would have put it in the box if you were supposed to use it. Not so, in my experience.

If you don't have any tools that make your work easier, I suspect you're too focused on the task at hand to actually investigate tools. In this age of enormous deadline pressure and tight budgets, that's understandable -- but it's also a big mistake. In the software business, if you are not actively learning new things, you are actively falling behind. You might be the best Visual C++ programmer ever, but you'll wake up two years from now and find that you can't get a job on any new, exciting project, because your skills have stagnated. Every developer needs to have some of what I call "sandbox time". Build into your schedule the time to read a book, play with a new programming language, or cruise the Internet looking for tools. Tell your boss I said it was OK. If you want, you can begin by following my own partial list of essential tools.

Controlling Code
Let's start with something that is in the box (at least, if you're using one of the Visual Studio products) but which many people don't bother to install: source code control. Every developer makes mistakes. Sometimes this is not a big problem: You correct the line of code and go on with your life. Other times, though, mistakes can be disasters: What if you completely deleted a complex class from your project, and then discovered that the new architecture you had in mind doesn't work? It's times like this that you need to be able to revert to an earlier version of your code. For any but the most trivial coding projects, you need to install and faithfully use a source code control system, even if you're not sharing code with anyone. Visual SourceSafe, part of the Visual Studio suite, works perfectly well. Two other products worth looking at, especially if you do any cross-platform work, are CVS (www.cvshome.org) and Perforce (www.perforce.com).

Editing Code
Code editors are another class of tools that are surprisingly underutilized. While the editors built into products such as Visual C++ and Visual Basic are adequate, a good programmable editor with macro capability can save you hours in the course of a week's worth of coding. The major editors will also integrate directly with your development environment, so that you can use them as part of the development process. There are dozens, perhaps hundreds, of good editors out there; it's worth looking around at trial versions to see which one fits best with your working habits. Major contenders in the Windows market include CodeWright (www.starbase.com/products/
Developer/#codewright), Visual SlickEdit (www.slickedit.com), and UltraEdit-32 (www.ultraedit.com/).

If you're on the cutting edge, you're probably working with XML files these days. If so, you probably should add a good XML editor to your toolbox as well. This is another area where there's plenty of competition. For light duties, Microsoft's XML Notepad (http://msdn.microsoft.com/xml/NOTEPAD/intro.asp) may be sufficient, though it seems they stopped development on this tool before it ever got out of beta. Many developers I know swear by the full-featured XML Spy (www.xmlspy.com), though you might find it overwhelming. XML Cooktop (www.xmleverywhere.com/cooktop) provides a freeware alternative with its own impressive feature list. You'll find lots more editors, as well as other XML tools, listed at the XMLSoftware site (www.xmlsoftware.com/editors).

Debugging Code
Tools can also help you when you're debugging software. For starters, many problems become easier to figure out if you know more about what's going on when you run your code. If you're facing an intractable problem, take a look at the suite of free utilities including FileMon, PortMon, and RegMon (for monitoring all file, port, and registry access in real time) available from the folks at SysInternals (www.sysinternals.com), And while you're trying to track down bugs, it helps to just keep track of them. Bug-tracking software is another area where there are lots of solutions to choose from. You can use anything from a home-rolled database to a multi-thousand dollar Internet-enabled team tracking product, but whatever you choose, bug-tracking software is the best way to make sure that problems don't fall through the cracks in your process. I'm fond of Visual Intercept (www.elsitech.com), which integrates well with Visual Studio. FogBugz (www.fogcreek.com/
FogBUGZ/index.html) is a relatively new web-based system that features integration with CVS. Applied Testing and Technology lists plenty more on their links page (www.aptest.com/index2.html?resources2.html).

Grab Bag
Finally, let me mention general-purpose tools that don't really fit into any category. Two that come to mind (because I use them daily) are Vault (www.personalmicrocosms.com) and WinZip (www.winzip.com). Unless you live in a cave, you already know WinZip, the does-everything compression and decompression program. Vault is a freeform data organizer that will take whatever you throw at it and keep it in a hierarchical outline structure; I use it for everything from storing passwords to making notes on which project I need to tackle next.

Choose Wisely
I could keep going (have you looked at the tools that actually ship as part of Visual Studio?), but let's back off for a minute and think about what makes a good tool. Here's my own list of tool-choosing criteria:

1. Tools do one thing, and do it well. Once you start stuffing every possible function into a program, you don't have a tool, you have an application. Word and Excel, for example, with their persistent featuritis problems, don't strike me as tools. On the other hand, something like FTP Voyager (www.ftpvoyager.com/), which concentrates on making FTP simpler and easier, is definitely a tool. I find that if I can't sum up what a tool does in a sentence or even a phrase, I'll never bother to pull it out of the toolbox.
2. Tools have a shallow learning curve. That doesn't mean that they have no power; the typical programmer's editor can practically make your computer get up and dance around the room. But you should be able to start using the tool immediately after installing it. (There's a trap here: If you don't at least skim the help file later, you might miss some sophisticated uses of the tool.)
3. Tools are transparent. They work the way you'd expect them to, based on your familiarity with the Windows user interface. For example, if they show a list of folders and files, tools do it with a treeview/listview metaphor that resembles Windows Explorer.
4. Tools fill a common need. If a tool is something you'll only use once a year, you're unlikely to remember you even own it, let alone how to use it.
5. Tools are inexpensive. You shouldn't have to crave permission from your boss three levels up to purchase a tool; the benefits in productivity should be so obvious that the purchasing department practically makes you buy a copy.

Looking at that list, I'm struck by what a good set of rules of thumb it makes for small-scale application development in general. Whether you're writing for the commercial market or working as part of an IT department, wouldn't you like your applications to do one thing and do it well? To be easy to learn, transparent, and needed? To be cost-effective for your audience? The next time you're tempted to build a web browser into the application that you're working on—just because you can—you might reflect on the simple elegance of the tools that you use the most. Perhaps a bit of thought will convince you that in programs there is an appropriate level of functionality that is not, despite what Microsoft might have you believe, the level that includes every conceivable function.