Here is a tentative schedule (including possible exercises), using eight
half-hour blocks:

1. Motivation: Why is an API more than just public methods?
Example exercise: Given an underspecified "API" of the turtle graphics plug-in
(e.g., consisting of the public methods penDown(), go(), turn(), and penUp()),
write a program that draws a house.

2. API critique: What to look for when reviewing an API.
Example exercises: Where is the API underspecified? Where is it inconsistent?

3. Appropriate level of specification detail: What needs to be specified, and
when can or should specs be vague?
Example exercises: Given a "corrected" turtle API: Where is the API
overspecified? Give examples for possible evolutionary steps that are prevented.

4. Evolving APIs 1: Binary and source compatibility
Example exercise: Compatibility Quiz – find the breaking change!

5. Evolving APIs 2: Techniques for evolving APIs
Example exercise: React to a change in requirements – How can we implement color
turtle graphics without breaking our existing (house-drawing) clients?

6. Advanced Topics: Callbacks, Events, Concurrency, Failure
Example exercises: What would happen if the turtle operated asynchronously? Add
listeners (for events like pen down, pen up...) to the API.

7. Process issues: Start small, start early, ...

8. Discussion, questions, API stories from the trenches