Coach's Reflections

Coach's Reflections

I. Enjoyable projects seem more likely to be successful. The developers will take pride in their work and quality will be high.

A variety of factors are related to the above goals of pride and enjoyment:

Social interaction makes for happy workers and a cohesive team. Computer programmers are not a social lot on the whole, but for everyone it is a fundamentally healthy exercise to communicate with others. Pair programming definitely involves communication, but it is perhaps more important in this regard to have the whole group present as much as possible (as opposed to pairs working in isolation), such that interaction is maximized and "team spirit" is fostered. The expectations of others becomes a powerful motivating force - for example, missing a meeting meets with the disapproval of the other members and the intense disappointment of the intended/assigned partner. This harnessing of "peer pressure" is generally inadvertent/subconscious but becomes a powerful technique. As a result, our meeting attendance was generally quite high and regular throughout the 2 semesters. By having everyone there at once, we could check on how other pairs were doing, what their intent was with such and such an interface or architecture, and also have light-hearted competitive comments floating about ("psh, this is Ed's code, must be full of bugs"). Having social events (Ed and Toby's parties, the awards banquet, etc) and bringing candy to the labs (even if it's technically not allowed) also improved the communication and relations between the group members. The benefits of snacks are actually mentioned several times in the XP book; Communal eating is an important social experience.

Small groups are preferable - it seems we were more effective this semester with approximately half the people. We got a much better feel for whom everybody was; it was more personal, informal, fun. Scheduling was easier to manage. People were more apt to take responsibility. Having more say in what goes on, more ownership of what one produces, leads to more pride and enjoyment derived from ones work.

Letting people do what they what they want to do (GUI, engine, etc) wherever possible is also fundamental to keeping developers happy, interested, and proud of their work.

Switching up people and tasks leads to higher team cohesion and better code. If two people are very similar, they will tend to work together whenever possible, creating a sub-clique within the group. When it comes to code, they will write with a specialized/particular style suited to them and likely leave out comments, since they understand their partner's thinking. By moving people about, and changing the things they are working on, lots of questions will be asked ("Why is this named this way? Wouldn't this be better instead?"), which will (hopefully) lead to comments addressing these concerns and clearer, more maintainable code overall.

II. Pacing affects morale and productivity.

Having a consistent schedule is preferable; for the most part, we had very steady progress. Schedules that shift necessarily introduce lazy bits and stressful bits; stress will cause frustration, laziness will lead to apathy. Also, if project velocity slips (like with a lot of refactoring and bug fixes) the work becomes a lot less interesting; new functionality is fun.

Scheduling is tough to manage. When we started a new application there were many different areas to investigate. However, as time went on we found that more and more often a group of stories that would be dependent on one critical story. Learning new technology often provided a painful lesson in this regard. We were adrift for quite a while last semester while trying find what JavaSound calls we needed, and which ones were in fact actually implemented in JDK1.3. XP further complicated the issue as the team tried not to look too far ahead - soon there was nothing else for most pairs to do while one pair, assigned to the critical story, tried to make sense of it all. We solved this by breaking the "everybody work together at once in parallel" format and serialized development for the troublesome parts. It worked.

Experience leads to tremendous gains in velocity. When it came to Composer, our second system, we already knew how to solve almost all of its problems. It took approximately 30 hours to implement functionality similar to what took over 100 hours in RiffDesigner, our first system. Reuse paid off in spades. The actual coding took very little time. Now we understand how some of those consultants (like Kent Beck of XP) can throw together accounting systems so fast.