The Many Hats of Software Development
Bored with coding? See what other key processes there are to getting your project to users and you might discover a new career path along the way.
"I am for all waters": I am a Jack of all trades, can turn
my hand to anything, a good all-round man. Like a fish which can live
in salt or fresh water.
Dictionary of Phrase & Fable
There's more to being a good developer than just being able to pound
out syntactically correct code. All the clever hashing algorithms and
well-commented procedures in the world won't get a product out the door
(or on to the end user's desk, if you're working in a corporate setting).
If you work in a large company, you may not need to worry about this too
much. There will be scores of other people in the software production
chain who will work together with you to make sure the code turns into
But the situation is different in small shops. Sometimes a team of two
or three developers has to do it all, perhaps with the help of a secretary
and a tester. Some software, of course, gets written by lone-wolf independents
who have to do the entire job, from concept to packaging. If you aspire
to work in such an environment, there are plenty of skills you can pick
up to become more employable and useful to a small software organization.
Even if you're working for BigCo, Inc., you might not want to be too
complacent about relying on your coding skills for your entire career.
Code fashions change, and today's high-demand language might be tomorrow's
boat anchor. (Seen many ads for Turbo Pascal programmers recently?) Combine
that with the ever-present threat of outsourcing and you might find it
worthwhile to expand your skill set as a career safety net.
Here, then, are some ideas for directions in which the good coder might
choose to explore. As a bonus, none of them involve going into management,
a fate which is often viewed as worse than death in our industry.
| 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,
Design It and They Will Build
One of the easiest ways to enhance your skills is to get more involved
in the design end of the software process. This will move you towards
being a software architect, though there's some debate about what exactly
a software architect does. Still, if Bill Gates' current title is "Chief
Software Architect," it can't be all bad.
One way to move more into the architecture is to become familiar with
the Unified Modeling Language. UML is an abstract, graphical language
for specifying the structure of software, which is supported by an ever-growing
variety of tools. Good resources for getting started include Sinan Si
UML (O'Reilly) and Jason T. Roff's UML:
A Beginner's Guide (McGraw-Hill/Osborne). The Object Management
Group's UML Resource Page (http://www.omg.org/uml/)
is a good online starting point.
But don't focus on UML too much: The tools are not the job (and there
are other ways to document the structure of an application, no matter
how universal UML aspires to be). To be a good software architect, you
need to understand how good applications are put together. This is an
area where you need to hit the books, especially if you didn't go through
a formal computer science academic program. Start with the classic Design
Patterns by Erich Gamma et al (Addison-Wesley) and then take
a look at Martin Fowler's Patterns
of Enterprise Application Architecture (Addison-Wesley). If
thinking on this level appeals to you, architect work may be in your future.
Toolsmithing for Fun and Profit
If you prefer to keep your hands grubby with code, you might consider
the job of toolsmith. As far as I know, this position was first described
by Harlan Mills (and popularized in Fred Brooks' classic, The
Mythical Man-Month). The toolsmith is the programmer who writes
tools for the rest of the team. In Brooks' rendition, this was "specialized
utilities, catalogued procedures, macro libraries." These days, it's
more likely to be XSLT style sheets and code generators, but the job remains
largely the same. The goal of the toolsmith is to make everyone else on
the team more productive (and, incidentally, to have fun building focused
little bits of code that give back immediate gratification).
Two things are key to being a good toolsmith: 1) writing excellent code
and 2) having excellent communication skills. Remember, your customers
are now right there, in the next cubicle (or office, if you're lucky),
and if your tools don't work, you'll know about it very quickly. As for
communications, it's not enough to just build tools when someone asks
you for something. You need to stay actively involved in the development
process so that you can spot opportunities to make life easier for everyone.
Finally, you'll need to keep up with that's going on in the development
world; sometimes the best tools are the ones that you can download for
free, or that are made by other companies. You need to be prepared to
help make build-vs.-buy decisions realistically.
How to get started toolsmithing? Build some tools! Spot some part of
your current project that can be simplified or automated and then bootleg
time or put in your own time to build the necessary tool. Do a good enough
job and you'll get noticed. Then you can make your pitch for building
tools as a full-time endeavor.
Sometimes software development seems like a three-ring circus:
Over here a handful of developers are pounding out code, in this ring
we have testers proving it doesn't work, and way over there are the Web
folks trying to deploy the latest semi-stable build. While it may seem
like the team lead is in charge of all this, there's another position
equally important to coordinating everything: buildmaster.
The job of producing a good build of software varies with the size of
the project. If there are only a couple of developers, it might be as
simple as getting the latest bits from your source code control system,
compiling, and e-mailing the results to your tester. For something like
Microsoft Office, it's a complex ballet involving dozens or hundreds of
computers, formal procedures, strict timetables, and Web-based status
Most of us will never build Office, but even a moderate software project
has enough steps that it makes sense to automate the build process. Getting
bits, setting version numbers, compiling (perhaps several separate versions),
posting status messages, rebuilding help files, running unit tests....
As the list of build tasks increases, the chance of missing an essential
step increases. And it's well known that frequent builds are the best
way to make sure your process is still on track.
Enter the buildmaster and build automation. Whether it's a homegrown
set of scripts or a free or commercial tool, there are many choices for
automating builds. Perhaps more important is an attitude. The buildmaster
needs to think about what can go wrong, and relentlessly eliminate manual
steps from the process. They also need the fortitude to confront anyone
who breaks the build or won't follow the rules. It's usually pretty obvious
when the build process is broken: Testers sit around with nothing to do
because working software never lands in their laps. If that's the case
in your organization, consider stepping up to offer ideas and solutions.
You might find yourself a new sideline.
Beating Software With a Stick
Speaking of testers, just how much do you know about software testing?
If you've been listening to me rant lately, you may already be doing unit
testing (I hope so!), but there's a lot more to the testing job than that.
The quality assurance folks also need to make sure the software can be
used by mere mortals, that the tested functions work together in a cohesive
whole and that the user interface makes sense, for example.
If you've got some spare cycles, using some of them to find out how the
test team works and what sorts of things they do can be an excellent investment.
First, you might discover that test appeals to you as much as development,
instantly doubling your opportunities—and, in most modern software
organizations, writing tests is just as important as writing code.
But there's an even larger benefit lurking here: If you can learn to
think like a tester, you can catch more errors before they ever make it
off your desk. Good testers can be incredibly inventive about the things
that they try. This is good, because real users are the same way. If your
software breaks when someone runs it during a full moon while listening
to MP3s, then it's broken, whether you considered that scenario or not.
A few hours watching a good tester pound on your software can be both
an illuminating and a humbling experience. It can also inspire you to
brush up your testing skills.
Your Knowledge In a Box
Finally, if you can write words as well as code, you might think
about the area sometimes known as UA, for User Assistance. Software is
worthless if the intended users can't figure out how to use it. To combat
this problem, someone has to write the array of manuals, help files, and
Web sites that are designed to teach software operation. To some extent,
writing good documentation depends on the same skills as writing good
code: You need to grasp what the program is doing and know how to make
it do what you want.
But there's a lot more to UA than just copying the comments out of the
code. First and foremost, you need to remember that you're explaining
the application to its actual users, who are unlikely to be developers.
Things that are blindingly obvious to you may require drawn out explanations,
and terms you've known for a decade might still need to be defined. You
also need to know how to write sentences and paragraphs that actually
make sense. Not to put too fine a point on it, that's a tough job for
many excellent coders.
Still, if you can manage it, UA skills will open more doors. Writing
skills are important in everything from giving conference presentations
to coming up with plans for future improvements to your software. And
the best way to learn to write is to simply practice. UA work can give
you a way to practice in a tightly constrained environment, where you
can concentrate on a single task (helping users with software) and learn
to do it well.
One Hat or Many?
That's a lot of hats to try to wear, and I didn't even discuss
things like graphic design, marketing, and licensing, all of which come
into play when you're trying to get software packaged and sold. I just
know I'm going to get mail from people arguing that developers should
simply concentrate on being better developers, and let the support organization
take care of all these other roles.
Here's how I look at it: Being a great developer is a fine thing, but
in the current economy, depending on just being a developer makes me personally
nervous. This industry has gone through a number of upheavals in the past
few decades and I'd hate to lose my career to the next upheaval. Learning
extra skills is just like diversifying your stock portfolio—it's
an easy form of insurance. To me, at least, it just makes sense to learn
new skills, especially if they help make me a better developer themselves.
Want to continue the debate? Got a different career strategy I haven't
mentioned? You can get hold of Mike at [email protected].
I'll use the most interesting comments in a future issue of Developer