TITLE: An Instant Recipe for Success -- for Students and Professors? AUTHOR: Eugene Wallingford DATE: November 10, 2004 10:46 AM DESC: Some meandering thoughts about applying an agile idea, short cycles, to the teaching of programming ----- BODY: I liked Incipient Thought's recipe for project success yesterday. It starts with T. J. Watson's well-known:
If you want to increase your success rate, double your failure rate.
... to which he adds a second part:
If you want to double your failure rate, all you have to do is halve your project length.
Then, winking, he points out that the second step may fail, because shorter projects may actually succeed more often! I think this is wonderful software development advice. As a teacher, I have been thinking about how to bring this idea to my courses and to my students. I always encourage my students to approach their course projects in this way: take lots of small steps doing the simplest thing possible, writing test code to verify success at each step, and refactoring frequently to improve their design. By taking small steps, they should feel confident that whatever they've done so far actually works. And, when it doesn't, they haven't gone too far astray, because they only worked on a little bit of specification. Debugging can often be localized to the most recently added code. Breaking a complex but unitary spec ("implement a program to play MasterMind") down into smaller stories is hard, especially for freshmen and sophomores. Even my upper division students sometimes have difficulty breaking requirements that are smaller but still too big into even smaller steps. In recent semesters, I've tried to help by writing my assignments as a list of small requirements or user stories. My second-semester students are currently implementing a simple text-based voice mail system, which I specified as a sequence of individual requirements. Sometimes, I even specify that we will grade assignments story-by-story and stop as soon as the program "fails" a story. This approach sounds great, but it is out of step with the student culture these days. Taking small steps, and especially refactoring, requires having a certain amount of time to go through the process, with some reflection at each step. Most students are inclined to start every project a few days or less before it's due, at which point they feel a need to "just do it". I've tried to encourage them not to postpone starting -- don't all professors face this problem? -- mostly to no avail. In my Agile Software Development course, we've been doing 2- and 3-week releases, and I think we've had some success with doing 3 week-long iterations, with full submission of the project, within each release. Even still, word in the class is that many folks start each iteration on a day or two or three before it's due. Maybe I should take the "recipe for project success" advice for them... I could assign two half-week assignments instead of a one-week assignment! Students would have twice as many opportunities to succeed, or to fail and learn. One of the downsides of this idea for me is grading. I don't like to grade and, while am usually (but not always!) timely in getting assignments back to students, I use enough mental energy grading for three courses as it is. I could automate more of the grading, using JUnit, say, to run tests against the code. But to the extent that I need to look at their code, this approach requires some new thinking about grading. One of the downsides of this idea for my students is the old time issue. With 15 hours of class and 30 hours at work and whatever time they spend in the rest of their lives, students have a tough time working steadily on each course throughout each week. Throw in exams and projects and presentations during special times in the semester, and the problem gets worse. But I can't shake the feeling that there is something deeply right about halving the size of every project. I may have to "just do it" myself and face whatever difficulties arise as they do. -----