Developing Software in Groups

SE 430
Modified from Andrew Myers, Cornell University
by Dennis Mumaugh

Like most medium to large software projects, system architecture and high-level design are generally developed by groups of people of about the size of your project group. In fact, this size is nearly optimal for developing such projects -- if the group functions effectively . One of the goals of this class is to give you experience doing real software development; an important part of this experience is learning how to make a small group work.

It might be helpful to share a few lessons about working in groups that have been learned during a number of group projects in industry and academia. A group project like this will only be successful if every member of the group is doing useful work. The projects in this course are very difficult if not impossible for a single person to finish in the time allotted. So your goal is to organize the project development so that everyone is helping to make the project happen. The strategies suggested below all are largely common sense, but do think about whether you could improve your development process by applying them. I also recommend the classic The Mythical Man-Month, by Fred Brooks: a great source of ideas for and cautionary tales about group projects.

• Prepare for group meetings
  Group meetings are a very important part of a group development effort, and should be treated seriously by everyone. They can be an efficient way to communicate information efficiently to everyone in the group and to arrive at consensus about how to develop the project. However, it is also easy for group meetings to be unproductive because there is no concrete material to be discussed. Avoid vague discussions; when such a discussion seems to be happening, it is time for people to go off and think about the problem alone or in a subgroup. The best meetings are ones in which some members have worked up straw man proposals that the group can sink its teeth into and refine. The best approach is to delegate various issues to be figured out to different people in the group. These people then present a proposal or proposals, and the group discusses them and decides whether further off-line work is required or whether a solution has been arrived at and understood by all. This approach uses the energies of all of the group members effectively.
  
  Make sure meetings are productive. This means the moderator must make sure that people make productive contributions and do not devolve into long fruitless discussions that do not accomplish things. Use the custom of the Native Americans: the talking stick. Choose an object. Whoever holds the object may talk. When that person is done, the object is handed to the next person who may then talk. Also do not have side discussions.
• Rotate Group Function
  Groups function best when the administrative work is rotated among the members.  In small groups there needs to be a moderator and a recorder.  These functions should rotate on a regular basis.
  • Moderator The moderator's job is to keep the group focused on its progress and that the group doesn't get sidetracked into an unproductive discussion.
  • The moderator should make sure that the team keeps to the agenda
  • The moderator should confirm that pending Action Items are being resolved
  • At the end of the meeting, the moderator needs to assign new action items and get agreement on them
  • Recorder The recorders job is to keep track of what the group is doing and to document its actions, decisions and the design that results.
  • Keeps notes of the meetings
  • Makes sure the design documents are kept up to date
  • Keeps the project notebook with the latest version of the entire project.
• Document interfaces and  specifications
  When interfaces are defined, it is very important to document anything that is not obvious or that might be forgotten. A little effort spent writing down this kind of information pays off even on a single-person project; on a 3 or 4-person project the pay-off is tremendous.

  As a corollary, when you have to figure something out about some aspect that you or someone else has written, it should be written down in the design at the time you figure it out. This will prevent other people from having to waste time figuring it out too.

• Make sure your work is correct
Design Review: A very important process is arguing that a piece of the design is correct. Software is much more likely to work properly the first time if the person who writes the design must explain to someone else why it is that the design actually meets its requirements. If you can't tell whether a piece of the design is correct, it is probably because the specification the design is supposed to meet is not clear; in this case, you have learned that the specification needs refinement. This process of arguing for correctness saves immense time later, particularly when applied to problems that are tricky in any way. For completely trivial projects, it may be a waste of time.
Pilot/Co-pilot: A good trick for writing code and simultaneously doing this argument for correctness is the pilot/co-pilot or pair programming model. Two people work together with the co-pilot looking over the pilot's shoulder. They discuss interfaces and work up specifications together, and the pilot writes the design and has the burden of convincing the co-pilot that the design meets the specification. In cases where one member of the team is more familiar with the kind of design  involved, that person should be the co-pilot , not the pilot. The co-pilot can provide the higher-level guidance that his or her experience provides in the particular aspect being written. In 4-person groups, it often works well to split into two pilot-copilot subgroups. It is also useful to rotate who you work with in this arrangement -- everyone learns more that way. (For a nice article on this approach, see All I really need to know about pair programming I learned in kindergarten .)