TITLE: Becoming More Agile in Class
AUTHOR: Eugene Wallingford
DATE: May 14, 2014 4:52 PM
Days 2 and 3 of my Agile Software Development May term
course are now in the books. This year, I decided to move as
quickly as we could in the lab. Yesterday, the students did
their first pair-programming session, working for a little
over an hour on one of the industry standard exercises,
Conway's Game of Life.
Today, they did their first pair programming with unit tests,
using Bill Wake's
to implement the beginnings of a simple data model for
I always enjoy watching students write code and interacting
with them while they do it. The thing that jumped out to me
yesterday was just how much code some students write before
they ever think about compiling it, let alone testing it.
Another was how some students manage to get through a year
of programming-heavy CS courses without mastering their
basic tools: text editor, compiler, and language. It's hard
to work confidently when your tools feel uncomfortable in
There's not much I can do to help students develop greater
facility with their tools than give them lots of practice,
and we will do that. However, writing too much code before
testing even its syntactic correctness is a matter of
mindset and habit. So I opened today's session with a brief
discussion, and then showed them what I meant in the form of
a short bit of code I wrote yesterday while watching them.
Then I turned them loose with Wake's spreadsheet tests and
encouragement to help each other write simple code, compile
frequently even with short snippets, and run the tests as
often as their code compiles.
Today, we had an odd number of students in class, something
that's likely to be our standard condition this term, so
paired with one of the students on a spreadsheet. He wanted
to work in Haskell, and I was game. I refreshed my Haskell
memories a bit and even contributed some helpful bits of
code, in addition to meta-contributions on XP style.
The student is relatively new to the language, so he's still
developing the Haskell in his in his mind. There were times
we struggled because we were thinking of the problem in a
stateful way. As you surely know, that's not the best way
to work in Haskell. Our solutions were not always elegant,
but we did our best to get in the rhythm of writing tests,
writing code, and running.
As the period was coming to an end, our code had just passed
a test that had been challenging us. Almost simultaneously,
a student in another thrust his arms in the air as his pair's
code passed a challenging test, too, much deeper in the suite.
We all decided to declare victory and move on. We'll all
get better with practice.
Next up: refactoring, and tools to support it and automated