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.

• By Mike Gunderloy
• 12/01/2003

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 an application.

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.

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 AlLhir's Learning 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.

Ringmaster, Anyone?
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 reporting.

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 Central.