@Article{LC:92,
  author = 	 {Linn, Marcia and Clancy, Michael},
  title = 	 {The case for case studies of programming problems},
  journal = 	 CACM,
  year = 	 {1992},
  OPTkey = 	 {},
  volume = 	 {35},
  number = 	 {3},
  pages = 	 {121-132},
  OPTmonth = 	 {},
  OPTnote = 	 {},
  annote = 	 {

This is a lovely paper, another of those gems that I have read.  Every
time that I reread it, I gain new insights.  

The overall point is that using programming case studies is a much
more effective way of teaching programming design than previous
methods that have been studied.  They define a case study as
consisting of an explanation of a problem, an expert solution to this
problem organized around one or more {\em templates}, and an expert
commentary on their solution, which describes the various design
decisions, and rationales for these decisions that the expert made.
The templates are knowledge structures that include pseudocode that
represents the basic action of the template, sample programs that use
the template, illustrations to provide graphical reps, verbal
descriptions, implementation information sufficient for incremental
development, testing information, antibugging and debugging
information, and connections of the component to related templates.
They evaluated their case studies technique on students from
precollege classes; details of this evaluation are in a separate
paper. 

Before launching into describing their case studies, the authors
define their notion of programming design skills, and follow that with
a fairly comprehensive overview of previous studies on how design has
been taught.  In particular, they argue that expert problem solvers in
a variety of domains, including programming, organize their knowledge
into complex structures.  Most programming instruction overemphasizes
syntax, and students tend to have a syntax based mental
representation, which is inadequate for the complex kinds of design
decisions that are required for the construction of larger programs.
They identify what they call their eight principles of program design
that characterize expert design behavior.  They then argue that using
case studies can help students to acquire these skills.

This paper is extremely well written.  It clearly diagnosis a problem:
that students do not learn design skills.  It presents relevant
research from both software engineering and cognitive science as to
the kinds of processes and structures that are relevant to the design
task.  It presents both an abstract description and concrete example
of the template structure that it proposes can help to teach design
skills.  It identifies a number of subskills (the eight mentioned
above) that characterize expert design behavior.  And it reports on
empirical studies that they have made within the classroom, comparing
the effect of using the case studies.  I find their research
completely convincing.  I have incorporated pieces of their work into
the teaching that I do.  But, every time I reread this, I can see that
there is far more work that I can do.

This paper actually is a lovely companion to the Brooks
paper, and it is a shame that they don't reference it.  For it is to
Brooks more than to Soloway that I think they relate.  This is because
the design decisions that are being explicated have to do with both
the real world domain, and with the mapping between the domain and
programs, and the process of constructing this mapping.  It suggests
that people use much more than plans.  

On rereading this paper,
however, I can see why I was surprised by Clancy's definition of a
case study when I took the sigcse workshop.  Although I enjoyed his
workshop a great deal, and felt that there was merit to it, he never
discussed the issue of expert design and commentary.  Rather,
everything was student focussed, with discussion and meta-analysis.
These activities are important, but they do not capture many of the
essential qualities that are argued for in the paper.  No wonder I was
a bit surprised.
}  
}