COMP290-059 Report
Long Le

This report contains my impression and experience from the homework and
project. I am in team B. I work with Yuanxin Liu most of the times but
also pair with Phil Holman sometimes. The report contains my impression
and experiences with the three important features of XP: pair-programming,
test-first and favor working code over documentation.

1. Pair-programming

I have mixed experiences with pair-programming. Some of my programming
sessions were productive and satisfying. These were usually relatively
long sessions. Coincidentally, these sessions happened at the beginning
of the semester or after spring break when both my partner and I had
more time and were not stressed out. A few programming sessions were
not very productive and less satisfying. These sessions were usually
short because someone had to leave. Short programming sessions were
not productive because we usually spent the first thirty minutes picking
up what we left from the last programming session. In general, scheduling
for programming sessions was a constant battle throughout the semester
due to different constraints. (My partner and I had different class
times. I'd rather stay at school after classes for a few hours and
then go home to work in my apartment. On the other hand, my partner
usually goes home for dinner after class and then comes back later
in the evening.) I believe that pair-programming is more difficult
for students than for full-time professionals because of the scheduling
overhead.

Because all members of my team were Java beginners, pairing seemed
to help us learn the language faster. I was able to learn different
techniques in Java from my partners. Pair-programming was also very
productive when I paired with other members of the team who were
responsible for different parts of the project. In those sessions
I was able to learn the details of other team members' code and
shared with them the details of my pair's code. We were able to
find a few subtle bugs due to misinterpreting the design interfaces.
Pair-programming was also productive for us when one person was
actively coding while the other person looked up something that
we needed. However, when the programming task was easy and coding was
straightforward, the person not actively coding tended to get bored.

2. Test-first

I found test-first difficult. I usually start a programming project
by building small pieces of code and then gradually put them together.
Doing it that way, I usually do not think of "the big picture" up-front.
In order to do test-first, one has to think about "the big picture" and
its interface first. I found the test-first approach difficult and
unproductive when we had short programming sessions. In some cases,
we wrote the test cases in one session but then forgot what they were
supposed to do in the next session when we coded the program itself.
For complex and interactive objects, such as the GUI or the interface
to the data server, test-first was difficult and caused some overhead
in time and coding effort. I believe that this is partly because my
limited exposure to this approach. With more time and experience, I
would probably be able to benefit more from this approach.

3. Favor working code over documentation

All members in my team seemed to like this approach. In the first few
weeks of the project, we spent quite a fair amount of time discussing
alternative architectural desgins. Once we agreed on a desgin, we made
a few pictures and CRC cards. Fortunately, our design did not change
over time so that all team members had a reasonable understanding of
the design throughout the semester. Had the design changed during the
semester, it would have been harder for us to keep track of the
changes. Although we had two meetings a week for the entire team,
we usually missed one or two members in a meeting. It would probably
have been difficult for team members who were not present in a meeting
to understand changes in the design without detailed documentation.

In general, the approach of not emphasizing documentation worked
well for us and spared us some overhead. However, I believe that
some documentation would probably be necessary if the size of
the project or the team is larger, especially when not all team
members are working closely together.