Evaluating a Presenter

For the evaluation of a presentation, we will consider the following aspects:

1. the presentation suggestions from above;

2. the clear desire to work with the panel on the most difficult parts of the project. For example, a presenter should never ask “what do you want to see next”.

3. the presenter’s ability to work with the panel in an interactive manner. In particular, a presenter should never discuss problems abstractly but always direct the attention of the panel to concrete pieces of design documents, comments, or lines of code.

4. the presenter must know when to acknowledge a potential problem in the code and, equally important, must realize when it is time to reject criticism. Consider a coding problem. In this case, a presenter may wish to work through a test scenario to understand why code may fail on a specific kind of input or sequence of calls etc. Similarly, for an architectural complaint, a presenter must use existing drawings in files or drawings on the blackboard to work through a scenario. What-if scenarios are a particularly good way to assess architectural problems.

5. the presenter is in obvious command of all the code, even though the code is created in pair-programming sessions. Thus, a presenter should never have to ask his colleague for advice and a colleague should never have to jump in.

As a reader, you will play three different roles:

• head reader; as such you are responsible to keep the presentation on track;

• assistant reader; you and the head reader find mistakes, omissions, and questionable design decisions;

• secretary; you keep track of the questions that the readers ask, note the discovery of problems, take notes, and summarize the to-do items as a memo.