Sat, 06 Aug 2005
Two solutions
(After a couple of days trying, off and on, to make a narrative of
threats to Agile work, I give up. I also give up on the cybernetics
tie-in. It gave me ideas, but I can't use it to express them. So it
comes down to three solutions and their justifications. And every time
I write about the last of them, I see it in a different way, so I'm
going to cut my losses and put up the first two until I can say
something coherent about the third.)
What we need is...
-
... an undergraduate-level textbook and course
-
I'm thinking here of an Agile alternative to texts like
Sommerville
and Pressman:
books that intend to be the only text for a survey/project course, books
that go through edition after edition, books that are referred to by
author name rather than title.
I'm inclined to agree, with
Kuhn,
that textbooks both mark and help cause the transition of a
particular style ("paradigm") from something revolutionary to
something normal. As Agile goes mainstream, a textbook will be
a significant marker.
A textbook will, I'm assuming, come with instructor support:
teaching guides, sample problems and solutions, advice on
fitting Agile teamwork into student schedules and the physical
infrastructure (dorm rooms, and carrels filled with people who
don't want to hear chatter). I get the
impression that Agile courses are more work for instructors than
conventional high-ceremony courses, so such materials will be
needed to get overworked instructors to switch to something new.
The existence of such courses is important in two ways. First,
it will route more students into Agile. They'll have a
"routinized" way of discovering it, instead of relying on
chance contacts with inspiring people or texts. Second, it will
slot Agile into the routine of hiring. Yes, that routine is
impersonal and lossy in many ways. But companies hiring,
say, undergraduate physics majors have an advantage.
They can look at a resume and be pretty sure that
the candidate knows a particular set of facts and has been
drilled in a set of techniques. So scarce interview time can
build on that base. We know nothing of the sort: does the
person know TDD? Has she ever refactored? Does she understand
the test-code-refactor cycle? Has she ever been in a standup
meeting? Does she know why they work? (This ties in with Josh
Kerievsky's claim at
Agile2005 that the amount of time coaches spend teaching
basics is retarding the spread of Agile within companies.)
I realize I'm talking about something intensely political: even when
the author describes a superset of Agile ideas and techniques,
rather than a common core, such a book serves to define a
field. When ideas get left out, people get mad.
I am convinced my schtick about tests
as examples will get left out, and that's wrong, wrong, wrong.
But I'll have to live with it.
Notes:
At Agile2005 a couple of instructors told me that they happily
assign multiple books: Refactoring, a
test-driven-design book, etc. I'd prefer that - if only because
such books stand a chance of being opened after the final exam
- so I could be wrong about some of the need for a survey
textbook. But there's still the need for instructor support
materials.
I'm a fan of alternative
education, like Dave West's Bachelor of Arts in
Software Development Technology or RoleModel's apprenticeships
or the Planetary
Collegium. But we'd be foolish to bet against society's dominant form
of job training, despite its well-known inadequacies.
Bill Wake's Refactoring Workbook seems to me a great
instructor guide or supplementary text. I wonder how much
it's used?
-
... to take over a computer science department
-
If you say "Agile in
academia" I think of people: Rick Mugridge,
James Noble,
Grigori
Melnik,
Robert
Biddle, etc. The only
university name that comes to mind is North Carolina State, but
I just checked the home pages of all the faculty there, and it
appears that
Laurie
Williams is the only one interested enough in Agile to mention
it.
Scattered individuals have extra trouble making
progress. Compare to my wife's department. There are several
professors whose interests are close enough to hers that they
routinely publish together. Because they're all in the same
place, they can bounce ideas off each other at random
moments. And I'm especially interested in how they trade favors
with each other and thus exploit comparative
advantage to the benefit of all. Conferences are great because they're concentrated events that
raise people's emotional energy and increase cultural capital,
but they're not enough.
The lack of departments with a concentration on Agile
hurts development of the field in other ways. In 1976, I wanted
to be an astronomer. Going to Caltech was an obvious
choice. Eight years later, I was peripherally involved in the
big AI boom (as a Lisp implementer). Had I wanted to get a
graduate degree in AI, there would have been obvious places to
go: MIT, CMU, Stanford. Going to a department with a specialty
in AI is less risky than going to work with a person who
specializes in AI: it's easier to recover from bad luck -
personality mismatches, your mentor leaving for another
university. Because of that, some potentially productive people
will go a different field. We want them all.
Accomplishing this takeover is an exercise left to the reader.
## Posted at 12:56 in category /conferences
[permalink]
[top]
|
|
