🚀 go-pugleaf

In article <3471@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
> Software technology is not in the primitive state that people so constantly
> moan about.  First, software has a much more difficult task than hardware.  We
> have more expectations from software than hardware, so the perceived state of
> the technology is less than the actual state.  
> 
> transistors == machine language
> 7400 series == assembly language
> msi         == higher level languages
> lsi         == libraries
> vlsi        == utility programs (ala Unix)
> custom ICs  == inheritance and generics (needs more experience to say for sure)
> 
> It looks to me like software and hardware technology have tracked fairly well.
> The cause for the difference in perception is that hardware has done the same
> task cheaper and faster while software has performed an ever more difficult
> task.  Because hardware has simpler measures, it has more apparent progress.
> The actual progress is roughly equivalent.
> 

I really like Lawrence's analysis.  He has a few vital points.

1.  Today's software projects attack extremely difficult tasks.  It is 
    unlikely that these tasks would be attempted in a circuit or in a
    mechanical system.

2.  Software technology has evolved.  I would not have built the same
    equivalence that he did, but his way of looking at things is certainly
    reasonable.

I have a few observations that I would like to add.

1.  I believe many of the problems attributed to
    the "software crisis" are a by product of the difficulty of the task
    itself, not of the fact that the solution is implemented in software.
    Often we run into problems because we do not understand the problem
    that we are trying to solve well enough.  Therefore, the program that
    is built doesn't solve the right problem.

2.  Often the people who wish to purchase a software system to inprove the
    efficiency of their operation do not understand the true problem that
    they want to solve.  Introducing automation does not always make a
    business run more efficiently, largely because the change introduced
    in work methods by the automation changes what should be automated.
    I think those who specify what is to be done often don't get this
    right.  I am not sure it is possible to get it right in many cases.
    An example is the stories I have read about the introduction of robots
    on assembly lines.  Supposedly many of these installations have not
    worked out well on an economic basis.

3.  I am not entirely convinced by the arguments presented of where money
    is spent during the "software life cycle".  I have seen varying estimates
    up to 80% for maintenance.  I always wonder what maintenance means.  Does
    it include enhancements to the product because customer needs were not
    understood?  Does it include enhancements to address more markets?
    Does it include ports to new operating environments such as porting a PC
    program to the MAC environment?  These things are very different than
    bug fixes.  If things are counted this way, the newest IBM 370 series
    computers should probably be counted as engineering changes on the
    original 360.

4.  Program bugs after release are a serious problem.  Just read
    comp.micro.ibm.pc to see how many postings are related to bugs
    in standard packages.  I would hate to have to pay to send a free
    update diskette set to every registered owner of LOTUS 1-2-3
    (This is probably a trademark of LOTUS development).  I would still
    rather do this than put a white wire change into every IBM PC.
    With today's hardware, the answer to hardware problems may be to
    document them and program around them.  This is equivalent to a
    work around solution for software problems.  I will not make
    apologies for buggy software.  We need to make some improvements
    here.

5.  The theoretical base is better for hardware than for software.
    People have been studying the physics of electricity for MANY
    years, and many things are well understood.  One of the reasons
    many new hardware designs work well is because they are extensively
    simulated.  They can be simulated because the theoretical base allows
    software to simulate them.  Most of the work in theory supporting
    software that I have seen falls into two classes.  The first is the
    analysis of algorithms.  This area has been extremely fruitful.  We
    have been able to find good algorithms for many computations.  We also
    have been able to find theoretical upper bounds for performance and 
    see how close we have come to those bounds.  The second area is in the
    theoretical basis for computing in general.  In my mind, this area
    covers many basic problems such as the halting problem and proof of
    correctness.  The advances in this area have been significant, but they
    are very difficult for the working programmer to use.  They are more
    like Maxwell's equations for electromagnetic fields.  I don't know
    of any theoretical basis that supports software like circuit analysis
    supports circuits (both digitial and analog) or like boolean algebra
    supports digital circuits.  We have no good way of doing automatic
    (or really semi-automatic) checks of software boundary conditions,
    or of driving software through many states.  Currently, we manually
    generate many tests, and then we manually run them.  It would be
    really nice if we could have some system generate and run tests
    and then we could analyze the results.

6.  The state of the theory as listed in 5 also makes correctness by
    construction difficult.  I don't really think circuit designers 
    do everything like that anyway.

I hope I have managed to shed some light on the matter, and perhaps
to spur some thought.
                               John Unruh