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.
Pragmatic, adj.: 1. Dealing or concerned
with facts or actual occurrences; practical.
- By Mike Gunderloy
- July 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.
Coders, DBAs: Let Us Know What
If you're a current or former
MCSD or an MCSD wannabe who
thought MCP Magazine
conspicuously ignored your needs
(yep, we heard it all, including
"Why don't you just call it
MCSE Magazine?"), let us know
what you think of our new MCSD-related
coverage online. Write to Michael
Domingo, Web Editor, at email@example.com;
put "MCSD Feedback" on the Subject
line of your message.
Also, if you have an interesting
technique or developer time-saver
you want to share with fellow
MCPs, we'd love to hear about
it at that same e-mail address.
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
- 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
- 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
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
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
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
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.