Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.software-eng
Subject: Re: Writing code/Basics of Program Design)
Message-ID: <3008@geac.UUCP>
Date: 14 Jul 88 15:48:25 GMT
Article-I.D.: geac.3008
References: <900@td2cad.intel.com> <580001@hpiacla.HP.COM> <2992@geac.UUCP>
Reply-To: daveb@geac.UUCP (David Collier-Brown)
Organization: GEAC Computers, Toronto, CANADA
Lines: 123
Organization:

Lst week I said...
|  There are two other basic approaches to a largish project, one of
| which is best described as "predictor-corrector", and another best
| described as a "modeling" approach.

  At the request of Stan Osborne @ pbdoc.pacbell, I'll rant
briefly about predictor-corrector... About which I'm biased.


    The term comes from Mathematics, describing algorithms which
guess at a starting point, move to that point and then decide which
way to move to get closer to the desired answer.
    In computer science, it really means that one is trying to
hit a moving target: one predicts what **should** be the answer, and
then finds out why not.
    In either case, one can discuss it in terms of:
        1) how fast it is converging on the target,
        2) how expensive it is to do another iteration,
        3) how much one can expect to gain by doing another
            iteration.

    This means that, once you have captured a customer, one's
business managers can discuss how much we're going to make from her
in business terms ,without delving deeply into the details of
programming. After the first iteration, that is!


    Specifically, one is doing a series of prototypes, each
getting closer and closer to what the customer wants.  Consistent
with hardware prototyping terminology, we'll call the prototypes the
"breadboard", "brassboard" and "printed circuit"...
    This is a **specific kind** of prototyping approach: not all
prototyping fits this model!



The Specification Phase:
    Write a breadboard prototype to test out the user interface
and determine the specifications.  Don't consider either efficiency
or elegance. This one you're unconditionally going to throw away, so
don't waste money!

    Make sure that it really does what the customer wants (well,
thinks she wants). Keep trying until you do. Don't stop early!


The Design Phase:
    Now go away into a back room and design a brassboard.
Find the architecture that bests maps the task into an achievable
implementation. Use whatever mental tools you like, but plan for
evolving the program, especially storage structures (using a
database is a REAL good idea here), protocols and interfaces.
Try to break up the program into three layers: user interface,
application proper and core facilities.  Plan to write the interface
and core facilities as reusable/replaceable independent parts.

Implementation Phase 1: 
    Write the brassboard for alpha-testing, in parallel to the
customers existing (manual) system.  Make the implementation simple:
The Unix kernel is full of **very simple** techniques, even though
the authors knew the harder, faster ones.  Follow their example!


Validation & Verification 1:
    There is no real "unit test/integration test": all in-house
tests are integration (verification) tests, all demos are validation
tests.  Spend time building scripts and test harnesses: you will
have to re-run most tests every time you fix something, just to be
sure you're not headed towards a maintenance nightmare.

    At the end of this, you should have a customer who says "It
works ok, but its too big and too slow. When do we get the next
release?" If you get that question, you've hit the jackpot!


Implementation Phase 2:
    You're writing and releasing versions 1.2 through 1.999,
fixing specific performance problems and misfeatures.  You're also
seeing what's wrong with the design,  Don't try to redesign on the
fly, save that for version 2.0, but do record what you do/don't like.

Validation & Verification 2:  
    Test, and record bug ratios so as to make sure that you're
not going backwards.  Make sure that the number of bugs is
monotonically decreasing and is decreasing fast enough.

Implementation Phase 3:
    "Release 2.0".  Now you exit the prediction-correction cycle
and use a more formal method to review what you achieved, what you
want to change and add. And then do it.  But do consider any
new/experimental features as individual candidates for the
predictor-corrector approach.
    

Weaknesses of this Technique:
    1) It works best on hard, poorly understood or politically
       dangerous problems,
    2) It assumes that specifications are hard/impossible to
       write and validate,
    3) The customer must want a short time scale for first
       product, and be prepared to live with an "early release"
       to get something functioning,
    4) It typically produces code which is a wonderful blend of
       brilliance and sheer stupidity, so you can't just hand it
       over to an underpaid "maintenance" group after the first
       release, you have to keep the lead developers working at
       it, and
    5) Without active involvement of management and the customer,
       it can into mindless hacking...


Conclusion:
    Its like the girl with the curl: when she's good, she's
very very good, but when she's bad, she's horrid.

--dave (I love this technique, I use it **inappropriately** all the
        time...) c-b

-- 
 David Collier-Brown.  {mnetor yunexus utgpu}!geac!daveb
 Geac Computers Ltd.,  |  Computer science loses its
 350 Steelcase Road,   |  memory, if not its mind,
 Markham, Ontario.     |  every six months.