Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!olivea!oliveb!pyramid!athertn!hemlock!mcgregor
From: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Newsgroups: comp.software-eng
Subject: Re: some advice to a software engineer (let's get real)
Message-ID: <31216@athertn.Atherton.COM>
Date: 2 Oct 90 00:32:24 GMT
References: <1161@dms.UUCP> <31112@athertn.Atherton.COM>
Sender: news@athertn.Atherton.COM
Reply-To: mcgregor@hemlock.Atherton.COM (Scott McGregor)
Organization: Atherton Technology -- Sunnyvale, CA
Lines: 68

In article <1161@dms.UUCP>, albaugh@dms.UUCP (Mike Albaugh) writes:

> 	Is there some sort of Software Engineer's code of ethics that
> _requires_ games to be singled out as the canonical "who cares" product?

I certainly don't mean to claim that "game" software IS buggier, only
that the financial repercussions of a missed bug in a game is frequently
less than in the case of life and mission critical software.  Therefore
companies who produce the latter sorts of software MUST demonstrate
a certain level of committment in their QA processes.  Even with these
committments, they may be less effective in finding bugs than a
game manufacturer who tries to make the reliability of their games
a key differentiator.  But the response to shipped  bugs may have to be
different-- the game company MIGHT offer an alternate game if sales
of the original are so low that fixing it is not meritted.  A seller
of a medical system may not have the alternative of offering a
distinctly different kind of system if a patient dies due to a
failure in one system--they might face a law suit instead.  In any case,
features of their markets help determine what will and will not be
successful tradeoffs between functionality, quality and timeliness.

Game software isoften notably superior to most other software in that it
pays lots of attention to quick learning time, low documentation,
and other human factors aspect, but it often does so by providing
a more limited set of controls and displays.  Other software may pay
less attention to this area in order to focus the developers on other
key aspects
for that market, such as rich functionality (aka baroque embellishment), etc.

> I would point out that in 14 years of working on games, I have had (and
> observed in the work of my peers) about the same bug density as found
> in the Gnu C compiler, and a significantly _lower_ density than in
> any of the "shrink wrap" software I have ever used. Perhaps this has to
> do with the fact that when we have a "real bug" (as opposed to a feature
> we included that may not meet _some_ customer's expectations) _we_ often
> eat the cost of sending out ROMS with the fix. We _may_ charge for the
> ROMS, (i.e. media and handling), but we do _not_ follow the "commercial"
> practice of charging > 60% of the "new" cost of a software package to fix
> what were our mistakes to begin with. In other words, "Lighten up dudes" :-)

This may be a reason, but I think there may be others too.  What you
are saying is that game consumers judge the product based upon whether
they have an enjoyable time, and if the software malfunctions in a certain way
(like it bombs just after starting, or lose the score at the end) this
may have such serious financial impacts that it is important to set
things right by sending new ROMS.  Other markets (e.g. freeware or
shrinkwrap software) very probably do have other concerns.

One of the big differences for many shrinkwrap software products is
that many such products are purchased based upon functionality comparison
checklists.  If your product doesn't have more functions than your
competitor, you may lose a lot of business.  This causes such software
to skew toward more functionality than most games, and sometimes
quality is what gives, other times (especially for major vendors like
Lotus and Microsoft) schedule may give too.

> 	If Lotus/uSoft/etc were to have a similar bug-fix policy, I
> suspect that a) they would be a bit more careful about testing _before_
> they ship :-) and b) they would ship even less frequently and at even
> higher prices than they do now :-( TANSTAAFL
> 
If they had such a policy, with such results, they might very well
lose their positions in their markets to competitors who were more
accurate at meeting that market's specific needs for timeliness, and
cost.


Scott McGregor