TITLE: The End Comes Quickly
AUTHOR: Eugene Wallingford
DATE: June 04, 2010 4:38 PM
DESC:
-----
BODY:
Teaching a 3-credit semester course in one month feels
like running on a treadmill that speeds up every
morning but never stops. Then the course is over,
almost without warning. It reminds me a little bit of
how the Christmas season felt to me when I was a child.
(I should be honest with myself. That's still how the
Christmas season feels to me, because I am still a kid.)
I've blogged about the course only twice since we dove
head-long into software development, on
TDD and incremental design
and on the
rare pleasure of pair programming
with students. Today, we wrapped up the second of two
week-long iterations. Here are the numbers, after we
originally estimated 60 units of work for the ideal
week:
- Iteration 1
- Budgeted work for week: 30 units.
- Actual work for week: 29.5 units.
- Story points delivered: 24 units.
- Iteration 2 (holiday-shortened)
- Budgeted work: 16 units.
- Actual work: 18 units.
- Story points delivered: 11 units.
I was reasonably happy with the amount of software the
team was able to deliver, given all the factors at play,
among them never having done XP beyond single practices
in small exercises, never having worked together before,
learning a new programming language, work schedules
that hampered the developers' ability to pair program
outside our scheduled class time, and working a domain
far beyond most of their experiences.
And that doesn't even mention what was perhaps the team's
biggest obstacle: me. I had never coached an undergrad
team in such an intense, focused setting before. In
three weeks, I learned a lot about how to write better
stories for a student team and how to coach students
better when they ran into problems in the trenches. I
hope that I would do a much better job as coach if we
were to start working on a second release on Monday.
As my good friend
Joe Bergin
told me in e-mail today, "Just being agile."
We did short retrospectives at the end of both iterations,
with the second melting into a retrospective on the
project as a whole. In general, the students seemed
satisfied with the progress they made in each iteration,
even when they still felt uncomfortable with some of the
XP practices (or remained downright skeptical). Most
thought that the foundation practices -- story selection,
pair programming, test-first programming, and continuous
integration -- worked well in both iterations.
When asked, "What could we improve?", many students gave
the same answers, because they recognized we were all
still learning. After the first iteration, several team
members were still uncomfortable with no
Big Design Up Front
(BDUF), and a couple thought that we might have avoided
needing to devote a day to refactoring if only we had
done more design at the beginning. I was skeptical,
though, and said so. If we had tried to design the system
at the beginning of the project, knowing what we knew
then, would we have had as good and as complete a
system as we had at the end of the iteration? No way.
We learned a lot building our first week's system, and
it prepared us for the design we did while refactoring.
I could be wrong, but I don't think so.
Most of the developers agreed that the team could be more
productive if they were not required to do all of their
programming in pairs. With a little guidance from me as
the coach, the team decided to loosen the restriction on
pairing as follows:
- If a pair completes a story together, one member of
the pair was permitted to work alone to refactor the
code they worked on. Honor code: the solo programmer
would not create new code, only refactor, and the
solo programmer would not make changes to the code
that stayed very far from what the pair understood
while working together.
- If a pair is nearly finished with a story, one member
of the pair was permitted to work alone to quickly
wrap up the story. Honor system: the programmer
would work for only 15-30 minutes alone; if it became
clear that the work remaining was more involved than
a quick wrap-up, the solo programmer stop immediately
and resume working with a partner at the next
opportunity.
- A team member may experiment alone, doing a quick
spike in an effort to understand some part of the
system. Honor system: the solo programmer would
commit none of the spike's code; upon returning to
the studio, the developer would collaborate on an
equal basis within the pair, sharing what was learned
via the spike but not ramming it through to the
mainline system without agreement and understanding
from the partner.
- At the next daily stand-up, any developer who had
worked solo since the previous class session would
explain all work done solo to the entire team.
After the second iteration, the team was happy with this
adaptation. Only three of the ten developers had worked
alone during the iteration, all doing work well within
the letter of the new rules and, even more important,
well within the spirit of the new rules, too. The rest
of the team was happy with the story wrap-up, the
refactoring, and the experimentation that had been done.
This seemed like a nice win for the group, as it was the
one chance to adapt the XP practices to its own needs,
and the modification worked well for them. Just being
agile!
As part of the course retrospective, I asked the students
whether they would have preferred working in a domain
they understood better, perhaps allowing them to focus
better on the new practices and new programming language.
Here are the notes I had made for myself before class,
to be shared after they had a chance to answer:
My thoughts on the domain:
I think it was essential that we work in a domain that
pushed you out of your comfort zone.
- It is hard enough to break habits at all, let alone
working on problem you already understand well --
or think you do.
- The benefits of agile approaches come in helping
the team to learn and to incorporate that learning
into the system.
- Not knowing the domain forced you to ask lots of
questions. That's how real projects work. That's
also the best way to work on any system, even ones
you think you already understand.
- There is a realness to reality. Choices matter.
When the user is a real person and is passionate
about the product, choices matter.
I was so impressed with the answers the students
gave. They covered nearly all of my points, sometimes
better than I did. One student identified the trade-off
between working in familiar and unfamiliar domains.
Another student pointed out that not knowing the domain
made the team slow down and think, which helped them
design better tests and code. Yet another remarked
that there probably was no domain that they all knew
equally well anyway. The comment that struck me as most
insightful was, roughly, "If we worked in a domain we
all understand, then we would probably all understand it
differently." That captures the problem of requirements
analysis as well as anything I've ever read in a software
engineering textbook.
It occurred to me while writing this that I should share
the list of readings I asked students to study. It's
nothing special, papers most people know about about,
but it might be a subset of all possible readings that
others might find useful. Sharing the list will also
make it possible for you to help me make the it better
for the next time I offer the course! I'll gather up
all of my links and post the list soon.
A few days ago, alumnus Wade Arnold
tweeted:
Sad to see May graduates in Computer Science applying
to do website design and updates. Seriously where did
the art of programming go?
The small and largely disconnected programming problems
that we assign students in most courses may engage some
students in the joy of programming, but I suspect that
these problems do not engage enough students deeply
enough. I remain convinced that courses like this one,
with a
real problem
explored more deeply and more broadly, with the student
developers more in control of what they do and how, is
one of the few things we can do in a traditional
university setting to help students grok what software
development is all about -- and why it can satisfy in
ways that other activities often cannot.
Next up on the teaching front: the compilers course.
But first, I turn my thoughts to sustainable pace and
look forward to breathing free for a few days.
-----