How I might teach using the Working Software Cycle

I've been out of teaching CS222 for several semesters now, but it still occupies my mind from time to time. This afternoon, I read the latest blog post by Ron Jeffries, which concludes with this:

There is a particular trick to the working software cycle, as I prefer to do it. It goes like this:

1. Start with working software. Ideally an “End Card”, ideally bug-free, but something that runs. Your existing legacy product will do if that’s all you’ve got.
2. Select a very simple next feature to do. No, that’s too big, even simpler. There you go.
3. Write an automated example that will fail until that feature works, and then succeed. If it requires more than one example, go back to #2.
4. Start programming: Run the example; add some code; run the example; every time the example runs, refine and improve the code a bit. When you’re satisfied with the example and code quality, that bit of feature is ready to ship.
5. You’re back to working software, with a new feature. Go to 2.

It made me think about the nine-week project in CS222 and its three three-week iterations. Students always struggle with getting a productive rhythm of software development. Next time I teach the course, I need to think about Jeffries' idea instead. That is, rather than ask them to write up plans for what to have done in three weeks, have them come up with something to have done, say, by tomorrow. Make the loop even tighter so they can both expose their misunderstanding about planning and feel what its like to be productive. (Of course, they should also start in a bug-free condition, which is also a challenge for them!)

Also, putting this together makes me think I should write more often. We're wrapping up the third week of the semester, and I feel like I've been thrashing. That usually means its time to schedule reflection and writing time and hold myself accountable to the schedule.