Description of Methods

Early Days

In early January 2000, we began a series of weekly developer lunches, whose purpose is best described by quoting the e-mail one of the authors sent to the developer team.

Here is the basic idea I propose (subject to any modifications you guys feel are necessary of course): each week … someone will give a short (30 min), informal presentation of some piece of development work… . The presentation will be followed by group discussion of the material for another half an hour or so… . Loosely, these talks will hope to serve to: familiarize us all (esp. new people!) with the … architecture, help those giving the talks to come up with new ideas about how to solve architectural problems, and give us a chance to all talk shop together as a group. I imagine that more familiarity with what everyone does might also help when we try … [pair] programming … in the coming months… . You should try to show some real code … I emphasize that the point of these talks is to provide an opportunity for informal group discussion. Don't worry about making a powerpoint [sic] presentation … [Hohman2000]

When these meetings began, individual code ownership was the rule. Developers who had been around for a while were pushing for the adoption of XP techniques (such as unit testing and pair programming), and new developers had a hard time getting a handle on the already present code base. Frequent and regular code discussion was unanimously received as a good idea.

Our goals were similar to the broader goals of XP. We wanted to increase developer communication, both to increase morale and to aid in the dissemination of crucial knowledge about our software. We wanted to decrease individual code ownership. With a broader knowledge of the overall architecture, each of us would be less afraid to change "someone else's" code. We wanted to encourage more feedback within the group on design and coding decisions. And we wanted a lightweight solution. Formal presentations, arduous preparation, and prescribed meeting content were not going to be accepted by the group. We wanted to provide a forum for people to talk about issues they already found interesting.

First Light

The presentations were boring. They resulted in little actual feedback or informal discussion. The first half hour mercilessly took over the second half hour, because the second half hour was often awkwardly silent. After a couple of months, we had already discussed every part of the application, at least at a general level. We needed to make a change. The presentation format did not serve our goals. We needed to increase the emphasis on group discussion.

For a couple of meetings, we completely dropped any official agenda whatsoever and just had lunch together. Discussions arose naturally, often with different parts of the group discussing different topics. However, as often as not, these topics were not related to our work. There was little focus, and as a result, people began to lose interest and leave after they had eaten. A total lack of structure was not good either.

To re-create focus, we wrote a simple utility to pick one Java class at random from our source tree. The day before each meeting, we would pick a couple of classes and announce them to the group. At the meeting, we would project the code on the wall and discuss it. The idea was that, over time, we would have the opportunity to discuss code from all parts of the application while avoiding the arduous presentations.

By looking at the code one class at a time instead of one module at a time, we did not have to worry about running out of material after two months. Familiarity with a particular module could grow over time. In this format the person who had written that particular class still did a lot of the talking; however, we did notice that these meetings elicited more discussion than our original format.

Looking at code at the class level was more instructive than at the module level. At module granularity, a half-hour presentation can cover only the barest summary of the screens, the business logic, and the high-level architecture. Also, module presentations become less helpful and less interesting over the life of the project. As the code complexity of a module increases, the level of detail of a presentation must decrease.

At the class level, developers can see the similarities between modules. Many of our design patterns apply across the application, and a discussion of one module's use of a pattern can explain an entire layer of the application. Additionally, common utility classes can be hard to find or are implemented several times. Class-level discussions with all the developers present can reveal or prevent this kind of redundancy.

Which Brings Us to the Present

One day, a few months ago at the time of this writing, we were particularly distressed by the quality of code under discussion. So we decided to go ahead and make a few changes right then and there. We were not particularly careful, and there were no unit tests written for the class, so we ended up breaking the build. To restore the build to health, someone had to spend time throwing away the changes we made. However, we had learned something. Changing the code during the meeting made the discussion more interesting, perhaps because it forced people to think, and when people think, they tend to have more to say. We decided we were on to something, so we subsequently added structure to make the process safer and to improve on the idea. This process is still a work in progress, so here we present only our current view of its ideal execution.

Some period of time before the meeting the most effective period is a few days one or two classes are picked from the source tree for discussion. The person who runs the selection utility vetoes generated code and code destined to be removed soon from the source tree. The remaining results are then filtered based on level of interest, until there are one or two worthwhile candidates. Two people ("previewers") spend time together looking over these classes to make sure that there is enough material for an hour to an hour and a half's discussion. If there is not, they replace one of the selections. These two people also examine the unit test coverage and augment it if necessary. Finally, these two developers begin to brainstorm issues for discussion and possible refactorings. When the previewing phase is over, the two e-mail the code in the body of an e-mail message to all the developers on the team so they have a chance to glance over it themselves before the meeting.

The day of the meeting, the group meets in a closed room to avoid outside distractions. For the first 20 minutes or so, we eat and engage in social discussion. Then we begin.

Developers play different roles in the process. One role is the "driver," a person who types, compiles, and tests the code. Because we split into two groups, there are two drivers, one at each of a pair of laptops. We connect these laptops to projectors that display the code on opposite walls, giving each group some focus. We intend that all developers share the driver role (though this does not often occur; see the section Shortcomings). Second, the person or persons who originally wrote the code (or are familiar with it) take on a special role as "narrators," providing a description of the code, its purpose, and how it fits within the context of the rest of the application. Finally, the rest of the group participates by offering suggestions and feedback. These people form the mob, probably the most difficult role to play and the least understood of the three.

At the beginning, the narrator tells the group about the code and its history. Then we split into two groups, one at each laptop/projector, and discuss ideas for refactoring. We discuss with our hands as well, typing in our suggestions to communicate them more clearly. If the refactorings we agree on are simple enough, we carry them out. After about half an hour, or when we feel it is time, the two groups rejoin and discuss the changes each group has made. We then decide which to keep (if any) and which to throw away.