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: 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:
  1. 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.
  2. 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.

  3. 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. -----