TITLE: The Academic Future of Agile Methods
AUTHOR: Eugene Wallingford
DATE: August 09, 2005 4:00 PM
DESC: Brian Marick's recent blog entries have me thinking about cross-disciplinary connections, pragmatism, and the long-term survival of agile methods.
-----
BODY:
After a week impersonating one of the
Two Men and a Truck
guys, I'm finally back to reading a bit.
Brian Marick wrote several articles in the
last week that caught my attention, and I'd
like to comment on two now.
The
first
talked about why Brian thinks the agile movement
in software development is akin to the British
cybernetics movement that began in the late 1940's.
He points out three key similarities in the two:
- a preference for performance (e.g., writing
software) over representation (e.g., writing
requirements documents)
- constant adaptation to the environment as a
means for achieving whole function
- a fondness for surprises that arise when we
build and play with complex artifacts
I don't know much about British cybernetics, but
I'm intrigued by the connections that Brian has
drawn, especially when he says, "What I wanted
to talk about is the fact that cybernetics fizzled.
If we share its approaches, might we also share
its fatal flaws?"
My interest in this seemingly abstract connection
would not surprise my
Ph.D. advisor
or any of the folks who knew me back in my grad
school days -- especially my
favorite philosophy professor.
My research was in the area of knowledge-based
systems, which naturally took me into the related
areas of cognitive psychology and epistemology.
My work with Dr. Hall led me to the American
pragmatists -- primarily
C. S. Peirce,
William James,
and
John Dewey.
I argued that the epistemology of the pragmatists,
driven as it was by the instrumental value of
knowledge for changing how we behave in particular
contexts, was the most appropriate model for AI
scientists to build upon, rather than the mathematical
logic that dominates most of AI. My doctoral work
on reasoning about legal arguments drew heavily on
the pragmatic logic of
Stephen Toulmin
(whose book The Uses of Argument I strongly
recommend, by the way).
My interest in the connection between AI and pragmatic
epistemology grew from a class paper into a proposed
chapter in my dissertation. For a variety of reasons
the chapter never made it into my dissertation, but
my interest remains strong. While going through files
as a part of my move last week, I came across my folder
of drafts and notes on this. I would love to make time
to write this up in a more complete form...
Brian's
second
article gave up -- only temporarily, I hope -- on
discussing how flaws in the agile movement threaten
its advancement, but he did offer two suggestions
for how agile folks might better ensure the long-term
survival and effect o their work: produce a seminal
undergraduate-level textbook and "take over a computer
science department". Just how would these accomplish
the goal?
It's hard to overestimate the value of a great textbook,
especially the one that reshapes how folks think about
an area. I've written often about the ebbs and flows
of the first course in CS and, while much of the history
of CS1 can be told by tracing the changes in programming
language used, perhaps more can be told by tracing the
textbooks that changed CS1. I can think of several
off-hand, most notably Dan McCracken's Fortran IV text
and Nell Dale's Pascal text. The C++ hegemony in CS 1
didn't last long, and that may be due to the fact that
no C++-based book ever caught fire with everyone. I
think Rick Mercer's Computing Fundamentals with C++
made it possible for a lot of instructors and schools
to teach a "soft" object-oriented form of OOP in C++.
Personally, I don't think we have seen the great
Java-in-CS1 book yet, though I'm sure that the small
army of authors who have written Java-in-CS1 books
may think differently.
Even for languages and approaches that will never
dominate CS1, a great textbook can be a defining
landmark. As far as OOP in CS1 goes,
I think that
Conner, Nigidula, and van Dam's Object-Oriented
Programming in Pascal is still the benchmark.
More recently, Felleisen et al.'s
How to Design Programs
stakes a major claim for how to teach introductory
programming in a new way. Its approach is very
different from traditional CS1 pedagogy, though,
and it hasn't had a galvanizing effect on the world
yet.
An agile software engineering text could allow us
agile folks to teach software engineering in a new
and provocative way. Many of us are teaching such
courses already when we can, often in the face of
opposition from the "traditional" software engineers
in our departments. (When I taught my course last
fall, the software engineering faculty argued strongly
that the course should not count as a software
engineering course at all!) I know of only agile
software engineering text out there -- Steinberg
and Palmer's Extreme Software Engineering
-- but it is not positioned as the SE-complete
text that Brian envisions.
Closer to my own world, of course, is the need for
a great patterns-oriented CS1 book of the sort some
of us have been
working on for a while.
Such a text would almost certainly be more agile
than the traditional CS1 text and so could provide
a nice entry point for students to experience the
benefits of an agile approach. We just haven't yet
been able to put our money where our mouth is -- yet.
On Brian's three notes:
- Using Refactoring and Test-Driven
Development and various other readings can
work well enough for an agile development course,
but the need for a single text is still evident.
First, having scattered materials is too much
work for the more casual instructor charged with
teaching "the agile course". Second, even together
they do not provide the holistic view of software
engineering required if this text is to convince
CS faculty that it is sufficient for an introductory
SE course.
- Yes and yes. Alternative forms of education such
as apprenticeship may well change how we do some
of our undergraduate curriculum, but no one should
bet the survival of agile methods on the broad
adoption of radically different teaching methods
or curricula in the university. We are, as a whole,
a conservative lot.
That doesn't mean that some of us aren't trying.
I'm chairing
OOPSLA's
Educators' Symposium
again this year, and we are leading off our day
Dave West and Pam Rostal's
Apprenticeship Agility in Academia,
which promises a firestorm of thinking about how to
teach CS -- and software development and agility and
... -- differently.
- I have used
Bill Wake's
Refactoring Workbook as a source of lab
exercises for my students. It is a great resource,
as is Bill's website. But it isn't a software
engineering textbook.
Why "take over a computer science department"? To
create a critical mass of agile-leaning faculty who
can support one another in restructuring curricula,
developing courses, writing textbook, experimenting
with teaching methods, and thinking Big Thoughts.
Being one among nine or 15 or 25 on a faculty means
a lot of hard work selling a new idea and a lot of
time isolated from the daily conversations that help
new ideas to form and grow.
OOPSLA
and
Agile 200x
and
SIGCSE
only come once a year, after all. And Cedar Falls,
Iowa, is far from everywhere when I need to have a
conversation on agile software development right
now. So is Raleigh, North Carolina, for that matter,
when
Laurie Williams
could really use the sort of interaction that the
MIT AI Lab
has been offering AI scientists for 40 years.
Accomplishing this takeover is an exercise left
to the reader. It is a slow process, if even
possible. But it can be done, when strong leaders
of departments and colleges set their minds and
resources to doing the job. It also requires a
dose of
luck.
-----