Restocking the Toolbox
It’s worthwhile to spend time with new tools, but only if it gets you ahead in the development game.
"We'd better take it with us," the Knight said. "It'll
come in handy if we find any plum-cake. Help me to get it into this bag."
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
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
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.
| Want to read more of Mike's work? Sign
up for the monthly Developer Central e-newsletter,
including product reviews, links to web content, and more,
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
Mike Gunderloy, MCSE, MCSD, MCDBA, is a former MCP columnist and the author of numerous development books.