| RHF Joke Archives |

Copyright (c) 1990 Patrick D. Scannell
Used by permission

     "Software Engineering Process Archaeology, An Overview"
          (Transcript of a lecture by Grant Money, D.S.A.)
               (Doctor of Software Archaeology)

To trace the development of the Software Engineering Process, we
must begin in the late Pleurassic period (so named because the
air was very dense and it was hard to breathe.)  It was during
this period that violent geological upheavals brought to the
earth's surface large deposits of silicon and germanium crystals,
and the first crude programs, barely more than undifferentiated
collections of single-bit organisms such as the primitive
kilobyte, crawled out of the sea and began to live and thrive on
silicon.  More complex forms, such as structures and arrays,
began to evolve.

It was during the Ice Ages of the Fortybeloic period, however,
that programs began to thrive and multiply.  Unlike the dinosaurs
who preferred a warmer climate, software produced its own heat
and operated better in a colder environment.  However, in the
warmer Kerocene epoch which followed, the competition between
programs became more fierce, and the first carnivorous programs
such as viruses began to develop.  Parasitic organisms such as
statistics gathering tools also evolved during this period.

During these periods, thousands of strains of primitive programs
evolved, thrived for a while, and died out.  But it was not until
the advent of the customer that programs began to assume the
importance that they have today.  The oldest known customer,
Pithecanthropurchaser, was discovered at Olduvai Gorge by Dr.
Louis B. Sneaky.  Fossil remains and other evidence indicate that
the Pithecanthropurchaser whose remains Dr. Sneaky discovered
died while waiting for a customer service line to take him off
hold.  (Of course, the average life span of the
Pithecanthropurchaser was only about 35 years, so this is not too
surprising.)

The next step in the evolution of software was the invention of
the requirements document.  Until the requirements document,
programs were purchased without being expected to do anything
specific, or in some cases because they had done something
interesting and the purchaser hoped that they might do it again.
There was, however, no clear perception that a certain input
might result in a certain output.  The first requirements
document is believed to have been a gift from aliens who carved
it on a large basalt block, as dramatized in the movie "2001."

The existence of requirement specs led purveyors of software to
experiment with interbreeding of programs in order to produce
desired characteristics.  Gregor Mental, a monk, discovered that
certain characteristics (such as Help Key Support) were
recessive, but could be passed on to future generations of
software.  Thus a program with both the recessive help function
and the dominant no help would not have help key support, but the
offspring of two such programs would have one chance in four of
having this characteristic.  (What we would now call a feature.)

Meanwhile, the first steps toward a Software Engineering Process
Aggregation had been taken.  The so-called "Midas" (or "Through
the Goose") model, popular during the Middle Ages and Early
Renaissance, looked like this:

     FRONT VIEW                         SIDE VIEW

    _______                          __________________
   /       \                         |                 |
  /\  ENG  /\                        |                 |
 /  \     /  \           Customer    |                 |
/    \()/     \               =======|                 |=====
\ PLM ||MFG  /           Input     |                   |
  \   ||   /                       |                   |
    \_||_/                         |___________________|

As the diagram shows, this model allowed Engineering, PLM and
Manufacturing to go round and round in circles, while Customer
input went in one end and out the other without stopping.

The next model, used throughout most of the 20th century, was the
"Osmosis" model:

                ______________________________
CUSTOMER       |         |         |         |
INPUT -------->|  PLM    |  R&D    |  Mfg    |---> PRODUCT
               |_________|_________|_________|

This model has the advantage, for the customer, that some of the
customer's requirements may, with some luck, filter through into
the product by a process similar to osmosis.

But what, we may ask, is the model of the '90s and beyond?
Predictions, of course, are dangerous, but many scientists now
believe that the "Osmosis" model will be replaced by the so-
called "Milli Vanilli" model (sometimes also referred to as the
"Tom Sawyer" model) in which the customers actually produce the
software themselves, and the producer sells it back to them at a
profit.  Naturally, this model presents great challenges to the
marketing and sales organizations.

Thus, to summarize, we see that the development of software
engineering process has made considerable progress over the past
few eons, and yet in the end we must conclude that it still makes
very little sense.

Thank you.  Good night.

| RHF Joke Archives |