Program design techniques?

[Jay Freeman]

The recent discussion on "writing code" seems to suggest that program design
techniques are worth discussing:  I wonder if there is any consensus -- or
any interesting diversity -- of such methods.

I myself try to think about a program for as long as possible before writing
anything -- sometimes one will be on "back burner" in my head for months.
This practice often helps me come up with ways to simplify things.  Then I
usually go through at least an informal preliminary design, often making
written notes, deciding what kind of abstract data types are necessary,
and thinking some about what kind of flow control will be required to hook
them together.  For complicated and featureful programs, I also find it
useful to think hard about a development path that will allow me to bring
the system up a piece at a time.

This last is fraught with opportunity:  Implementing from the top down can
produce an interim situation in which you have an elaborate control
structure or driver which is untestable because it's not hooked to anything
that does anything; implementing from the bottom up can result in lots of
little primitives that are untestable because there is no way to coordinate
their activities cooperatively.

I find abstract data types, psuedocode, and a HIPOish kind of process
decomposition fairly useful.  I rarely use the kind of box-and-arrow flow
charts that introductory books are full of.  I have sometimes used
Warnier-Orr diagrams.
-- 
Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)