From: kambic@iccgcc.decnet.ab.com (Bonus, Iniquus, Celer - Delegitus Duo)
Newsgroups: comp.software-eng
Subject: Re: Properties of software, _not_ systems
Date: 15 Oct 92 11:46:21 EST

In article <wegner.719078055@gmd.de>, wegner@gmd.de (Eberhard Wegner) writes:
[...]

What a depressingly insightful piece.  This may help Jim Cardow with his "GOAL
of SWE" question.  Couple of thoughts.

In almost every statement, the word "people" is not used as the subject of the
sentence.  This I think is core  to these issues.  People use
software...development is difficult for people....etc., etc.  In one of my
earlier posts, I alluded to the fact that maybe software engineering is
something different, and that the goal may not become clear until we figure out
that "what".  I might argue that the integration of the practical psychological
aspects of the software engineer must be an integral part.  This is not to say
that engineers and scientists are inhuman with respect to their fields, however
the field of software engineering currently does not permit the intellectual
separation that can be achieved in other fields.  When we achieve this, and the
issues Eberhard raises are not issues any longer because people know the rules,
then we may have achieved the point where people can truly say that SWE is a
discipline.

Repeated for emphasis.
> 
> 1) Software cannot be used on its own, but it needs hardware for
> being used, and it becomes part of an organisational system
> including people and equipment. 
> 2) Development is difficult, replication is trivial and does not
> even require preparation for new models. 
> 3) A copy cannot be distinguished from the original (except by the
> data media that carry the two). However, presumably identical
> copies of the same object often differ due to voluntary changes. 
> 4) Every test is superficial (compared with the vast number of
> possible states and application situations). 
> 5) Small local changes may cause large effects, remote or even
> global. It is difficult to relate measurable characteristics of
> software to its external behaviour. 
> 6) Software does not wear out, age, or break. It does not change
> at all on its own. No preventive maintenance is necessary.
> However, a copy may deteriorate: A magnetic data medium or a
> handbook may become unreadable; this may require preventive
> actions. 
> 7) A hotline is often needed (not equally often provided),
> servicing is normally unnecessary (may be necessary for system
> software). 
> 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"). 
> 9) It is physically easy to change a piece 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; 
> -  software is changed much more frequently than tangible products
> (system maintenance: The modification of a system to correct
> faults, to improve performance, or to adapt the system to a
> changed environment or changed requirements. From ISO/IEC 2382
> Part 20 "Information technology; Vocabulary; System development",
> 1990-03-01, entry 20.05.09); 
> -  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; 
> -  changes may influence even parts which are functionally and
> textually remote from the place of change; therefore 
> -  changes (including those for the correction of faults) easily
> introduce new errors; 
> -  changes accumulate to a degree that nobody completely under-
> stands a software system still being used. 


George Kambic
standard disclaimer