From: johnson@cs.uiuc.edu (Ralph Johnson)
Newsgroups: comp.lang.c,comp.software-eng
Subject: Re: Will we keep ignoring this productivity issue?
Date: 13 Nov 92 13:30:56 GMT
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL

mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:

>But from what I can tell, high-level hacking is
>not something that can be put into words, never mind analyzed
>reductionistically.

I disagree.  I think that if we study how people *actually* do things,
instead of just making up a theory of how they should do things, we
can learn a lot about how to teach people to do better.  One problem
is that computer scientists don't know how to study people; that is
the job of psychologists.

People have studied how good programmers work, and what they have
found indicates (to me, at least) that the way we teach people design
is faulty.  We usually teach people design by teaching them a design
method that consists of a set of notations, usually graphical, and a
set of rules that tell how and when to use each notation, how to link
notations, problems that occur in a design and how to fix them, and
how to evaluate designs expressed in these notations.  But good
designers also depend on a large body of more domain specific
knowledge about design, including algorithms, data structures, and
design idioms.  This domain specific knowledge is just as important as
the notations for recording design and the rules for using those notations.

Studies of expert programmers have shown that knowledge is not
organized around syntax, but in larger conceptual structures, such as
algorithms and data structures [Adelson and Soloway].  Soloway
claims that expert programmers organize their knowledge in plans
that indicate the steps necessary to fulfill a particular goal
[Soloway and Ehrlich].   In the same way, it is likely that good
designers do not think about the notation they are using for 
recording the design as much as they are looking for patterns that
they can match against design plans that they have learned in the
past.  Recognizing and teaching these design plans is therefore
necessary to produce good designers, but we don't do it.

Simply teaching design notations and rules for using them is unlikely
to be more effective at producing good designers than teaching
language syntax and rules for using it is at producing good
programmers.  The best way to teach programming is to explicitly teach
plans and to explain how they are combined with each other to form
complete programs [Linn and Clancy].  That is probably the best way to
teach design, too.  However, this requires having a set of plans to teach.

What I think computer scientists should be doing is enumerating the
design plans that good programmers actually use.  We should enumerate
debugging strategies, rules of thumb for solving design problems, etc.
This is much more important in the long run than the current
preoccupation with using pretty pictures for design notation.

Here are some good papers to read that back up what I am saying.

Adelson, B. and Elliot Soloway.  The Role of Domain Experience in
Software Design.  IEEE Trans. on Software Engineering, V. SE-11, N 11,
1985, pp. 1351-1360.

Curtis, Bill.  Cognitive Issues in Reusing Software Artifacts.  In
Software Reusability, V. II  ed. Ted J. Biggerstaff and Alan J.
Perlis, Addison-Wesley 1989, pp. 269-287.

Linn, Marcia C. and Michael J. Clancy.  The Case for Case Studies of
Programming Problems.  Communications of the ACM  V. 35, N 3, March
1992, pp. 121-132.

Rich, Charles and Richard C. Waters.  Formalizing Reusable Software
Components in the Programmer's Apprentice.   In Software Reusability,
V. II  ed. Ted J. Biggerstaff and Alan J. Perlis, Addison-Wesley 1989,
pp. 313-343.

Soloway, Elliot and Kate Ehrlich.  Empirical Studies of Programming
Knowledge, IEEE Transactions on SOftware Engineering V SE-10, N5,
September 1984.  Reprinted in Software Reusability V II.


Ralph Johnson -- University of Illinois at Urbana-Champaign