SigCHI 2007 – day 2

The first session I attended today was a talk about “Programming by Professionals.” The first paper, presented by Cherubini, was about how developers use whiteboards to communicate. Although one audience member rightly pointed out that this study was somewhat limited in that is only utilized employees of Microsoft, some of the conclusions by the author are interesting.

For example, the author suggests that there are 9 primary types of use of whiteboard diagrams by developers:

1. understanding existing code
2. ad-hoc meeting
3. design / re-factoring
4. design review
5. onboarding – or bringing a new person up-to-speed
6. explaining to a secondary stakeholder
7. explaining to customers
8. hallway art
9. technical documentation

A few other general observations from this talk:

• Each type of use had different levels of formality and need for accuracy/precision.
• They also suggested that the diagrams were less important than the conversations around them – which makes sense.
• Developers did not follow any graphical standard in their diagrams (such as UML)
• Many design decisions are made in 1-to-1 meetings
• Engineers need microscopic and macroscopic views of the code. Zooming between these levels happens extremely fluidly in these whiteboard discussions
• Some plasticity in the drawing tool is required (to support the flexibility of the conversation)
• Architects tend to keep many versions of drawings/plans even as they evolve. The metamorphosis of a plan or design is important to capture both so that everyone understands “how we got here” and because it can be used post-hoc to help the designer better understand and improve their own process. Programmers, however, can express themselves in code – a process which in-and-of itself does not lend itself to plastic “redrawing.” This suggests that having a rapid prototyping process in an organization can capture alternate approaches early, as well as allow designers/engineers to express themselves in a manner appropriate to their work.

Usable Tools to Support Code Refactoring

Next there was a talk about a new tool to support refactoring on the Eclipse framework. There were some interesting ideas in this, but I thought the UI supporting the refactoring was rather undiscoverable and clunky. They were going in the right direction, I think, but the visual cues in the UI portion of this tool were very Java-esque (meaning old-school and ugly). A few points worth noting:

• Error messages are often used to help a developer systematically review affected spots in the code after a refactoring gesture is made. In other words, developers don’t seem to sit around and think… I wonder where all this change might cascade or how many instances of this wildcard I have used in the application. Instead, they make the change, and then use the error messages to get a feel for the reach of the change. In Eclipse this is relatively efficient, since you can get code errors and warnings without the need for a full re-compile.
• End programmers are not compiler experts; they don’t see their programs as abstract syntax trees. Tools to support their refactoring have to support the way they visualize their code/application

…. Games Panel writeup forthcoming ….