Architecture & Design Pervasive Tooling

Pervasive Tooling

Every software developer has their own favorite set of tools they
use to build software. Depending on the job you’re doing at the
moment, you might choose a slightly different tool: this compiler or
that one, for example, or the version control system preferred by a
particular client. But some kinds of tools are pervasive. Just as no one
would dream of being a carpenter without hammers and saws, no one should
be developing Windows and Web software in 2006 without stocking their
toolbox with these basic categories of tools. While language choice and
personal preference (as well as budget) play a part in choosing precisely
which tools you use, here are my current thoughts on what tooling should
be truly pervasive in the current development universe.

1. Version Control – There’s no excuse for writing software
without some kind of version control system in place. There are dozens of
alternatives to choose between, free and commercial. Even if you’re not
working as part of a team, a version control system makes sense as a way
to archive and backup work, to experiment without messing up your main
line of code, and as a way to recover from mistakes.

2. A Web Browser – Yes, the browser is a very important part of
your development tool set these days. Obviously if you’re doing Web
development work you need to have the browser to test things in, but even
if you’re not, the browser is a better gateway to information than 99% of
the documentation that ships with today’s products. You need to take the
time to test out the major browsers (which in practice means Internet
Explorer and Firefox; for developers on Windows, everything else is an
also-ran for day-to-day use) with an eye towards figuring out which one
provides better services for your own usage pattern. Remember to look at
extensibility and customization.

3. An Integrated Development Environment (IDE) – Here’s where I
lose some people. I am aware of the school of thought that says “real men
write code in Notepad and compile it at the command line.” My experience
has been that roughly 1% of those who take this approach are actually
productive and the rest are simply too lazy to learn what a decent IDE can
do for them. With IDEs starting in price at “free” and available
for practically every language under the sun there’s no excuse for not
using one. I’m willing to make an exception for people who are comfortable
with one of the few remaining high-end programmer’s editors and who have
customized it to actually use a decent set of external tools to do useful
work.

4. Virtual Machines – Virtual PC or VMware, take your pick, but
you should have one of them installed and be using it. There are just so
many times when having a throwaway PC comes in handy – to test code, to
simulate a client site, to try a daily build, to recover old work, to
sandbox dangerous code, to install trial versions – that it’s just plain
silly to not have the ability to create as many virtual machines as you
need. As a corollary, you need to have a box with a decent amount of RAM
and free hard drive space, but if you don’t have those (and a big enough
monitor or dual monitors) someone is being penny-wise and pound
foolish.

5. A Local Database Server – OK, if you’re one of the rare
developers who isn’t writing applications with a database involved
you can skip this one. But if databases come into the picture for you, you
should have your database server on your own machine, or on a box you
control, not off on some distant server presided over by the high priests
of the IT department. There’s no reason why the database parts of your job
should slow you down while you wait for someone else to decide you’re
worthy of attention.

6. A Build Tool – A good build tool can do more than just
compile software for you. It will copy files around, FTP them to servers,
run your tests, build the documentation, check code coverage, and perform
dozens of other steps. The best build tools are general-purpose automation
engines. Whether you’re partial to XML-based tools or GUI tools, there are
a number of excellent build tools on the market, as well as free
alternatives and the build tools that are part of major IDEs. Learning how
one works and using it consistently can be a major productivity boost.

7. A Testing Tool – Whether you buy into the whole test-driven
development methodology or not, there are times when having an automated
testing tool can save you an untold amount of tedium. Depending on what
you’re doing, you may want to look at a pure unit testing tool, a GUI
automation tool, or some combination of tools. But in any case, you should
have some tool that lets you save and repeat a series of tests.

8. An XML Editor – XML is so pervasive these days that it makes
sense to have a tool that minimizes the angle bracket tax by giving you
color coding, automatic entity handling, multiple views, XSLT transforms,
XSD checking, and so on. While your IDE may have all or most of these
services built in, I’ve found it very convenient to have a lighter-weight
and more specialized tool that I can fire up to deal with all those pesky
XML files that clutter my life these days.

9. Some Kind of Scratchpad – One of the keys to writing good
code is to stay “in the zone” as much as possible, minimizing
interruptions. To encourage this, it helps to have a way to quickly record
the random bits of information that you’re bombarded with, as well as the
random thoughts that go by in the midst of development (“oh, hm, I’ll need
a class to do THAT later on”). To avoid ending up with a desk covered with
sticky notes, you should find a way to do this on the computer. At times
I’ve kept a simple text file open in an editor, used an outliner, or used
a local wiki for this, but however you do it, some sort of random
information storage is essential.

10. An RSS Reader – Yes, these days I consider an RSS reader to
be a development tool. Of course, like many other tools, this one can be
abused to lower productivity. It’s easy to fill up your RSS reader with
news and comics and other detritus that only distract you (sort of like
e-mail). But smart companies are now using RSS to deliver things like
repository checkin notices and build success notifications. A select group
of RSS feeds is also the best way to find out about new software releases
and coding techniques that will help you do your job better.

At the most basic level, the craft of software development hasn’t
changed in decades. We still take ideas out of our heads and wrestle with
them until they become working programs. But the tools we have to help us
with this job are continually evolving. When I interview a potential hire,
one of the things that I’m looking for is some indication that they’ve
kept up with the tooling. I don’t expect everyone to be on the absolutely
latest release of whatever the current darling open-source tool set is –
but if someone is still compiling with punched cards, you have to question
whether they are really equipped to learn new things. And in this
business, you’ve got to be able to move along quickly when it makes
sense.

About the Author

Mike Gunderloy is the author of over 20 books and numerous articles on
development topics, and the Senior Technology Partner for Adaptive Strategy, a
Washington State consulting firm. When
he’s not writing code, Mike putters in the garden on his farm in eastern
Washington state.

Latest Posts

Related Stories