In May 2001, the C/C++ Users Journal published John Hubbard’s article Building a Professional Software Toolkit. In the article, Hubbard suggests that we programmers should be manufacturing our own tools. That this is an absurd idea was seen almost instantly: while musing over the article, I was watching a workman refurbish my neighbor’s garage. He is an experienced carpenter, and he builds the scaffolding and jigs necessary to align and erect permanent structures. However, he does not build the tools he uses daily. He had built neither his hammer, nor his Skilsaw®, nor his level, nor had he build the truck in which he arrived. Instead, it’s much more economical for him to buy most of his tools from vendors who specialize in building tools, and then use those tools to build the scaffolding needed for his work.

The article suggested four properties that a tool should meet to be considered 'good':

• policy free;
• reliable;
• freely available;
• supplied in source code form.

This is similar to the list of properties provided in Software Tools, Kernighan & Plauger, Addison-Wesley, ISBN 0-201-03669-X,1976. Although K&P listed ‘source code’ as a useful property 25 years ago, they also mention that ‘compilers should be written by experts’, so they drew a vague line somewhere between tools and TOOLS.

The time has come to revise this list of properties, so let me waste no time in demolishing the old list.

Take ‘policy free.’ Hubbard says, "Dogma tends to give indigestion to people who like to reason things through from first principles". Usually, I don’t have the time to go back to square 0 on every project. To the contrary, I’d rather have a tool that implements good policy, and argue for that policy. Most often, my argument will be in favor of some standard.

'Reliable' - sure. If it doesn't work, it's not a tool.

‘Availability’ is defined by the market place, and the cost of getting the tool to that market. On the other hand, ‘freely available’ these days may mean ‘available at no cost’. But it’s obvious that tool-building companies can’t stay in business very long by giving their intellectual property away.

Finally, consider ‘supplying in source code form’: this directly contravenes the requirement for ‘reliability’. If I tinker with software, I may break it, or, it may no longer work the way the designer intended. If my compiler is incapable of rebuilding the tool because of ‘quirks’, I’ve wasted time. From my viewpoint, it is better to acquire an executable, if possible, so I can get on to my work with a minimum of interruption, think about improvements along the way, and pass those ideas on to the tool builder.

To get a handle on what is involved with dealing with a vendor’s source code, humor me while I invent and throw a few numbers around. My software and files occupies approximately 5.2Gbytes on my hard drive. Assume for the sake of argument, that the source required to generate the executables of those tools is 1% of that storage, or 52Mbytes. Assume that Help files, configuration files, and examples comprise another 1% for a total source supply of 104Mbytes.

For comparison, consider Melville’s Moby Dick: it is approximately 1.2Mbytes. The source for my tools, then, would be the equivalent of 86 copies of Moby Dick in different languages by different authors using different styles. My personal interest in reading and modifying that much software is exactly 0.

So why I provide source code to my customers? The major reason is to ensure that the components our clients purchase can be upgraded to the next compiler release with no trouble.

Turning the ‘supply source code’ scrutiny on my own toolkit, I find three loose categories of software: system, user, and developer tools.

My system software includes the OS (Windows 2000 Pro); drivers for various hardware; system utilities; and miscellaneous things like a few text editors (edlin lives!). This lot of tools came as a single huge package. There is no chance that I want to look at the source for this stuff.

My user tools are the software that helps me get my ‘ordinary’ work done. I include in this category: Microsoft Office; AOL Instant Messenger; Mathcad; Microsoft Money, Google, Firefox, and so forth. I’m not interested in the source for this stuff, either.

My developer tools include Microsoft Visual Studio and a few other doohickeys.

In software as in physics, the most important criterion is leverage. By this criterion, a tool may be as primitive as a stick, and still be satisfactory. On the other hand, a tool to perform laser eye surgery requires the absolute highest quality, and the concomitant expenditure of time and money to guarantee that quality.

Thus, acquiring software is a business expense. Measure tool value along the three axes of time, cost, and quality. You get your money's worth by minimizing time and cost, while maximizing quality. The lore is that the best you can do is ‘pick any two’.

-- Peter N Roth