Restocking the Toolbox

It’s worthwhile to spend time with new tools, but only if it gets you ahead in the development game.

• By Mike Gunderloy
• 06/01/2004

This took a very long time to manage, though Alice held the bag open very carefully, because the Knight was so VERY awkward in putting in the dish: the first two or three times that he tried he fell in himself instead. "It's rather a tight fit, you see," he said, as they got it in a last; "There are so many candlesticks in the bag." And he hung it to the saddle, which was already loaded with bunches of carrots, and fire-irons, and many other things.
— Lewis Carroll, Through the Looking Glass, Chapter VIII

Another year has passed in the life of this column, and it's time for me to ruminate over software tools once again. I recently repaved my main development computer, and the sheer number of packages I felt that I needed to be reinstalled put me in mind of the White Knight from Through the Looking Glass, the one who has a large number of devices, from bee hives to fire-irons, hung about his horse just in case he might need them in the future. Why do we load up on tools so? And given the sheer number of software tools out there, how is one to choose the ones to invest money in?

The Search for the Holy Grail
The "why" of it seems fairly obvious to me: We developers are cantankerous with our tools, because we know darned well they can be improved and they're never perfect. Consider the simple case of text editors. I don't know how many editors I have installed, tested, and uninstalled over the years, but surely it must be in the dozens. And like many developers of a certain age, I've even (under the influence of one or another of the classic Software Tools books) gone some ways down the path of writing my own.

What's the point? Surely the principles of editing plain-text documents are well known by now. That seems an innocuous enough statement, but if you think about it for a moment, it leads to another statement that will strike most developers as absurd: That the perfect text editor must exist, and all one needs to do is find it.

There's No Accounting For Taste
If there is a perfect text editor out there, I've certainly never found it (and please, I beg you: if you're going to e-mail me about emacs, don't bother). Over the years, I've discovered that what I want is some combination of all of the editors that I've tried: a keystroke combination from one, a bit of user interface from another, a built-in diff utility from a third, and so on. The reason that no perfect text editor has turned up for me is that I've been exposed to too many different attempts, and that my own notions of what should be in a text editor don't precisely match up with the developers of any editor that I've tried. Of course, the same principle applies to any moderately complex utility, from an FTP package to a source code control server.

The problem is that I know darned well there's no magic in the source code for a text editor. Given unlimited time and a good team, I could design and build a text editor that would be perfect for me (just as I suspect all of the text editors currently on the market are perfect for their developers). There's a trap here. The temptation is very strong to continue searching for the perfect text editor, on the grounds that somewhere there must be a development team whose prejudices in the matter match my own.

But one can waste a lot of time searching for perfection in an imperfect world. When picking a text editor, you ought to implement a strategy of satisfaction rather than one of optimization. Instead of looking for the absolute best solution, figure out what will satisfy you and stop when you find a solution that's at least that good. In my case, I found a text editor that could handle the features I use most often and quit looking at more (except when I'm writing software reviews, but that's another story entirely). There may be a more perfect text editor for me out there, but looking for it isn't worth the effort.

The Singing Sirens
Not wasting time looking for perfect tools is an admirable philosophical position, but it's a darned hard one to put into practice. For starters, there's an entire industry devoted to convincing you to try out the next piece of software in your search for the perfect utility. I refer, of course, to the entire apparatus of books and magazines and Web sites and reviews all aimed at providing information and enticing you into new purchases. Of course, since I write a good number of software reviews myself, I'm as much a part of the problem as anyone.

Then, too, sometimes the new tool is better. Just because no tool is perfect, and most progress comes in tiny increments, doesn't mean that you can ignore progress. You might not care whether you use one text editor or another, but a compiler that works in real time from code you type into an IDE is generally recognized as superior to a batch facility based on punch cards, even though the one evolved incrementally from the other.

What's the answer? The best one I can come up with is to stay in touch with changing tools in your particular area of development and to make at least a little "sandbox time" to play with the latest and greatest. Even though most won't be worth more than a casual look, you may eventually come across something that will so increase your productivity that you can convince your boss to buy a license. And even if not, what's better than paid play time?

Keeping Hold of the Purse Strings
Then again, maybe you're the boss yourself — or at least the person who has to foot the bills for the tools that you use. This is especially true if you're in a small partnership or working alone. If you don't have a strategy for deciding what money to spend, you're setting yourself up for problems when the credit cards bills come do. 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 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 documentation will save you much more than that in time that would otherwise be spent writing docs from scratch. But these easy decisions can be insidious. Decide to spend $500 to save effort twenty times, and suddenly you've spent $10,000 on tools with no income to show for it.

When you're in control of the budget, you can't afford to make these decisions on a tool-by-tool basis. This is especially true when you're just starting out and your income steam is unclear. 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. As a bonus, you have an easy way to get rid of software salesmen: "Sorry, we've already spent our tools budget for the year."

Now, 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 your business, in the form of more tools. Repeat until you own all the tools that you want, or until you've made enough money to retire. That's my story, and I'm sticking to it.

How do you feel about tools? Always looking for new ones, or have you decided it's more rewarding to just write code with the set you already have? You can get hold of me at [email protected]. I'll use the most interesting comments in a future issue of Developer Central.