Program design techniques?

[Roy Smith]

> 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.

	I do this too.  Occasionally I actually get around to writing the
code.  By the time I reach the point of typing it in, it's such an
anticlimax that I don't usually bother. :-)  I find flowcharts very good
for pretending to do something useful when the boss walks in.

	Most of my pre-typing thought goes into designing data structures.
It took a long time for me to figure out (i.e. to finally learn from other
people's preaching and my mistakes) that data structures are more important
than code.  If you have well laid out data, the code to manipulate it is
obvious.  If the data structures are awkward, no amount of code will make it
work right, or be easy to understand.

	On of my favorite examples is the Version 6 Unix file system.  Once
you see the layout of the inodes, directories, superblock and freelists, it
is trivial to figure out what you need to do to create a file, remove a
file, read and write a specific block, etc.  (I'm not picking on post-v6
file systems, I just don't know their details well enough to talk about
them).

	Once I actually start writing code, I begin with a stripped down
version of whatever it is.  No options, no bells and whistles, no worries
about handling special cases.  Once I get this working I can start adding
in features.  Before this goes too far, the problems with whatever data
structures I picked become obvious, and I start adjusting those and
incrementally build up the program.

	This rarely leads directly to a finished product.  For a system of
any reasonable size (no, I don't know how many lines of C that is), I will
usually reach some point where the program is more patch than planning.  At
that point, I chuck it and start from scratch, incorporating the lessons I
learned from the experimental version.

	The key is to be able to recognize when it's time to start over.
Do it too soon, and you won't get anything out of the experiment.  Do it
too late and you waste time beating a dead horse.  Sometimes the hardest
part of all this is telling your boss "Yeah, it works, but you can't use it
yet because I want to rewrite it all".

> a HIPOish kind of process decomposition fairly useful
> I have sometimes used Warnier-Orr diagrams.

	What does "HIPOish" mean?  What are Warnier-Orr diagrams?
-- 
Roy Smith <allegra!phri!roy>
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016