Fundamentals of Computer Science II (CSC-152 99S)


Clif's Project Comments

Clif Flynt asked his students to turn in their one-page summaries a few days before mine were expected to do so. These are his observations on the project experiences, with reflections from his own experiences in industry. There are also a few comments from Sam Rebelsky [in square braces].

Some of the telling points from individual analysis

1. The recurring theme is lack of communication, or difficulty of communication between group members and between groups.

It would be useful to have a set of time after the designs are stable for each group to describe their design so that the other groups are aware of the what they have to work with.

2. Most groups developed a group leader, but while it was recognized within a group that one person was coordinating the group, it wasn't always obvious to the other groups who they could contact for information.

Defining a group ``information-holder'' would be good in future projects.

That group member would be responsible for knowing their projects design, status, and forwarding change requests to the other group members.

3. The de-facto group leader in most groups was not comfortable with the role they assumed, they just sort of fell into the vacuum.

This is common. I've seldom been on projects in which the official group leader was also the de-facto group leader. Almost always someone takes the responsibility for knowing what everyone is doing and what the current status is and that person becomes the project leader.

In terms of student projects, it might be worthwhile to have each group elect an official leader after the design phase. Being recognized as the person who holds the information can make the position easier to deal with.

As an aside, when I've held this position, I don't call myself the group leader (which has control and decision-by-fiat connotations) but rather group coordinator, reflecting that my role is to know what's going on, and maintain the consensus on the design.

4. Most groups noted that much of their design work was done as they were coding and realized that they hadn't accounted for some requirement in their initial design.

A longer design period with a formal design required before coding, and report on the design to the other groups might help this.

5. Most groups worked all-together to get the advantage of the group members different strengths (either conceptualization skills or java programming skills) and to gain from having multiple eyes examining the code as it's written.

It was noted that while this let the group progress faster on one piece of code, it did not get code done N times faster (N being the number of people watching the code being written.)

Given a longer design phase, the project can be split into multiple parts, and team members can each work on a separate set of code. If group meetings for code-work are scheduled, the team members can be working on their own part of the project, and still be available to provide clean-eyes and sounding boards for the other team members.

A common industry technique is to hold a code-review, in which people examine each others code. The best technique I've heard of for this is that code is distributed before the meeting, and people write their comments. Only written comments will be addressed during the meeting. (This avoids the problem of people coming to a meeting to have every line of a program explained to them, instead of reading the code before time.)

[At this stage of your careers, I'm happy if you find it best to work together on each piece of code. While an elegant and appropriate design can make it easier to split up work, my experience from student groups is that there is often too much coordination necessary, and it's easier for a ``weak link'' to let the whole gropu down.]

6. Every group reports problems in varying degree with people who for one reason or another were late to (or missed) meetings. In the most disfunctional groups, meeting times were decided at the last minute, and the announcement was handled in an ad-hoc, rumor-mill fashion.

Groups might establish a rule that meetings must be announced via E-Mail at least 24 hours before they occur. Or the first item of business at each meeting is to establish the time and date for the next meeting.

Once a robust design has been completed, the need for full group meetings is reduced. [But certainly not eliminated.]

[For those groups that like to code together, it should be possible for subgroups to get together and make some progress. As long as there is some continuity (i.e., one person) who attends each progressive set of meetings and you document what you're doing, you can pass the torch from subgroup to subgroup.]

7. As a learning experience, it was noted that people learned a lot about the part of the project that they worked on, but did not gain any experience on the other phases.

Individual group progress reports might help to distribute some of the knowlege that people are gaining about their part of the project.

[This is also a common experience in large projects, and an appropriate one. The goal of splitting up the project is that you only need to understand what the other groups' parts will do, not how they do it.]

[I had also intended the large group discussions to provide some more information about the other parts. This was more difficult because two classes (Rebelsky's and Flynt's) were collaborating, but some people were supposed to be sharing information between the classes. I had also expected that you'd end up talking between groups as you started to coordinate your classes.]

8. Despite Karl Marx's dreams, ``From each according to his abilities'' means that some group members did more than their share of the work, and other group members either felt left out or were resented by the folks who did the work.

One of the difficulties in going from small to large scale projects is that in the small/medium projects a single designer/implementor can hold the entire design in his mind, and the only thing they need to convey at the end is a final product.

In a collaborative effort, the person who best understands how something needs to be done has to make that knowledge available to the other team members. If they simply do the task, then nobody else will know how to work with that part of the project, and will wander off to work on some other assignment.

On the flip side, when a team member feels disenfranchised they need to take the initiative to get involved actively.

[Moral: It's your responsibility, not your teammates. If you're not doing enough, do more. If you're doing too much, share with your teammates.]

Up-to-date formal designs can help keep people from getting lost, and assigning parts of a project to different individuals can help assess responsibility and performance.

[You should also accept that different project members will be able to do different amounts. That's part of life. In the largest project I worked on as an undergraduate, one person did 90% of the work, one person did 9% of the work, and one person did 1% of the work.]

9. It was observed that 4 people do not do 4 times as much work as 1 person does.

The Mythical Man Month goes into a lot of detail about why this is so, difficulties with coordinating large groups, and various techniques that have been used to solve the problems.

[In fact, it's pretty clear that if you throw too many people at a problem, they'll do less than one person working alone.]

[It was my hope in this project that four people would do about twice as much work as one person. I think that because groups looking at code are better at catching errors (even predicted errors before they happen), this is really the case.]

10. There was a difficulty in figuring out what modules were needed, and what modules went with which part of the project.

In some places I've worked, each part of the project was given a unique prefix to use on their modules. That way, you could figure what part of a project a file belonged to by looking at its name.

This technique could be used for 152 scale projects.

CVS supports a concept of modules - a directory that has a set of files that deal with one phase of a large project. This facility is used by large companies that have many projects, with overlapping modules (for instance, the Network code is used by everyone in the Auction project, but the ArtGUI is only used by the ArtGUI part of the project.)

A bit more time spent (a half hour or so) with CVS might help future projects use the tool more effectively.

[You also need to spend some more time reading the documentation. We'd tried hard to give an overall structure and then to give a little documentation on each module and class. We will use packages and modules in the next go-round of CS152.]

11. Some groups found that one member pushed during the initial design phase, and another member pushed the final completion.

Given the different time demands that other courses place on folks, this isn't surprising.

One place I worked, we had a ceremonial passing-of-the-marker to denote who was now in charge of coordinating things. It's not unusual for one person to run the design phase, another to run implementation, and a third to run the final integration/testing.

[See. The load can balance if you wait and give people time.]

12. It was noticed that designing with a group takes longer than doing it alone, but that having other people look at what you are thinking and pointing out problems makes a better design.

Design meetings can be some of the most exasperating meetings in industry. And some of the most exasperating meetings are the most productive.

Two tricks (to my mind) to having a good design meeting are:

13. Everyone thought that the project was a positive experience.

This matches my observation. I think everyone worked hard and learned a lot in this experience. I'm very happy to have had a part in it. Most of the groups worked well, and I'm impressed by the amount of code that was generated. [I'm also impressed that almost everything seemed to work in the end.]

I spoke with Dr. Stone about the work we did, and he'll be expanding on this experience in the software design course.


Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.

This page may be found at http://www.math.grin.edu/~rebelsky/Courses/CS152/99S/Handouts/project.clif.general.html

Source text last modified Fri May 21 08:27:04 1999.

This page generated on Fri May 21 08:33:48 1999 by SiteWeaver. Validate this page's HTML.

Contact our webmaster at rebelsky@math.grin.edu