TITLE: Course Notes from the Treadmill
AUTHOR: Eugene Wallingford
DATE: May 17, 2010 5:19 PM
Teaching a course two hours a day , especially a course that
is essentially new in this incarnation, feels like running
on ice. I'm enjoying every day, but tomorrow becomes today
way too fast!
At the end of last week, I began to feel the effects of
compressing a 3-credit course into four weeks. At the end
of Week 1, we are a quarter of the way through the course.
But one week is not really enough time for all these new
ideas to soak into a student's brain or fingertips. TDD,
refactoring, pairing, .... Ruby, an IDE, a VCS, ... Our
brains take time to adjust. The students are doing
remarkably well under the conditions, but some of them are
feeling the rush of days, too.
I most noticed the compression in my conflicting desires to
do stuff and to talk more about stuff before doing anything
big. Most professors tend to err on the side of talking
more, but that isn't the best way to learn most disciplines.
I decided that we had seen enough background on XP and that
students had practiced enough on small exercises such as
the spreadsheet TDD challenge
refactoring Fowler's code,
It was time to start building software, and learn as we go.
So today we played the Planning Game and put ourselves in
position to write Line 1 of code tomorrow.
It's been interesting talking to students about XP's
practices. Pairing seemed odd to many of them at first, but
they seem to have taken to it quickly. They are social
beings. Refactoring seems like the Right Thing To Do to
many of them, but in practice it is hard. Using a tool
like Reek to identify some smells and an IDE like RubyMine
to perform some of the refactoring will help, but RubyMine
does not yet implement enough different refactorings to
really dampen their fear of breaking code.
TDD is causing a couple of programmers fits, because it
inverts how they think about coding. When it comes time
to write tests for the app they are building -- no longer
a small exercise in their minds -- I expect us to struggle
as we think about simple design steps. I hope, though,
that this practice will get them over the hump to see how
writing tests early or first can really affect how we
think about our code.
I am still surprised when developers bemoan their inability
to deliver working code and then balk so mightily at a
practice that could help them in a major way. But, as we
old habits die hard.
When the mind is ready, change can happen. All we can
hope for in a course is to try to be in position for
change to occur whenever the mind becomes ready.