From: lehman@george.arc.nasa.gov (John Lehman -- GDP)
Subject: Re: Properties of software, _not_ systems
Summary: Misc. comments; &, differentiate "people problems".
Organization: NASA Ames Research Center, Moffett Field, CA
Date: Fri, 16 Oct 1992 19:38:37 GMT

>                                          presumably identical
> copies of the same object often differ due to voluntary changes. 

If one can use a "diff" command on the copies of the source,
at least it is easy to verify whether they are identical.

> 4) Every test is superficial (compared with the vast number of
     ^^^^^
> possible states and application situations). 

By "superficial" do you imply "insignificant"?

Even testing which spot-checks a complex system can be "significant". 
There should always be some test which will "indicate" whether a system 
is usable for a given purpose.  It doesn't have to be a perfect test.  

By a simple test of one software system, I was able to determine in a 
few minutes that it was crippled and that the two sales reps demoing it 
couldn't get it fixed in the same day, even with phone consultation to a
technical consultant.  It was really just a simple configuration problem 
involving tabs, so you could call it superficial, but I thought that the 
test was significant.

> 8) Computers seem to handle complex tasks easily, so that software
> is produced and used for solving problems which have not been
> fully understood by complex programs which nobody can fully
> understand ("unmastered complexity"). 

Let's have some guidance on dealing with unmastered complexity.
Are there some favorite reference books on the subject?  Should
we deal with the complex, unmastered system as a black box with
statistically sampled outputs?

> 9) It is physically easy to change a piece of software, 

Yes, that's one property of software.

> and there are consequences to this changeability: 
> -  Software is put into use before being debugged because it seems
> easy to remove bugs later; 
[stuff deleted]
> -  requirements change frequently during development and use; 
> -  presumably identical copies of a product are yet different
> because of fixes and patches; 
> -  documentation is virtually always obsolete; 
[stuff deleted]
> -  changes accumulate to a degree that nobody completely under-
> stands a software system still being used. 

This may be trite, but these problems are in theory easily remedied, by 
good management of changes; or even (_I_ think) just limiting changes, 
which would reduce the severity of the software changes problem to that
of the hardware changes problem.

The problem of unmanaged change isn't precisely a software problem; though 
it is partly attributable to people's ignorance about the problems of 
software.

It's true that unmanaged or poorly managed changes are more prevalent
in software than in most other areas.  Maybe it would be appropriate
to say: 
      "The problem of change is not yet fully appreciated by those
      who manage software, because these problems are less immediately 
      obvious in software than in more tangible goods.  For example, in 
      software there is little "startup" cost in the act of making a change.  
      (The associated costs are _delayed_!)"  

Or maybe even, the problem of change is essentially the same in all fields, 
but software simply experiences _more_ changes.

Unmanaged change of software might also be more aptly called a
"discipline" problem than a "software" problem.  A lot of people
know _how_ to manage changes to software, but for some reason
it does not get managed.  In a sense, it is a mostly "solved" problem
in the purely-software arena, and a mostly "unsolved" problem in the
psychology/managerial/sociology/people arena.  I know you want
to separate software problems from hardware problems; don't you
also want to separate software problems from people problems?

Thanks for the list!  lehman@ames.arc.nasa.gov[No wasteful 4-line signature.]
Newsgroups: comp.software-eng,comp.lang.prolog,comp.lang.lisp