MDAY@XX.LCS.MIT.EDU ("Mark S. Day") (02/10/88)
Soft-Eng Digest Tue, 9 Feb 88 Volume 4 : Issue 6
Today's Topics:
Free Upgrades and Bug Fixes -- A Policy Question (6 msgs)
Offices versus Cubicles (2 msgs)
Separating Parts of Development (2 msgs)
Software Complexity Measures Will Never Be Accurate
Software Science Counting Strategy
Training Courses for Software Management
----------------------------------------------------------------------
Date: 26 Jan 88 06:34:53 GMT
From: bnfb@june.cs.washington.edu (Bjorn Freeman-Benson)
Subject: Free Upgrades and Bug Fixes -- A Policy Question
What is the consensus about software vendors offering free upgrades
and bug fixes? It seems to me that other industries have always
charged for upgrades, especially in a consumer environment. For
example, dish washers are not upgraded each year for free -- if you
want a bug fix, you buy a new one.
Now I agree that the analogy is not perfect, but the software
industry is moving from small numbers of individually built programs
to large numbers of mass produced programs, and thus we are moving
towards software as a consumer item.
If one were to say "buy the upgrades", then the engineering issues
of quality and relability would become even more relevant.
Furthermore, the usual practice of only supporting (in the training
sense) the latest release, would be hard to justify.
Comments?
Bjorn N. Freeman-Benson
------------------------------
Date: 26 Jan 88 19:57:25 GMT
From: rion@ford-wdl1.arpa (Rion Cassidy)
Subject: Free Upgrades and Bug Fixes -- A Policy Question
Upgrades and bug fixes are not the same thing and should not be lumped
together like this; if you are going to make analogies, seperate them
and make individual analogies. Lots of retail products have been
subject to recalls. This is usually when the manufacturer just plain
blew it and made something dangerous or extremely defective. I would
equate this to bug fixes and note that the consumer virtually never
has to pay anything during a recall.
Since this column is software engineering, let me just say that if
software was being developed properly, there wouldn't be obvious bugs
that need fixing in the first place!!!
As to free upgrades, I own and use a fair number of different software
products and have never heard of totally free upgrades; only when we
have been a beta test site have we even come close to getting any
"free" software. Other upgrades we've gotten come from having a
maintenance agreement with the vendor (which costs!!).
Rion Cassidy
Ford Aerospace
rion@ford-wdl1.arpa
...{sgi,sun,ucbvax}!wdl1!rion
------------------------------
Date: 27 Jan 88 13:53:19 GMT
From: mtune!whuts!homxb!houxs!beyer@rutgers.edu (J.BEYER)
Subject: Free Upgrades and Bug Fixes -- A Policy Question
Of course manufacturers of inferior products such as automobiles may
be forced to distribute bug fixes -- often called recalls -- and be sued
for various liabilities ... .
------------------------------
Date: 27 Jan 88 11:19:56 GMT
From: xanth!kent@AMES.ARC.NASA.GOV (Kent Paul Dolan)
Subject: Free Upgrades and Bug Fixes -- A Policy Question
First, if you buy a washing machine, and the door falls off in the
first ten days of use, you call the vendor, and get it fixed under a
"warranty", usually in a day or two, if the vendor plans to stay in
business.
However, software vendors are scared witless about giving warranties,
because of something called "consequential damages". Also, (I've done
this task) fixing up a broken piece of code is rarely an operation
you'd like to guarantee to do in a couple of days. Instead, when the
compiler you just bought can't compile a null program ("the door falls
off..."), you call the vendor, it gets added to a long queue of things
to fix, and, usually months later, you get an "upgrade".
Sometimes it is really an upgrade, but most of the time, it is just
somebody "putting the door back on" in such a way that it won't fall
off when you use it. So, your "free" upgrade is just a little scam
that you and the vendor agree upon, to replace the much too dangerous
(to the venor) "warranty", while still getting things fixed, sometimes.
If "software engineering" were yet a science, and programming could
produce reliable, workable products at reasonable costs, this scam
would not be tolerated. However, with the demand for software far
outstripping the ability to produce it, and the reluctance of the
buyers to pay the true cost, in time and money, of producing reliable
software, we programmers continue to rebuild our bridges each time
they tumble into the torrent, and call our efforts "engineering".
What a terrible devaluation of a word!
Software engineering - it CAN happen in our lifetime!
Kent, the man from xanth.
I code reactor power plant control in C.
I add "count_of_recent_alarms" to "count_of_rods_to_lift".
C has weak type checking; the compiler doesn't notice.
A major coolant valve sticks, a spate of alarms occur.
All die.
Oh, the embarrassment!
------------------------------
Date: 28 Jan 88 15:45:12 GMT
From: uflorida!codas!usfvax2!pdn!reggie@gatech.edu (George W. Leach)
Subject: Free Upgrades and Bug Fixes -- A Policy Question
bnfb@june.cs.washington.edu (Bjorn Freeman-Benson) writes:
>What is the consensus about software vendors offering free upgrades
>and bug fixes?
Well, I would say that depends upon the nature of the release. Often
the next release or upgrade of a software product contains a blend of bug
fixes and new features. In some cases, those bug fixes are esential both to
the end customer, and to the viability of the vendor in the eyes of their
customers. The features are nice to have and are probably viewed by the
vendor as essential to keep their customer base from going with a product
from the competition.
Another problem from the vendor's view point is supporting multiple
versions of a product. In the ideal case a vendor would like all of their
customers to be working with the latest release, so that there is no need
to support older releases. However, if the vendor is going to charge for
the upgrade, this may keep many from taking it.
Software is a funny commodity. We are constantly trying to draw
comparisons with other industries/products in terms of engineering, production,
support, etc.... But it is fundamentally quite different from all other
products and processes. It deserves it's own approach, but don't ask me how.
--
George W. Leach Paradyne Corporation
{gatech,rutgers,attmail}!codas!pdn!reggie Mail stop LF-207
Phone: (813) 530-2376 P.O. Box 2826
Largo, FL 34649-2826
------------------------------
Date: 28 Jan 88 15:10:00 GMT
From: netsys!killer!ninja!sys1!trsvax!don@lll-winken.llnl.gov
Subject: Free Upgrades and Bug Fixes -- A Policy Question
I don't think the analogy applies too well. If I buy a dishwasher which
malfunctions due to manufacturer error, I expect the manufacturer to
cover the cost of repairing or replacing the product. By analogy, a
software vendor should cover the cost for replacing software which fails
to perform its specified function, i.e. "The program crashed when I tried
to ...."
However, if software comes out which adds functionality rather than fixes
bugs, I see no reason why the vendor could not justify charging the full
rate to owners of previous versions.
I am not a software vendor myself, so I make no claims about the analogy
holding up, in fact I find practices in software quite different from
what one would expect in other industries.
Don Subt
Tandy Corp.
------------------------------
Date: 21 Jan 88 14:58:55 GMT
From: hao!noao!mcdsun!sunburn!gtx!al@boulder.colorado.edu (0732)
Subject: Offices versus Cubicles
reggie@pdn.UUCP (George W. Leach) writes:
>
> Is anyone aware of any empirical studies or experiments to determine
>the impact upon programmer productivity (or any related field) of providing
>offices with walls and doors and as opposed to cubicles?
>
>
I agree, cubicles provide a terrible environment for the kind of
concentration needed for programming.
In the September 1987 issue of COMPUTER, Barry Boehm, in an article
entitled "Improving Software Productivity", cites two studies that show
that "Private Offices" have provided "productivity gains" of 11%
and 8%.
You'd have to check the references (the book "Programming Productivity"
by T.C Jones, and the article "A Software Development Environment for
Improving Productivity" by Boehm et al, COMPUTER v.17 no.6 June 1984 pp
30-44) to see exactly what the studies mean by "Private Offices"
and what they are being compared to.
----------------------------------------------------------------------
| Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
| {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
----------------------------------------------------------------------
------------------------------
Date: 27 Jan 88 16:59:04 GMT
From: trwrb!aero!polack@ucbvax.Berkeley.EDU (Alexander J. Polack)
Subject: Offices versus Cubicles
I think in 1981 TRW conducted a study that demonstrated 40% productivity
improvement when the working environment is properly setup. Part of the setup
was providing individual offices to the software engineers.
Now, not all of the improvement came from the "individual office" setup,
but it did help.
For better details you should contact Dr. Barry Boehm at TRW.
- Alex Polack
------------------------------
Date: 25 Jan 88 14:48:07 GMT
From: fad@think.com (franklin a davis)
Subject: Separating Parts of Development
> It seems more appropriate to divide the process into three sections --
> functionality, *algorithm*, and implementation. In the previous approaches,
> the algorithm was not adequately serviced in either document, and was often
> divided between the two.
>
> QUESTION: Does anyone know of an approach which *does* deal with each part
> separately? I am hoping for material which is readily available (articles
> or books which are well known) rather than commercial products or obscure
> titles.
See "Software Engineering Concepts" by Richard Fairley, McGraw Hill
1985. Dr. Fairley was chairman of the faculty at the now-defunct Wang
Institute of Graduate Studies, School of Information Technology.
The book includes discussion of various life-cycle models,
as well as prototyping, planning, cost estimation, requirements
definition, design, implementation issues, verification & validation,
and maintenance.
It is a good overview of the issues of software engineering, with good
references for particular topics of interest.
--Franklin
------------------------------
Date: 27 Jan 88 21:51:05 GMT
From: hpcea!hpfcdc!hpesrgd!mic@hplabs.hp.com (Marc Clarke)
Subject: Separating Parts of Development
Try _Developing Structured Systems_, by Brian Dickinson, published by Yourdon
Press, 1133 Avenue of the Americas, New York, New York, 10036.
------------------------------
Date: Thu, 21 Jan 88 12:41:18 PST
From: PAAAAAR%CALSTATE.BITNET@MITVMA.MIT.EDU
Subject: Software Complexity Measures Will Never Be Accurate
[Note: this message was truncated on the right. I have guessed at
the missing pieces. --MSD]
uh2@psuvm.bitnet (Lee Sailer) writes
>[...]. In *today's* programming languages, there are too many
>pieces of required knowledge that are not coded, so complexity measures
>based on the code alone will be of limited accuracy.
>This bring to my mind two developments in CS theory.
>[...]
>SPECIFICATION LANGUAGES: The ideal spec. lang. would lead to the user
>making explicit all of the *unstated* assumptions about the process.
>Furthermore, research is moving towards specification which can be executed
>directly, omitting the coding step altogether.
>Disclaimer: I am interested in these ideas, but unread. If this sounds
>to you like something that someone has written, please send me the reference.
You might like to look into the "International Workshops on Software
Specificati[on]
and Design". Most of the major and minor workers in specification and design
contribute. They are sponsored by the IEEE, ACM SIGSOFT, the Alvey Directorate
i[n England.]
The IEEE Computer Society Press Publishes the "position papers" that are
submitted. The chairs of the working groups publish summaries and
conclusions in the "Software Engineering Notes" published monthly by the ACM
Spe[cial Interest Group on Software Engineering.]
Disclaimer: I am in favor of places where I publish things
- like the above mentioned workshops and periodicals.
Dick Botting
PAAAAAR@CCS.CSUSCC.CALSTATE(doc-dick) paaaaar@calstate.bitnet
PAAAAAR%CALSTATE.BITNET@CUNYVM.CUNY.EDU
Dept Comp Sci., CSUSB, 5500 State Univ Pkway, San Bernardino CA 92407
voice:714-887-7368 modem:714-887-7365 -- Silicon Mountain
"where smog of LA is blown away, and the sun shines bright all the day"!
------------------------------
Date: Thu, 21 Jan 88 08:59:05 EST
From: jhowatt@afit-ab.arpa (James W. Howatt)
Subject: Software Science Counting Strategy
We're doing some work here on maintainability metrics.
One of the ones we feel almost obligated to check out
is Software science measures. The code we're looking at
is avionics software written in Jovial J73. Does anyone
out there know of a published counting strategy (the
method of identifying operators and operands) for Jovial?
Thanks in advance for your help.
Jim Howatt (jhowatt@afit-ab.arpa)
[Those interested in software science should
be aware of previous comments in Soft-Eng pointing
to published evidence that software science is no
more effective as a metric than counting lines of code.
-- MSD ]
------------------------------
Date: 25 Jan 88 11:12:15 GMT
From: mcvax!oce-rd1!cup@uunet.uu.net (Hans Cuppen)
Subject: Training Courses for Software Management
Since I am employed in management software projects,
I would be interested to receive addresses of institutes,
where training courses for managing software projects are organized.
I am mainly interested in:
- Managing and / or controlling software projects
- Configuration management
_ Quality assurance
Thanks in advance
Please send your reaction to:
J.Cuppen
Horatiuslaan 25
5926 SJ VENLO
The Netherlands
or by electronic mail:
cup@oce.nl or {...,uunet}!mcvax!oce-rd1!cup
------------------------------
End of Soft-Eng Digest
******************************
-------