Final exam grading notes

I've just finished a pass through all the final exams. Overall, I'm pleased.

I expected the first question to be pretty easy. You can't put everyone on the same floor (within the 30 meter "asymptote" mentioned by Herbsleb), but you can try to arrange offices to make the most critical interactions as frequent as possible, and you can do some other things to create opportunities for interaction. The cafeteria on the first floor was a big hint, and many of you took it. One of the interesting ideas (which I didn't think of, but more than one of you did) was having staggered lunch times to try to create specific groupings of people (either within a team, or across teams) to talk. Another idea was having big meetings in the main conference room just before lunch. A couple of you also had some good specific ideas about how to encourage people to move from floor to floor, e.g., by having different snack foods or other facilities available on each floor. There were also good ideas about using the smaller conference rooms on each floor in ways that encourage informal meetings, such as giving each team a space in a conference room in which they could keep up material on walls and whiteboards. Some of you also mentioned that, since the time in which the evidence Herbsleb relies on was gathered, "virtual" interactions like IM have become better and more widely used. I liked these ideas that were specific to the circumstances of this company (number of teams and employees, facilities on each floor) and creative in the ways you addressed the problems we have discussed.

The second question drew directly from some in-class discussions, and a lot of you did recall and adapt that, with discussions of root-cause analysis and adjusting the process to avoid certain classes of errors as well as detecting them more effectively. Some of the answers discussed looking at the history to assess maintenance of old code, but didn't really address how to use the information for new systems. A lot did address using it for new systems, but were pretty light on discussing how ... which shouldn't surprise me, because we didn't talk much about how error reports are triaged and classified to make that possible. Several answers underestimated the difficulty of searching for relevant bug reports (similar symptoms don't necessarily indicate similar causes), but I didn't hold that against you.

I expected the third question to be the hardest, and I think it was. Some of the answers were pretty generic and didn't address the peculiar challenges and opportunities in this specific problem (final hardware available only late in development, and a brand new user interface which will depend on the functionality of that hardware). I dropped a big hint in saying that the functionality was already available, but in a larger form factor, and a few (but not many) of you took advantage of that in the way I was hinting at: We can work with full functioning prototypes that just don't fit in a watch. Maybe we can hang part of the hardware on a user's belt, maybe we need someone running along beside the user carrying some of the hardware, but we can do some pretty good usability testing using the hardware that is available early. While this specific approach was not mentioned much, there were other pretty reasonable tactics, like building the software with a bare minimum of functionality and based on a bar minimum (and hopefully stable) specification of what the hardware could deliver.

An interesting note on that last question is that many answers either suggested or assumed that it had a much larger than usual development team (often the whole software division), and one made a (pretty good) argument that it should be done by a smaller than usual team.