There’s no shortage of advice on how you should
model, design, test, build, and deploy your software project. Every
author, trainer, and pundit will swear up and down that “they know the
secret.” They know how to build great software—they’ve done it before
and all you have to do is follow their lead. Buy their software, read
their books, buy their tools, attend their seminars, and do it just
like they do it and you’ll be a success, right? But somehow it doesn’t
seem to be that easy.
In this week’s column, the first in a series of
articles that will explore the different avenues of software
development, Andy Hunt and Dave Thomas, the Pragmatic Programmers,
begins the journey by revealing that learning software development
isn’t as easy as the pros make it out to seem. Find out why these
books and seminars work for them, but not always for the rest of us.
What are we doing wrong?
One trap we keep falling into is the
expectation that we can make developing software a “no-brainer.”
Everyone would adore it if we could just follow this or that process,
just follow those rules, and have it all work out. But software
development simply isn’t amenable to a “no-brainer” approach; here’s
one reason why.
A few years ago we discovered a helpful tool called the Dreyfus model
of skills acquisition. It describes people’s needs, how they learn and
problem-solve according to their skill level in a particular area. We
can use the Dreyfus model to better understand people and the role of
process in software development.
For instance, beginners require simple, context-free rules in order to
function in a new environment. They don’t want to see the big
picture—it’s overwhelming, confusing, and (to them)
irrelevant. Suppose you were giving a recipe to a novice cook. It’s
not at all sufficient to say “cook until done,” because the novice has
no experience to determine what “done” means. A novice needs to be
told to cook it for thirty-five minutes at 350 degrees. No more, no
Advanced practitioners, on the other hand, “must” have access to the
big picture or they won’t be able to function. If you tell an expert
chef to cook anything for exactly thirty-five minutes at precisely 350
degrees they will, at best, ignore you. “Cook until done,” while
meaning nothing to a novice, speaks volumes to an experienced chef. It
means taking into account the humidity, the condition of this
particular batch of ingredients, the vagaries of the equipment in
question (that oven always runs hot), the color of the dish, the
aroma, and so on.
Any process that tries to reduce software development to
a “no brainer” will eventually produce just that: a product developed
by people without brains. Instead of trying to turn software
development into a “no-brainer” activity, we need to recognize that
it’s a “full-brainer” activity, and deal with it
accordingly. Pragmatic programmers realize that everything can be
questioned, and hopefully improved upon.
Consider the very role of process and rules. In the original Dreyfus
research, experienced airline pilots were called on to create rules
for the beginners. They did, and the beginning pilots followed them
just fine. But then the researchers sneakily turned the tables and
made the experienced pilots follow their own rules—strictly.
It killed their performance.
Whether you’re attempting to follow eXtreme Programming or achieve CMM
Level 5, one size for all the team members simply will not
fit. Beginners need rules, but you can’t force advanced practitioners
to follow them. Not everyone is capable or comfortable working in a
pair-programming environment, and very few people are effective or
comfortable in producing excruciatingly detailed designs for something
they haven’t built yet. Both groups (and the shades of gray in
between) have different needs, and the successful project accommodates
each of them.
But that’s quite a burden to put on a process or a project manager
exclusively, so we’ll have to pick up some of the slack
ourselves. That means that we as pragmatic, forward-thinking
individuals have to get better at two key things.
Two Primary Activities
Developing software is largely composed of two
activities: learning and communication. Surprised? Those probably
aren’t the two chief activities that came to your mind first. But in
one form or another, that’s what fills our days. We’re always
learning—not just new technology, but the problem domain, the quirks
of the users/clients, the characteristics of the evolving system
itself. Similarly we’re always communicating: with the machine, with
the users, with each other, and sometimes even to a family member who
wonders just exactly what it is we do all day. These activities, while
critical to success, are also very personal. The good news is that you
can do something about it yourself, without any corporate mandate.
In this continuing column, we’ll look at many different aspects of
software development. But underlying it all, we’ll be talking about
the raw ingredients of software development—us developers, and how we
can improve ourselves, our projects, and our teams.
As it turns out, the final frontier isn’t outer space at all. It’s
inner space—our own minds. Join us in stretching the frontier.
This article originally appeared on StickyMinds.com
and is reprinted here with their kind permission.
Copyright © 2005 The Pragmatic Programmers, LLC.