required to play jazz, but you have to play it in order to
get the “feel.” The famous trumpet player and vocalist Louis
“Satchmo” Armstrong said of jazz, “Man, if ya gotta ask,
you’ll never know.”
There’s no expertise without experience, and there’s no
substitute for experience—but we can work to make the
experience you have more efficient and more effective.
Trumpeter Clark Terry used to tell students the secret to learning
music was to go through three phases:
• Imitate
• Assimilate
• Innovate
That is, first you imitate existing practice and then slowly assimi-
late the tacit knowledge and experience over time. Finally you’ll be
in a position to go beyond imitation and innovate. This echoes the
cycle of training in the martial arts known as Shu Ha Ri.
In the Shu phase, the student copies the techniques as taught—
from a single instructor—without modifications. In the Ha stage,
the student must reflect on the meaning and purpose and come to
a deeper understanding. Ri means to go beyond or transcend; no
longer a student, the practitioner now offers original thought.
So, among other things, we need to look at ways to keep as much
existing expertise as we can in the project itself; none of this pro-
gression will help if practitioners don’t stay in the field.
Keeping Expertise in Practice
The nursing profession was losing expertise rapidly; because of the
limits of pay scales and career development, nurses with high skill
levels would reach a point in their careers where they were forced to
move out of direct clinical practice and into areas of management
or education or move out of the field entirely.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
USING THE DREYFUS MODEL EFFECTIVELY
49
This largely remains the case in software development as well. Pro-
grammers (aka “coders”) are paid only so much; salespeople, con-
sultants, upper management, and so on, might be compensated
more than twice the amount of the best programmer on a team.
Companies need to take a much closer, much more informed look
at the value that these star developers bring to an organization.
For instance, many project teams use
a sports metaphor to describe positive Winners don’t carry
aspects of teamwork, a common goal, and losers.
so on. But in reality, our idealized view
of teamwork doesn’t match what really happens on professional
sports teams.
Two men may both play the position of pitcher for a baseball team,
yet one may earn $25 million a year, and the other may earn only
$50,000. The question isn’t the position they play, or even their
years of experience; the question is, what is the value they bring to
the organization?
An article by Geoffrey Colvin16 expands on this idea by noting that
real teams have stars: not everyone on the team is a star; some are
rookies (novices and advanced beginners), and some are merely
competent. Rookies move up the ladder, but winners don’t carry
losers—losers get cut from the team. Finally, he notes that the top
2 percent isn’t considered world-class. The top 0.2 percent is.
And it’s not just high-pressure sports teams; even churches recog-
nize difference in talent and try to use it effectively. Recently I was
shown a national church’s newsletter that offered advice on how
to grow and maintain a music program. Their advice sounds very
familiar:
• A group is only as good as its weakest link. Put the best per-
formers together to perform for the main service, and create
“farm teams” for other services.
• Keep a steady group with the same performers every week.
You want the group to jell; rotating players in and out is
counterproductive.
16. Fortune Magazine, March 18, 2002, p.50.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
BEWARE THE TOOL TRAP
50
• Timing is everything: the drummer (for a band) or accompa-
nist (for choral groups) has to be solid. Better to use a prere-
corded accompaniment than a flaky drummer or organist.
• Make your group a safe place for talented musicians, and
watch what happens.
That’s exactly the same thing you want on a software team.17 This
idea of providing the right environment for skilled developers is
critical.
Given that the highest-skilled developers are orders of magnitude
more productive than the least-skilled developers, the current com-
mon salary structures for developers is simply inadequate. Like the
nursing profession years ago, we continually face the risk of losing
a critical mass of expertise to management, competitors, or other
fields.
This tendency is made worse by the recent increases in outsourcing
and offshoring development to cheaper countries. It’s an unfortu-
nate development in that it further cements the idea in people’s
minds that coding is just a mechanical activity and can be sent
away to the lowest bidder. It doesn’t quite work that way, of course.
As in the nursing profession, experts at coding must continue to
code and find a meaningful and rewarding career there. Setting a
pay scale and a career ladder that reflects a top coder’s value to the
organization is the first step toward making this a reality.
TIP 5
Keep practicing in order to remain expert.
2.5 Beware the Tool Trap
There has been much written on the role of tools, formal models,
modeling, and so on, in software development. Many people claim
that UML and model-driven architecture (MDA) are the future, just
17. The drummer analogy is stretching it a bit, but I do talk more about the rhythm of development projects in Practices of an Agile Developer: Working in the Real World [SH06].
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
BEWARE THE TOOL TRAP
51
as many people claimed that RUP and CMM process models were
the salvation of the industry.
But as with all silver-bullet scenarios, people soon found out that
it just ain’t that easy. Although these tools and models have their
place and can be useful in the right environments, none of them
has become the hoped-for universal panacea. Worse yet, the misap-
plication of these approaches has probably done far more damage
than good.
Interestingly enough, the nursing profes-
sion had similar problems with regard to The model is a tool, not
the use of tools and formal models. They a mirror.
had fallen into the same trap that many
architects and designers fall for: forgetting that the model is a tool,
not a mirror.
>
Rules cannot tell you the most relevant activities to perform in a
given situation or the correct path to take. They are at best “train-
ing wheels”—helpful to get started but limiting and actively detri-
mental to performance later.
Dr. Deborah Gordon contributed a chapter to Benner’s book, in
which she outlines some of the dangers of overreliance on formal
models for the nursing profession. I’ve reinterpreted her sentiments
with the particulars of our profession, but even the original version
will sound pretty familiar to you.
Confusing the model with reality
A model is not reality, but it’s easy to confuse the two.
There’s the old story of the young project manager, where his
senior programmer announced she was pregnant and going to
deliver during the project, and he protested that this “wasn’t
on the project plan.”
Devaluing traits that cannot be formalized
Good problem-solving skills are critical to our jobs, but prob-
lem solving is a very hard thing to formalize. For instance,
how long can you just sit and think about a problem? Ten
minutes? A day? A week? You can’t put creativity and inven-
tion on a time clock, and you can’t prescribe a particular tech-
nique or set of techniques. Even though you want these traits
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
BEWARE THE TOOL TRAP
52
on your team, you may find that management will stop valu-
ing them simply because they cannot be formalized.
Legislating behavior that contradicts individual autonomy
You don’t want a bunch of monkeys banging on typewriters
to churn out code. You want thinking, responsible develop-
ers. Overreliance on formal models will tend to reward herd
behavior and devalue individual creativity.18
Alienating experienced practitioners in favor of novices
This is a particularly dangerous side effect. By targeting your
methodology to novices, you will create a poor working envi-
ronment for the experienced team members, and they’ll sim-
ply leave your team and/or organization.
Spelling out too much detail
Spelling out the particulars in too much detail can be over-
whelming. This leads to a problem called infinite regress: as
soon as you make one set of assumptions explicit, you’ve
exposed the next level of assumptions that you must now
address. And so on, and so on.
Oversimplification of complex situations
Early proponents of the Rational Unified Process (and some
recent ones) cling to the notion that all you have to do is “just
follow the process.” Some advocates of Extreme Programming
insist all you need to do is “just follow these twelve—no wait,
maybe thirteen—practices” and everything will work out. Nei-
ther camp is correct. Every project, every situation, is more
complex than that. Any time someone starts a sentence with
“All you need to do is...” or “Just do this...,” the odds are they
are wrong.
Demand for excessive conformity
The same standard may not always apply equally in all situ-
ations. What worked great on your last project may be a dis-
aster on this one. If Bob and Alice are hugely productive with
Eclipse, it might wreck Carol and Ted. They prefer IntelliJ or
TextMate or vi.19
18. Of course, there’s a balance here—you do not want a “cowboy coder” who ignores the team and common sense to strike out on his own.
19. OK, I have to confess that over the course of time, I wrote this book using vi, XEmacs in vi mode, and TextMate.
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
CONSIDER THE CONTEXT, AGAIN
53
Insensitivity to contextual nuances
Formal methods are geared to the typical, not the particu-
lar. But when does the “typical” really ever happen? Context
is critical to expert performance, and formal methods tend
to lose any nuances of context in their formulations (they
have to; otherwise, it would take thousands of pages just to
describe how to get coffee in the morning).
Confusion between following rules and exercising judgment
When is it OK to break the rules? All the time? Never? Some-
where in between? How do you know?
Mystification
Speech becomes so sloganized that it becomes trivial and
eventually loses meaning entirely (for example, “We’re a
customer-focused organization!”). Agile methods are fast los-
ing effectiveness because of this very problem.
Formal methods have other advantages and uses but are not help-
ful in achieving these goals. Although it may be advantageous
to establish baseline rules for the lower skill levels, even then
rules are no substitute for judgment. As ability to judge increases,
reliance on rules must be relaxed—along with any rigid institu-
tional enforcement.
TIP 6
Avoid formal methods if you need creativity, intuition, or
inventiveness.
Don’t succumb to the false authority of a tool or a model. There is
no substitute for thinking.
2.6 Consider the Context, Again
One of the most important lessons from the Dreyfus model is the
realization that although the novice needs context-free rules, the
expert uses context-dependent intuition.
The man with his pickled fish has set down one truth and has
recorded in his experience many lies. The fish is not that color, that
texture, that dead, nor does he smell that way.
John Steinbeck, The Sea of Cortez
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
CONSIDER THE CONTEXT, AGAIN
54
In The Sea of Cortez, Steinbeck muses on the interplay of context
and truth. You can describe a Mexican Sierra fish in the labora-
tory. All you have to do is “open an evil smelling jar, remove a stiff
colorless fish from formalin solution, count the spines, and write
the truth ‘D. XVII-l5-IX.”’ That’s a scientific truth, but it’s devoid of
context. It’s not the same as the living fish, “its colors pulsing and
tail beating in the air.” The living fish, in the context of its habitat,
is a fundamentally different reality from the preserved fish in the
jar in the lab. Context matters.
You may have noticed that the high-priced consultant’s favorite
answer is “It depends.” They’re right, of course. Their analysis
depends on a great many things—all those critical details that the
expert knows to look for, while ignoring the irrelevant details. Con-
text matters.
You might ask the expert to open a locked door. Fair
enough, but consider the difference context might
make: opening the door to rescue the baby on the
o
ther side in a burning house is quite a different
exercise than picking the lock and leaving no traces
at the Watergate Hotel, for instance. Context matters.20
There is an inherent danger in decontext-
Beware decontext-
ualized objectivity, that is, in trying to be
ualized objectivity.
objective about something after taking it
out of its context. For instance, in the pre-
vious Steinbeck quote, a preserved fish—perhaps dissected for
study—is quite a different thing from the silvery flashing beast glid-
ing though a cresting wave.
For the breaking-and-entering example, “I want to open this locked
door” really isn’t sufficient. What’s the context? Why does the door
need to be opened? Is it appropriate to use an axe, a chainsaw, or
lock-picking tools, or can we just go around back and use the other
door?
In systems thinking, as in object-oriented programming, it’s often
the relationships between things that are interesting, not the things
themselves. These relationships help form the context that makes
all the difference.
20. For more on expertise in lock picking, see How to Open Locks with Improvised Tools [Con01].
Report erratum
Prepared exclusively for Jose Luis Loya
gggggggggggggggg
this copy is (P2.0 printing, January 2009)
DAY-TO-DAY DREYFUS
55
Context matters, but the lower several stages on the Dreyfus model
aren’t skilled enough to know it. So once again, we have to look at
ways of climbing the Dreyfus ladder.
2.7 Day-to-Day Dreyfus
Well, this has been all fun and fascinating, but what good is the
Dreyfus model really? Armed with knowledge of it, what can you
do with it? How can you use this to your advantage?
First, remember that one size does not fit
all, either for yourself or for others. As you One size does not fit all.
can see from the model, your needs will
be different depending on what level you are on. What you need for
your own learning and personal growth will change over time. And
of course, how you listen and react to others on the team needs to
take into account their own skill levels as well.
Novices need quick successes and context-free rules. You can’t
expect them to be able to handle novel situations on their own.
Given a problem space, they’ll stop to consider everything, whether
it’s relevant or not. They don’t see themselves as part of the sys-
Pragmatic Thinking and Learning Page 6
