perform 1000-beginning.
       perform 2000-middle until done.
       perform 9000-end.

Then I like to stand up, do my end-zone dance*, stretch, announce my
coming in under budget, shake a few hands, then sit back down to repeat
that exercise on 2000-middle. beginning and end get filled in when the
middle crashes because I did not open a file, or when my manager says,
"Great, Kenny, but where the %$%$^ is the output file?".

The thing I like about this is that I get to defer the tedious details
as long as possible, generally until a day or two before we go live. The
compiler error listing is my "do list". It tends to get longer and
longer during the first third of development, stay constant for the
middle two thirds, then diminish asymtoptically for the final three thirds.

Any lines still producing compiler errors when it is time to go live I
just comment out.

hth.**

kt

* American football. Showing off after scoring.

** Just kidding, but I do like to work top-down, and I never test
low-level stuff on its own. What if it works? Then that time was wasted.
  yes this makes for more and harder debugging, but Lisp is great for
runtime debugging, and debugging is fun, so I have plenty of energy for
it. if I had to test every function after coding it, I would become a
bookkeeper or something else more entertaining. fast and loose, ladies,
fast and loose.

k