TITLE: Agile as Students, but Not Always as Programmers AUTHOR: Eugene Wallingford DATE: December 28, 2005 10:31 PM DESC: ----- BODY: I've noticed an interesting disconnect between student behavior when in the role of student and when in the role of software developer. When they are in the role of developer, students often fight the idea of XP's small steps: breaking tasks into small, estimable steps, writing a test for each small step, and then making sure the code passes the test before thinking about the next step. They want to think ahead, trust their experience and "intuition", write a lot of code -- and only then compile, run, and test the code. The testing is usually sloppy or, more charitably, incomplete -- at least in part because they are champing at the bit to move on to more code. Is this merely a matter of habit they have developed in past CS courses? Or have their years in the K-12 educational system encouraged them to rush headlong into every problem? Perhaps it is our natural human state. ... but when in the role of student, students tend behave much differently. They want feedback -- now. When they turn in an assignment, they want the graded result as soon as possible. I used to have a serious Grading Avoidance Problem, and all my students disliked it. Students who were otherwise quite happy with my course became cranky when I fell behind in returning assignments. Students who were unhappy with the course for other reasons, well, they became downright hostile. I'm mostly over this problem now, though I have to be alert not to backslide. Like a recovering addict, I have to face each day anew with resolve and humility. But I have a colleague for whom this issue is still a major problem, and it creates difficulties for him with his students. I can't blame students for wanting graded items back quickly. Those grades are the most reliable way they have of knowing where they stand in the course. Students can use this feedback to make all sorts of decisions about how and how much to study. (I do wish that more students paid more attention to the substantive feedback on their assignments and tried to use that information to improve their technique, to guide decisions about what to study.) So: students like frequent feedback to guide their studies. Many students also seem to prefer small, discrete, and detailed tasks to work on. This is especially true of students who are just learning to program, but I also see it in juniors or seniors. Many of these upper-division students do not seem to have developed confidence in their ability to solve even medium-sized problems. But when they are given a set of steps that has already been decomposed and ordered, they feel confidence enough to get the job done. They are industrious workers. Confessions of a Community College Dean captured my feeling about this feature of today's students when it said, "As a student, I would have been insulted by this approach. But they aren't me." I myself enjoy tackling big problems, bringing order to an unruly mass of competing concerns. Had I always been spoon-fed toy problems already broken into nearly trivial pieces, I wonder if I would have enjoyed computer science as much. I suspect I might have because, like many people who are attracted to CS, I like to create my own problems! So: students like to work on small, well-developed tasks whose boundaries they understand well. This, too, helps students focus their study. My net acquaintance Chad Orzel, a physicist at Union College, speculates on why students prefer to work in this way. The conventional wisdom is that working on many small, discrete tasks encourages them to keep up with their reading. But I think he is right when he takes this diagnosis one step further: This style of course helps students to compensate for poor time management skills. Larger, less well-defined units require students to figure out what the subtasks are, estimate how long each will take, and then actually do them all in a timely fashion. By structuring our courses as a set of smaller, discrete tasks, we do much of the preparatory work for our students. When students are first learning, this is good, but as they grow (or should be growing) we are merely reinforcing bad habits. It seems that we professors are enablers in a system of codependency. :-) Even in this regard, the relationship between student as software developer and student as student holds. As I have written before, software methodologies are self-help systems. Perhaps so are the ways we structure problems and lectures for our students. Once again, I can't blame students for preferring to work on small, discrete, well-defined tasks. Most people work better under these circumstances. Even those of us who love the challenge of tackling big problems usually succeed by taming the problem's complexity, reducing it to a system of smaller, independent, interacting components. That's what design is. Students need to learn how to design, too. When students are getting started, professors need to scaffold their work by doing much of the design for them. Then, as students increase in knowledge and skill, we need to pull the scaffolding away slowly and let students do more and more of their own design. It's easy for professors to fall into the habit of finely specifying student tasks. But in doing this thinking for them, we deny them the essential experience of decomposing tasks for themselves. Maybe we can leverage the agile-facing side of student behavior in helping them to develop agile habits as software developers. People aren't always able to change their behavior in one arena when they come to see that it is inconsistent with their behavior in another; we aren't wired that way. But knowing ourselves a little better is a good thing, and creates one more opportunity for our mind to grow. (I doubt going the other way would work very well. But it might take away some of the pressure to grade work quickly!) -----