From the author of

From the author of

Agile methodologies are changing the face of software development. Suddenly,
everyone on the team is a critical part of the solution. Every programmer has
wide-ranging responsibilities and must make decisions that affect the outcome of
the project. Instead of trudging along like an anonymous foot soldier on a
death march
project, we've got to parachute into the drop zone with what we can carry
on our backs. We've changed the paradigm: Infantry have become
commandos.

Unfortunately, this isn't always an easy transition. It takes time and
experience to get used to the freedoms and responsibilities. This experience is
always hard won: You have to make mistakes to learn, and sometimes that can be
painfulnot to mention expensive. Having made most of these errors
ourselves at various points in our careers, we decided to try to spare others
from the same pain by capturing what we'd learned. We call the result
pragmatic programming.

In this article, we'll look at a few of the basic aspects of pragmatic
programming: taking responsibility, applying feedback, creating a pragmatic
environment, and basic coding philosophy. Pragmatic programming is about doing
things that work, regardless of prevailing dogma. You can be a pragmatic
programmer in almost any environment, but the spirit of pragmatic programming is
more closely aligned with the Agile methodologies.

Hopefully these tips will help you make the transition to the brave, new,
Agile world.

Taking Responsibility

The sign on President Truman's desk said, "The Buck Stops
Here," and that just about sums it up. The ultimate responsibility for
getting things done, and doing them right, lies with the individual. Now of
course development is a team effort, but being in a team doesn't mean that
you have to lose your personality, nor does it mean that you can stop taking
responsibility for the work you do.

Taking responsibility is one of those unfortunate phrases that sounds
much like the title of a lecture your parents gave you as a teenager. But
we're concerned with much more than simply returning the family car by 10
p.m.; taking responsibility works on many levels, and is a powerful way of
propelling your career forward.

Take responsibility for yourself and your career. Learn new
technologies and techniques, even if they're not directly relevant to the
problem at hand or your current project. For example, a group of pragmatic
programmers have recently started the
Language of the Year
club, in which developers work in their spare time to learn a new (and offbeat)
programming language. For 2002, they're learning the functional language
Haskell.

Take responsibility for your work. Don't be like
"Fred," who isn't real sure about his code but checks it in
anyway, relying on his teammates to sort out problems that arise. That's
not taking responsibilitythat's hiding behind your team. In addition,
Fred will accept delivery dates that he knows he can't meet, and will
promise interfaces that he knows he can't deliver. Not only is this whole
process wasteful and inefficient; it's downright rude to the rest of the
team.

Pragmatic programmers are different. They're honest about their
capabilities and aggressive about applying those capabilities effectively.
Remembering Pragmatic Tip No. 4, "Don't Live with Broken Windows"
(named after the Broken Windows theory of urban decay), they don't let
problems in code or process fester and continue to do damagethey fix
problems as they find them.

Take responsibility for your team. Quality comes from individuals,
but success comes from teams. But just like marriage, making a team work well
takes effort and dedication. Communicating is difficult, so we need to find ways
of making it easier. Use rituals (like the start of day stand-up meeting) to
make communicating a habit. Use the lightest-weight form of communication
that's sufficient. If you need to discuss an architectural issue,
don't spend hours putting together a memo full of UML diagrams and
extensive descriptions. Instead, find a spare whiteboard and brainstorm it face
to face. Use internal web sites, Wikis, and information radiators to get
information out in front of people.

Both success and failure are shared, so lame excuses that "It's the
team's problem, not mine" won't work anymore. Fix problems as
they occur, because once a team gets used to sloppy work, they'll start
producing sloppy code. Always look for ways to improve the team's process.
And don't just look; go ahead and improve the process as your understanding
grows.