Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site unc.UUCP
Path: utzoo!linus!decvax!mcnc!unc!sherouse
From: sherouse@unc.UUCP (George W. Sherouse)
Newsgroups: net.micro
Subject: Re: How SPRs are handled
Message-ID: <6743@unc.UUCP>
Date: Sun, 12-Feb-84 09:25:22 EST
Article-I.D.: unc.6743
Posted: Sun Feb 12 09:25:22 1984
Date-Received: Tue, 14-Feb-84 01:20:48 EST
Organization: CS Dept., U. of N. Carolina at Chapel Hill
Lines: 65

I tried to mail this, but it wouldn't go:

> Sorry, not an Arpanet gateway!
> 
> 
> *--------------RETURNED MESSAGE---------------*
> 
> Date:     28 Jan 84 23:39:48-EST (Sat)
> To: jsweet%uci-750a%rand-relay@sri-unix
> References: <15895@sri-arpa.UUCP>

Note the confused look on my face.

On rereading it, it seems sufficiently general for the net, so here goes...

----------

Two comments:

1)  I have had a very similar experience with the Manx Aztec C for Apple.
(Yours wasn't a problem with long integers was it?  If not, be forewarned.)
I find this sort of sloppy (non)support of paying customers frustrating as hell
and say so every chance I get.  But, golly, isn't that compiler nice? (... I
mean the parts that work...)

2) I used to be on the other side of this.  I had a stack of SPRs, some dating
back 4 years, quite neatly filed away awaiting responses.  For the most part,
the ones that were older than six months were part of my orientation package
when I joined the company.  By the way, this was not a micro company and it is
highly unlikely that you would ever have had any dealings with them, their
market being extremely specialized.  Anyway, it can happen that SPRs don't get
answered because they are a) not serious enough to worry about right now or
b) too difficult to worry about right now.  In many cases the same staff who
generate new software are the ones who also have to answer the SPRs.  New
applications bring in new money, answered SPRs do not (directly).  Hence, the
attitude of management is easily predicted.  In my case, if I couldn't deal
with an SPR directly, I tried to at least fix it for the (inevitable) next
release and send along a friendly letter closing the SPR then, also suggesting
that it might be worth the customer's while to get the new release for a
nominal charge.  This tended to keep everyone relatively happy.  Incidentally,
it really is a no-win situation for the software house.  If you assign your
(always insufficient) staff to chasing SPRs, you don't get the updates out and
everybody gets upset.  I noticed that it is usually the same customers who
squeal loudest about minor bugs who also squeal loudest when a promised release
is late.  And so it goes...

In short, as a consumer I want service yesterday.  But, having been on the
other side I know why I'm not getting it.  Not that that helps.

-------------------------

I would add that the software I was involved with was an *applications*
package.  In general I think it is more critical that *systems* software
like OSs and compilers be serviced in a timely fashion.  Of course,
this is a wild generalization which ignores the realities of, say,
factory-automation software and the like.  But from the software developer's
perspective, if your tools don't work you might as well go home.
In this respect, kudos to S&H Software (of TSX fame) and rude noises
to Manx.


<< The views expressed are my own and should be everyone else's.  >>

(the real) George W. Sherouse