After four weeks of 21.5 miles each -- pure coincidence -- as I recovered from bothersome bugs and painful hamstrings, I finally have had a real week of running. I ran 8.5 miles last Sunday, then put in 23 miles Monday through Friday. I ran easily, with a couple of speedy miles here and there, but mostly I was just happy to be on the road again.
This morning, I got together with an old friend, a teammate from my first marathon in Chicago who used to lead the superb children's theater program at the aforementioned local playhouse. He has since moved to Little Rock but was back in town for a short weekend. Both of us wanted to take it easy for our legs, so we headed out for a moderate 11.5 miler along the trails he used to run. What made the run toughest was the fact that it rained all morning, and we occasionally ran into a stiff headwind. But we ended with much the same feeling I had after Friday: feeling good, and happy to run without pain or other impediment. I can now get ready for an end-of-June half-marathon and a few 5Ks in the meantime, and he can taper into the Olathe Marathon, three weeks hence. Good luck, Greg!
I'm pleased to have a 34.5 mile week under my belt. I now hope that the last few weeks' relative rest have prepared my body for a fun summer of training.
My family and I watched the Tim Rice/Andrew Lloyd Webber rock opera "Jesus Christ Superstar" this weekend. Both of my daughters are into the theater, having performed a few times and seen most of the local children's theater's productions over the last many years. My older daughter vaguely remembers a stage production we saw a few years ago at an excellent local playhouse and wanted to see the show again. Our local library had two versions, the original 1973 movie and a 2000 London theatrical performance staged for television. Fortunately, we all like the music, so watching the same show on back-to-back nights was just fine.
Watching two versions so close in time really made the differences in tone, characterization, and staging stand out in great relief. The newer version took a European viewpoint, with the Romans as fascist/Nazi-like overlords and the common people seeking a revolution. The older version focused more on the personal struggles of the main characters -- Jesus, Mary, and especially Judas -- as they tried to come to grips with all that was happening around them.
For some reason, this brought to mind a short blog entry called Process as theatre written by Laurent Bossavit nearly two years ago. Laurent considers the differences between Extreme Programming as described in Kent Beck's original book and as practiced by Kent and others since, and compares them to the script of a play like "Hamlet". The script stays the same, but each staging makes its own work of art. The two videos I watched this weekend were at the same time both the same play and very different plays. (I was proud when my younger daughter recognized this and was able to express the two sides.)
Folks who feel compelled to follow every letter of every rule of a methodology often find themselves burning out and becoming disillusioned. Or, even when they are able to keep the faith, they find it difficult to bring others into the process, because those folks don't feel any need to be so limited.
On the other hand, we've all seen performances that take too many liberties with a script or story -- and instinctively feel that something is wrong. Similarly, we can't take too many liberties with XP or other methodologies before we are no longer working within their spirit. In XP, if we give up too many restrictions, we find that some of the remaining practices lose their effectiveness without the balancing effects of what we've removed.
As in so many things, striking the right balance between all or nothing is the key. But we start from a healthier place when we realize that a development process consists of both script and production, fixed and dynamic elements working together to create a whole.
I had forgotten that Laurent's blog entry refers to the book Artful Making. In an interesting confluence, I just this week asked our library to purchase a copy of this book so that I can read it over the summer. Now I'm even more eager.
Oh, and on the two versions of "Superstar": call me an old fogey, but I still love the 1973 movie. Larry Marshall as Simon Zealotes gives an awesome performance in his highlighted scene, and Josh Mostel delivers one of the all-time great comedic song-and-dance performances as King Herod. "Get out of my life!"
I am spending this day uncharacteristically, at the international conference Camouflage: art, science & popular culture. As I've written before, UNI is home to an internationally renown scholar of camouflage, Roy Behrens, who has organized this surprising event: a one-day conference that has attracted presenters and attendees from Europe, Australia, and all over the US, from art, architecture, photography, literature, theater, dance, music, and graphic arts, as well as a local mathematician and a local computer scientist, all to discuss "the art of hiding in plain sight". I am an outlier in every session, but I'm having fun.
Marvin Bell, the Flannery O'Connor Professor of Letters at the University of Iowa and the state's first Poet Laureate, opened the day with some remarks and a first reading of a new poem in his Dead Man Walking series. First, he chuckled over his favorite titles from the conference program: "The Case of the Disappearing Student" and "Photographic Prevarications" among them. My talk's title, "NUMB3RS Meets The Da Vinci Code: Information Masquerading as Art", wasn't on his list, but that may be because my talk was opposite his favorite title. It is worthy of enshrinement with the all-time great MLA titles: "Art and the Blind: An Unorthodox Phallic Cultural Find". His remarks considered the ways in which poetry is like camouflage, how it uses a common vocabulary but requires a second look in order to see what is there.
Thankfully, my talk came almost first thing in the day, as one of three talks kicking of the day's three parallel sessions. As you might guess, this was an unusual audience for me to speak to, a melange of artistic folks, with not a techie among them. What interests them about steganography in digital images?
The talk went well. I had prepared much more than I could use in thirty minutes, but that gave me a freedom to let the talk grow naturally from plentiful raw material. I may write more about the content of my presentation later, but what is most on my mind right now are the reactions of the audience, especially in response to this comment I made near the end: "But of what interest can this be to an artist?" As I was packing up, a Los Angeles architect and artist asked about 3D steganography -- how one might hide one building inside another, either digitally or in real space. A writer asked me about hypertext and the ability to reveal different message to different readers depending on their context. Later, another artist/architect told me that what excited her most about my talk was simply knowing that something like this exists -- the idea had sparked her thoughts on military camouflage. Finally, on the way to lunch, two artists stopped me to say "Great talk! We could have listened to you for another 30 minutes, or even an hour." What a stroke to my ego.
For me, perhaps the best part of this is to know that I am not such an oddball, that the arts are populated by kindred spirits who see inspiration in computer science much as I see it in the arts. This has been my first "public outreach" sort of talk in a long time, but the experience encourages me that we can share the thrill with everyone -- and then watch for the sparks of inspiration to create the fires of new ideas in other disciplines.
I've done my best today to attend presentations from as many different media as possible: so far, poetry, architecture, literary translition (yes, that's an 'i'), photography, dance, painting, and neurobiology; coming up, language, music, and math. The talks have been of mixed interest and value to me, but I suppose that's not much different from most computer science conferences.
Some thoughts that stood out or occurred to me:
Do computer science courses do this to students?
I think that introductory computer science courses disorient our students in a similar way. They are drowned in new language, new practices, and too often 'just programming'. How can we help them to see, "So This is Computer Science!"?
Okay, so I'm crazy, but how could I turn this into a programming etude?
This is an indulgent day for me, frankly. I have a list of 500 hundred things to do for my job -- literally -- plus a hefty list for home. My daughters had soccer games, piano lessons, and babysitting today, so my wife spent a bunch of time running shuttle service solo. It's a privilege to spend an entire day, 8:00 AM-8:30 PM, on an interdisciplinary topic with little or no direct relationship to computer science. It's a good thing I don't have to worry about getting tenure.
numbers in patterns.
Words in patterns entice the mind.
Each poem is six lines, twenty syllables. You should see a familiar pattern.
The syllables of a Fib follow the Fibonacci sequence. And, for my own amusement, the last three paragraphs extend the pattern.
Don't I have something better to do, like prepare slides for my talk on steganography at this weekend's Camouflage Conference at UNI? Of course! But sometimes the mind chooses its own direction. (Count the syllables!)
Back in 1998, the still relatively new Hillside Group spun off a third conference in its "Pattern Languages of Programs" series, the mysteriously-named ChiliPLoP. The name is a double entendre, one part based in the southwestern US culture and cuisine that are spicy by national standards, and one part based in the conference's intent to bring together patterns folks working intensely in groups on "hot topics" of interest. Since the beginning, I have been a regular, meaning that each spring I travel to Arizona for a great three or four days working on patterns and interacting with the some of the most interesting folks I've ever met.
The first three years of ChiliPLoP were held in the rural area 50 miles northwest of Phoenix, at the wonderful Merv Griffin Wickenburg Inn and Dude Ranch. At the time I was still just a casual runner, so I jogged about the compound on gravel and sandy paths for 20-30 minutes at a time. In 2000, Merv donated the ranch to a charity, for use as a camp for wayward boys, and ChiliPLoP had to surrender its great Western luxury and find a new home.
Since 2001, ChiliPLoP has been in Carefree, northeast of Phoenix, at the Spirit in the Desert retreat center. That may not sound exciting, but it has been a great place to hold a working conference -- quiet, with lots of open space and kitchen area, autonomy, and a great staff. And, more to the point of this article, Carefree offers great running.
Carefree is a young town of about 3000 people up the road from Scottsdale and neighboring the older and larger community of Cave Creek. It's basically a tourist community, with restaurants, trinket shops, and art galleries. Many of its residents live in expensive homes in the land that rings the small center center.
When I run in Carefree, I go for three different kinds of outing.
My shorter runs tend to be in and around the town area. There isn't really much town, but the streets in the vicinity of the retreat center wind around, folding back in on each other, making it possible to run for a few minutes without ever running in quite the same place. Just south and east of town, the roads are like the country roads I remember in rural Indiana, with a few houses, narrow streets with no shoulders, and little traffic. I can easily piece together a 5-6 mile run by aimlessly wandering streets with names like Bloody Basin, Nonchalant, Long Rifle, Sidewinder, and Breathless.
The Outlying Areas
Farther to the east but especially to the north, I get into the "wild". There are still homes to be found, but they are fewer and harder to see, hidden atop hills and behind the desert's flora. These runs are much hillier, with a few big hills and many, many smaller but still significant rises and falls. I like to run early, and I often see javelinas and coyotes out -- the javelinas in packs, sometimes near the roads, and the coyotes alone or in pairs, scouting the ridges above the roads.
My favorite runs are north of town. I take Tranquil Trail north across Cave Creek Road and follow streets where they lead me. Occasionally I hit a dead end at the top of a steep incline, so I double back to the latest choice I made and make another. We all study about backtracking algorithms in our CS courses, and I've tried them all as I explore this area. I don't worry much about distance, because the hills change my speed profile so much; I just run for an hour, or ninety minutes, being sure to stop moving farther from town near the 2/3 mark. One run of this sort is the strength work-out I need for a week, replacing any speed work-out or hills I might do at home.
When I started running more miles in 2002, I began to hear a siren call: Black Mountain. This 3700-foot mountain lies east of Carefree and south of Cave Creek, and it dominates the skyline as I look out the window of my room at the retreat center. I was running more mileage, and now I realized that something was possible that before had never even been conceivable. The mountain called to me: run all the way around me.
That first year, I mostly wandered the retreat center's tranquil grounds and imagined. But I looked at local tourism maps and guessed that the roads around the mountain's base form a loop of 10 miles or less, and the call got stronger.
I also could not resist one other attraction of this run. The south border of mountain is called Carefree Highway, and all I could of was the old Gordon Lightfoot song, which I loved, and the prospect of telling my friends that I had run down Carefree Highway.
In 2003, I did. The run convinced me that the loop -- beginning on the northeast side of the mountain at the corner of Tom Darlington Highway and Cave Creek Road, counterclockwise on Cave Creek around the north and west perimeters to Carefree Highway, east back to Tom Darlington, and finally north again to Cave Creek -- was only 8.5 or 9 miles. With a half mile or so to and from the starting point, I figure this run is in the 9 to 9.5-mile range. It has plenty of rise and fall, but not dramatic changes in elevation; the inclines and declines are long and gradual.
This run is now a ritual of my ChiliPLoP visits. The roads of this route are two and four lanes and are the major roads into and out of Cave Creek and Carefree. So they are busy. That, coupled with the fact that I do have work to do at the conference, means that I usually start early -- no later than 5:30 AM, certainly, and as early as 4:15 AM. I start in darkness and end in light, much like the conference itself. Indeed, I have seen some remarkable sunrises as I come around the southwest corner of the mountain and turn east, when the sun seems to come alive all at once as the mountain no longer blots out my eastern vista.
I hope no one is listening, because I often talk to the mountain. The first year, I spoke to it as a motivational device, because I'd never run such a hilly 9-miler. Now, I speak to it as an old friend, a partner that has seen me go from novice runner to old hand. Yesterday morning, I thanked Black Mountain for another glorious run. Unlike Coleridge's Ancient Mariner who bore the burden of guilt for slaying the albatross, I grew with the mountain and became its companion.
The software patterns movement is changing, as patterns and the OO software development that engendered it become a part of the discipline's mainstream, and I don't know how much longer conferences like ChiliPLoP will continue to exist as viable entities. I can only hope that it lasts for a while longer. I need my annual excuse to run in its world.
While doing a little reading to end what has been a long week at the office, I ran across a pointer to Steve Yegge's old piece, Tour de Babel, which has recently been touched up. This is the third time now that Yegge's writing has come recommended to me, and I've enjoyed the recommended article each time. That means I need to add his blog to my newsreader.
This was my favorite quote from the article, a perfect thought with which to end the week:
Familiarity breeds contempt in most cases, but not with computer languages. You have to become an expert with a better language before you can start to have contempt for the one you are most familiar with.
So if you don't like what I am saying about C++, go become an expert at a better language (I recommend Lisp), and then you'll be armed to disagree with me. You won't, though. I'll have tricked you. You won't like C++ anymore...
I know that this is the sort of inflammatory, holier-than-thou pronouncement that smug Lisp weenies make all the time, and that it doesn't do anything to move a language discussion forward. But from all I've read by Steve, he isn't a language bigot at all but someone who seems to like lots of languages for different virtues. He even speaks kindly of C++ and Java when they are discussed in certain contexts.
Even though I know I shouldn't like these sorts of statements, or give them the bully pulpit of my ever-so-popular blog, I give in to the urge. They make me smile.
I myself am not a smug Lisp weenie. However, if you replaced "Lisp" with "Smalltalk" or "Scheme" in the quoted paragraph, I would be smiling even wider. (And if you don't know why replacing "Lisp" with "Scheme" in that sentence would be a huge deal to a large number of Lisp devotees, well, then you just don't understand anything at all about smug Lisp weenies!)
Pardon me this guilty pleasure.
The SIGCSE mailing list has been alive this week with a thread that started with pseudocode, moved to flowcharts, and eventually saddened a lot of readers. At the center of the thread is the age-old tension among CS educators that conflates debates between bottom-up and top-down, low-level and high-level, machine versus abstraction, and "the fundamentals" with "the latest trends". I don't mean to rehash the whole thread here, but I do want to share my favorite line in the discussion.
Suffice to say: Someone announced an interest in introducing programming via a few weeks of working in pseudocode, which would allow students to focus on algorithms without the distraction of compilers. He asked for advice on tools and resources. A group of folks reported having had success with a similar idea, only using flowchart tools. Others reported the advantages of lightweight assembly-language style simulators. The discussion became a lovefest for the lowest-level details in CS1.
My friend and colleague Joe Bergin, occasionally quoted here, saw where this was going. He eventually sent an impassioned and respectful message to the SIGCSE list, imploring folks to look forward and not backwards. In a message sent to a few of us who are preparing for next week's ChiliPLoP 2006 conference, he wrote what became the closing salvo in his response.
The pseudocode thread on the SIGCSE list is incredibly depressing. ... Why not plugboards early? Why not electromechanical relays early? Why not abacus early?
An "abacus-early" curriculum. Now, there's the fundamentals of computing! Who needs "objects first", "objects early", "procedures early", "structured programming", ...? Assignment statements and for-loops are johnny-come-latelys to the game. Code? Pshaw. Let's get back to the real basics.
Joe, you are my hero.
(Of course, I am being facetious. We all know that computing reached its zenith when C sprang forth as whole cloth from Bell Labs.)
Am I too young to be an old fogey tired of the same old discussions? Am I too young to be a guy who likes to learn new things and help students do the same?
I can say that I was happy to see that Joe's message pulled a couple of folks out of the shadows to say what really matters: that we need to share with students the awesome beauty and power of computing, to help them master this new way of thinking that is changing the world as we live. All the rest is details.
Well, if there are different kinds of pain, which kind of pain am I feeling today?
After a few days on hold, my hamstrings felt okay by Tuesday night, so I headed out for a short (3-mile), easy run on Wednesday morning. My legs were sore, but I felt no pain in my hamstrings!
I ran 5 miles yesterday. After a tentative first mile, I accelerated for the first time in over a week. I held a pace in the 8:45 minutes/mile range -- not fast, by any means, but much faster than anything I could manage the week before. Again, sore legs, but no pain.
Today's 5-miler was a bit slower, but just because my muscles are a little out of shape even after a the short lay-off. But I feel the good kind of sore. I'm getting better.
I plan to take it relatively easy in Carefree next week while at ChiliPLoP'06, and then -- if the legs still feel good -- begin preparation for a half-marathon at the end of June.
The other night at dinner, I was telling my family about the state of my legs after my most recent run, and I said, "My legs don't hurt, but my hamstrings are sore." My younger daughter, Ellen, responded, "Um, Dad, your hamstring is part of your leg." And I was caught. Fun was had by all at my expense.
Of course, I was talking about different kinds of pain. I've been thinking about different kinds of pain a lot lately. As I mentioned in my last post, I have been having trouble with my hamstrings. I have not suffered from a running injury in the three-plus years since I developed a larger commitment to running, but I've felt plenty of pain. Whenever we push our bodies farther than they are used to going, they tend to talk back to us in the form of muscle soreness and maybe even a little joint soreness. That pain is a natural part of the growth process, and if we can't handle that sort of pain then we can't get better -- more speed, more stamina. Oh, I suppose that we might be able to get better slowly, but so slowly that it wouldn't be any fun. Even still, we runners have to listen to their bodies and let them tell us when to lighten up. I live with this sort of pain periodically, as it is a part of the fun.
This is a different sort of pain than the pain we feel when something is wrong with the body. Last week, my hamstrings hurt. Walking was painful at times, and going upstairs was torturous. This is the kind of pain that evolved to tell us our bodies are broken in a way that wasn't helping. Listening to this kind of pain is crucial, because unheeded the underlying cause can debilitate us. When we feel this kind of pain, we need to "get better", not get "better".
This week I have been talking with students in my compilers class. They are feeling a kind of pain -- the pain of a large project, larger than they've ever worked on, that involves real content. If they design the parsing table incorrectly, or implement the table-driven parsing algorithm incorrectly, then their programs won't work. To their credit, they all see this sort of pain as useful, the sort of pain you feel when you are getting better. "I've learned more about Java programming and object-oriented design than I've ever learned before." They realize that, in this case, less pain would be worse, not better. Still, I feel for them, because I recall what those first few experiences with non-trivial programs felt like.
For my agile software development readers: I know that I haven't written much about agile in a while, but I can say that many of my students are also experiencing the pain that comes from not using the agile practices that they know about. Taking small steps, using unit tests, and getting as much feedback from their code as often as possible -- all would make their lives better. There is nothing like trying to debug several hundred lines of tightly-coupled code for the first time and needing to track down why Rule 42 of 200 doesn't seem to be firing at the right time!
This is also advising time, as students begin to register for fall courses. Sometimes, the best course for a student will be painful, because it will stretch him or her in a way that the mind is not used to. But that may be just what the student needs to get over the hump and become a top-notch computer scientist!
These encounters with various kinds of pain remind me of an essay by Kathy Sierra from a month or so ago. One of her central points is that, to become really good at a task, you must practice the parts that you are weakest at -- you have to choose pain. Most of us prefer to practice that with which we are already comfortable, but then we don't stretch our (programming, piano-playing, golfing, running) muscles enough to grow. I suspect that it's even worse than that, that by repeatedly practicing skills we are already good at we drive our muscles into a rut that leaves us worse, not better. I see that happen in my running every so often, and it probably happens to my programming, too.
But is all the psychic pain we feel when taking a compilers course or learning to program a good sign? Probably not. We do need to choose tasks to master for which we are well suited, that we like enough to work on at all. If you really have no affinity for abstraction and problem solving, then computer science probably isn't for you. You'll not like doing it, no matter how expert you become. But after selecting a task that you can be good at or otherwise interested in, you after to be ready to take on the growing pains that come with mastering it. Indeed, you have to seek out the things you aren't good at and whip them. (*)
I hope you have the chance to feel the right kind of pain soon. But not for long -- be sure to move on to the fun of getting better as soon as possible.
(*) I do offer one caveat, though. It is too easy to tell ourselves, "Oh, I don't like that" as a way to avoid finding out whether we might like something enough in practice. I don't know how many times people have said, upon hearing that I ran 20 miles that morning, "Oh, I can't run long distances" or "I don't like to run at all". I usually smile politely, but sometimes I'll let them know that I didn't know I liked it until I had done it for a while. I used to make jovial fun of my friends who ran. Then I did a little for ulterior reasons and thought, "Hmmm...", and then I did more and more. Sometimes we need to try something out for a while just to know it well enough to judge it.
Since I took up training for half-marathons and marathons back in 2003, the first Monday in April has been the traditional "opening day" for my training season. I usually run the Sturgis Falls Half Marathon, which is part of our major city festival. The race is always the last Sunday in June, and starting at the beginning of April gives me almost three months to prepare specifically for racing a good half. Today is opening day for 2006, with a race date of June 25. Countdown: 12 weeks.
My training is on hold for a day or two, though. A couple of week ago, I started feeling a little soreness in my hamstrings. I ran normally that week, in hopes that it would pass. It didn't, and got worse instead. So last week I cut my mileage way back and further ran very, very easily -- no speed, no acceleration, no hills, just short, slow, easy miles. I may never have run a 10-minute mile before (well, except perhaps while struggling to finish my last marathon.)
By last Friday, my hamstrings hurt even more, so I decided to take drastic measures: I skipped my Sunday run. Believe it or not, I had never had to cancel a run for injury! The 48-hour break helped my right hamstring, but the left still felt a little tender. So I chose not to run today, either. The left hamstring is feeling better today, and I may take tomorrow off, too. With hamstrings, it is safer to be a little more cautious and let those boys heal well than to foolhardily race off too soon. I have friends who have suffered through full seasons of hamstring pain. They affect walking and sitting, and then you can't run at all. A day or too of rest is a price worth paying when a plausible alternative is weeks or months on the shelf.
Not that I have ever been one to be cautious when it comes to canceling runs. I usually run through things and let my body win. But I've probably been fortunate not to have the sort of injuries that made that strategy impossible.
I didn't suffer any particular injury here, so I guess this is what athletes call an "overuse injury". I've been running about 38-41 miles per week this winter, and between miles and shoes and a little speed, I may just have overdone things a bit. And maybe I'm getting a little older, and this is my body's way of reminding me who's in charge...
So, my half-marathon training may not start until Wednesday morning. Another day of rest, then a short, easy jog, then -- if all feels okay -- a few easy miles for this week. Eleven weeks is plenty of time to prepare for a half, and I want to enjoy it.
Besides, next week I spend a few days in Carefree, Arizona, and I want to enjoy the trails, hills, coyotes, and javelinas!
A couple of days ago I was tracking down an article that had been mentioned in a thread on the SIGCSE mailing list and ran across Rich Pattis's paper, "A Philosophy and Example of CS-1 Programming Projects" (pdf), from the February 1990 issue of the ACM SIGCSE Bulletin. Having recently written about Rich's work, I couldn't resist taking it home for a weekend read. Not surprisingly, I am glad I did.
On its face, this paper is relatively unassuming. It describes a project that he assigns to his CS 1 students as an example of how he thinks about projects. Reading it reminded me of the sort of simplicity I associate with Ward Cunningham. But I was amazed to see Rich talk about two ideas that have been discussed everywhere in CS education for the last few years.
Section 2 is titled "Using Packages in Projects". It lays out Rich's philosophy of projects, which consists of at least two key ideas:
Long-time Knowing and Doing readers know that this topic is often on my mind.
Anyone who has been trying to teach OOP faithfully in the first year recognizes this as a central theme.
Then, Section 5 describes the software "methodology" that Rich taught his students, which he called Stepwise Enhancement. If you read this paper today, you'll say to yourself, wait a minute, that's XP! Consider these fragments:
... students first must reduce the program specifications to a minimum, concentrating on their main structural features and ignoring all the complicated details that will make the program difficult to write. Then they design, implement, and test ... a complete version of the program that meets these simplest specifications.
The students continue repeating this process - at each stage enhancing the specifications and writing an enhanced program that meets these new specifications - until they have solved the complete problem described in the original specifications.
At every stage they are making small additions or modifications to an already correct (for the simplified specifications) program.
Fundamentally the stepwise-enhancement technique is useful because it is easier to design, implement, and test a series of increasingly more sophisticated complete programs than it is to attempt writing one large program that solves the original problem specifications at the outset...
This technique also allows students to test their original ideas on how to solve the main features of the problem in a simple program first. They receive feedback, at very short intervals, that tells them whether or not they are on the correct path to a solution program. ... such feedback is critical for students who are learning in parallel the language features and how to use these features when writing programs.
As students gain more programming experience, it will become more obvious to them what are the important structural features in specifications and what are the complicated details....
At the end of each stage, students should have a working program that they can test on the computer to ensure that it correctly solves the problem at that stage.... If they do not finish a program, they still should have a running program that solves a simpler problem.
I could quote more, but there is something known as "fair use". Besides, you should just go read the paper, which you can find in the ACM Digital Library. Bonus points to the reader who finds the most XP values and practices in this three quarters of a page of text! Plus, you get a sense of the practical experience Rich had gained while teaching this style of development.
I haven't even mentioned the sample project, a simple cardioverter-defibrillator. Now that I am on deck to teach our CS1 course, I have a great place to adapt and use this project when teaching about selection and repetition. After reading this paper, I realize how much fun I will have going back to my old CS1 notes, ten years old and older, and recalling how I was teaching elementary patterns and little bits of agile methods back then. I hope that I do an even better job of teaching CS1 after my experiences from the last decade.
Rich wrote this paper almost 17 years ago -- which should remind all of us who are trying to do new things that there isn't much that is all that new. We have a lot to learn from what folks were doing before our new ideas came along. You just have to know where to look. Considering that guys like Rich and the folks he hangs out with are usually thinking about big ideas and how they might help us improve CS education before anyone else, any CS educator would do well to keep an eye on what they were doing a few years ago. And whatever they are doing right now, well, we'll probably all be doing that in a few years.