Pragmatic Programming — Is It For You?

Strangled by the latest "methodology of the month"? The authors of <i>The Pragmatic Programmer</i> can help you wriggle out of the methodology straightjacket.

• By Mike Gunderloy
• 07/01/2001

As software developers, we face the interesting problem of how to create something out of nothing every time we type at the keyboard. As we gain insights into the process of software development, inevitably we try to formalize the process, so that what worked today can be repeated tomorrow. It's easy to get buried documenting every step you take or completely strangled by the "methodology of the month." Let's look at a book that offers some ways to avoid those traps.

In The Pragmatic Programmer: From Journeyman to Master (Addison-Wesley, 2000), authors Andrew Hunt and David Thomas give plenty of good advice on getting out of the methodology straightjacket. Here are some concrete tips that you can take home from their work.

Hunt and Thomas define their audience as programmers who want to become more effective and productive (and I expect you fall into that category, or you wouldn't be reading this column!). They identify some characteristics that pragmatic programmers tend to share:

• Early adopter/fast adopter — You love to try new things, and you're quick to grasp how they work and what they're good for.
• Inquisitive — You want to know how things work, not just what syntax to use in your code.
• Critical thinker — You're not quick to take a vendor's or an author's word on a programming issue.
• Realistic — You won't give in to schedule pressure in the face of knowledge that software always takes longer than management thinks.
• Jack of all trades — You try to be familiar with a broad range of software technologies, so you can pick the best tool for the task at hand.
• Care about your craft — "We feel that there is no point in developing software unless you care about doing it well."
• Think about your work — You keep an ongoing critical eye on your own development practices.

In 300 pages, the authors offer 70 tips that summarize their experiences in trying to nurture these characteristics in their own work. These range from general business advice ("Tip 3. Provide Options, Don't Make Lame Excuses") to some of the core wisdom of software engineering ("Tip 33. Use Assertions to Prevent the Impossible').

The tips, along with some handy checklists, are printed on a heavy cardstock pull-out at the end of the book. You could do worse than to have this sitting on your desk as a reference and brainstorming tool.

Although they cover the full spectrum of software development, from requirements gathering through testing, the pragmatic programmers do not dictate a particular development model or methodology. Their focus is on what works on the small scale. For example, the book includes a section on refactoring, a subject about which entire books can be (and have been) written. Rather than lay out a complex refactoring methodology with hundreds of specific cases, they discuss the overall concept of refactoring: "rewriting, reworking, and re-architecting code". They also point out what most of us know, but don't admit: that we don't refactor nearly as often as we should.

Refactoring your code -- moving functionality around and updating earlier decisions -- is really an exercise in pain management. Let's face it, changing source code around can be pretty painful: it was almost working, and now it's really torn up. Many developers are reluctant to start ripping up code just because it isn't quite right.

They go on to discuss real-world complications (like bosses and schedules) and why and how you can proceed to refactor anyhow.

In five and a half pages (including three exercises, and cross-references to related sections), the authors manage to introduce (if you haven't run across it before) or reinforce (if you have) an important concept of software engineering. There's enough meat to get you started, and enough references to other materials that you can dig in if you need to. An appropriate level of detail is what characterizes this book. Individual sections are seldom more than 4 or 5 pages long, but there are also pointers to Web resources and a good bibliography to help you learn more.

But the best thing about this book is that they agree with me on the importance of continual learning for good developers. They emphasize the development of a knowledge portfolio - a set of skills that you are continuously expanding and building upon. They give concrete suggestions for going about this, ranging from learning a new language every year to surfing the web for information.

Right now we have a great example of why you should develop the habit of building a knowledge portfolio: the introduction of .NET. It's Microsoft's next-generation development model. Visual Studio.NET will replace the current Visual Studio completely, bringing with it everything from a new IDE to new development concepts. A change of such magnitude provokes strong reactions. Developers have a variety of attitudes about .NET:

• "Wow! Neat stuff! I'm going to spend as much time as I can spare to learn how this all works in the beta."
• "Could be interesting, but I'll wait for the real thing. No point in crashing my development machine with a new language. Let someone else find the bugs."
• "It's different from Visual Studio 6, and therefore broken. The market will never go for it. I'm not going to waste my time learning this abomination."

Now let's think about the development world a year from now, when VS.NET is on the shelves and ready to use. Suppose Microsoft gets the majority of the bugs out, demonstrates that it's a great RAD environment, and markets it successfully to managers. The first of those developers will have job opportunities galore, while the last will find himself maintaining existing order entry code as his business shrinks. It's a clear win for the developer who takes this opportunity to build his knowledge portfolio.

But what if VS.NET doesn't succeed, Microsoft can't fix the bugs, the company overprices the product, sales flop, or the company pulls the plug before the product gets shrink-wrapped?

The first developer still wins. How? By learning new concepts from .NET. Maybe the importance of metadata finally becomes clear. Maybe she comes up with ideas for a class redesign in her own application based on some of the .NET framework classes. Maybe the notion of code-signing is finally clear, or her understanding of Web interfaces is improved. The point is that learning a particular product, or a particular tool, or a particular methodology is not simply a matter of building a skill (at least, not if you're a pragmatic programmer). As you learn, you can and should be thinking about what's behind the product or tool or methodology, what design concepts you can extract from it and reuse, and what you can apply to your own applications.

In fact, I'd say this book itself would be an excellent addition to your knowledge portfolio. I'll go farther than that: If I'm ever in the position of leading a development team in an office again, this book will be one of those that I'll stock in the restrooms, in multiple copies if need be. In ten minutes of reading at random, you're likely to find something here that directly applies to your current project. It's hard to find more of a bargain than that.