TITLE: Agile Themes: Things Students Say
AUTHOR: Eugene Wallingford
DATE: December 22, 2009  2:57 PM
DESC: 
-----
BODY:
And now
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-12.html#e2009-12-21T07_37_07.htm">
   even the grading</A>
is done.  I enjoyed reading my students' answers to exam
questions about software engineering, especially agile
approaches.  Their views were shaped in part by things
I said in class, in part by things I asked them to read,
and in part by their own experiences writing code.  The
last of these included a small team project in class,
for which two teams adopted many XP practices.

Many people in the software industry have come to think
of agile development as implying an incomplete
specification.  A couple of students inferred this as
well, and so came to view one of the weaknesses of agile
approaches as a high risk that the team will go in
circles or, worse yet, produce an incomplete or
otherwise unacceptable system because they did not spend
enough time analyzing the problem.  Perhaps I can be
more careful in how I introduce requirements in the
context of agile development.

One exam question asked students to describe a key
relationship between refactoring and testing.  Several
students responded with a variation of "Clean code is
easier to test."  I am not sure whether this was simply
a guess, or this is what they think.  It's certainly
true that clean code is easier to test, and for teams
practicing more traditional software engineering
techniques this may be an important reason to refactor.
For teams that are writing tests first or even using
tests to drive development, this is not quite as
important the answer I was hoping for:  After you
refactor, you need to be able to run the test suite to
ensure that you have not broken any features.

Another person wrote an answer that was similar to the
one in the preceding paragraph, but I read it as
potentially more interesting:  "Sometimes you need to
refactor in order to test a feature well."  Perhaps
this answer was meant in the same way as "clean code
is easier to test".  It could mean something else,
though, related to an idea I mentioned last week,
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-12.html#e2009-12-16T21_51_33.htm">
   design for testability</A>.
In XP, refactoring and test-first programming work
together to generate the system's design.  The tests
drive additions to the design, and refactoring ensures
that the additions become part of a coherent whole.
Sometimes, you need to refactor in order to test well
a feature that you want to add in the next iteration.
If this is what the student meant, then I think he or
she picked up on something subtle that we didn't
discuss explicitly in class.

When asked what the hardest part of their project had
been and what the team had done in response to the
challenge, one student said, "We had difficulty writing
code, so we looked for ways to break the story into
parts."  Hurray!  I think this team got then idea.

A question near the end of the exam asked students
about Fred Brooks's
<A HREF="http://www.cs.uni.edu/~wallingf/teaching/172/resources/brooks-no-silver-bullet.pdf">
   No Silver Bullet paper</A>.
They read this paper early in the semester to get some
perspective on software engineering and wrote a short
essay about their thoughts on it.  After having worked
on a team project for ten weeks, I asked them to revisit
the paper's themes in light of their experience.  One
student wrote, "A good programmer is the best solution
to engineering software."

A lot of the teams seem to have come to a common
understanding that their design and programming skills
and those of their teammates were often the biggest
impediment to writing the software they envisioned.
If they take nothing from this course than the desire
and willingness to work hard to become better designers
and programmers, then we will have achieved an outcome
more important than anything try to measure with a
test.

I agree with Brooks and these students.  Good programmers
are the best solution to engineering software.  The trick
for us in computer science is how to grow, build, or find
great designers and programmers.
-----