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