Impressions on the XP process

Andrew Nashel
4/30/02


What worked
-----------

Pair programming - It was useful having a partner for some tasks,
particularly for looking up API docs, example code, etc.  Because we
were not very familiar with Java, these activities were very common.
Pair programming was less successful, but somewhat useful, for tasks
such as finding bugs and making sure syntax was correct.  We were
most productive doing pair programming using TWO computers, one for
development, and one as a lookup tool.  It was definitely more useful
than switching between the development IDE and a web browser, and even
better than having two monitors, because the two programmers could be
doing simultaneous things, which is normally a limitation of pair
programming techniques.  I think that this could be a promising area
for future study of XP technique.  Pair programming was also useful to
make sure both people stayed on task (instead of web surfing, email,
etc.).

Working code - The project seemed like it was exactly the right scale
for this sort of development.  In particular, the project was modular
enough so that we could always have SOMETHING running for a demo or
testing throughout the entire semester.  This is much better than a
project in which you can't be sure of success until everything is
done.  Without this carrot or working code, it would have been hard
to maintain interest as the semester progressed.

What didn't
-----------

Pair programming - Scheduling time for programming and meetings was
very difficult.  In a corporate setting (without many other classes
and projects) I imagine that it would be easier to find time to do
this if it was your full-time job.

Design meetings - All of the design meetings were usually discussion
and argument between 2-3 members of the team.  Even if present, the
other team members didn't really participate, and one even said that
it was too hard to have this many designers on a small project.  It
would have been more useful to designate a team leader, a lead
designer, a lead tester, and a lead 

Remote XP - I was at conference the last week before the project was
due and it was very hard to work with the other team members on coding
and documentation because I didn't have the infrastructure need for
remote pair development.  Instead of live, person-to-person pair
development, we had to occasionally revert to short-cycle individual
coding, in which I would code and then submit changes (usually a few
methods at most) to a local coder, who could then integrate them.
Compared to the majority of the coding, which was done as proper
pair-programming, this method was definitely more difficult.

Test-first - It was hard to test some of our modules because the
initial design did not take ease-of-testing in to account so much as
practicality of development.  As a result, many modules had too much
functionality to allow for thorough testing.  For example, many of
the user interface elements had string processing built into their
display methods.  This was mostly cause by the design of the GUI,
but it made it hard to test the output of the program.  Other elements
were modular enough so that they could be tested independently,
particularly the algorithms for the tracker