Masscomp

Brett Fleisch brett at LOCUS.UCLA.EDU
Mon Sep 9 22:15:24 AEST 1985


> From: guy at sun.uucp (Guy Harris)
> Subject: Re: Masscomp
> Date: 6 Sep 85 06:54:28 GMT
> To:       unix-wizards at brl-tgr.arpa

>>>      If you are having problems with software bugs, they will let you talk
>>>      to a software engineer If you are covered under a software contract.
>>>	 ... 
>>>      If you are not covered under a service contract, they will also let
>>>	 you talk to a software engineer, for $80/hr.
>> 
>> This is a very bad company policy.  The objective of a small growth
>> company is to develop/adapt software for their special purpose hardware
>> that customers are satisfied with.  Bugs, which are inevitable, should
>> be corrected.  In this case, the company is discouraging them 
>> from being discussed by having an 80.00/hr fee.

> The objective of a small growth company is to make money.  If all your
> software engineers are tied up saying "RTFM" to customers, this makes it
> harder to make money.  The $80/hr fee is a price for a service, and serves
> to cut the demand so that it matches the supply of that service.  In this
> case, it tempts people to save themselves money by actually Reading The
> Manual before bitching to the vendor's technical support people.

> ... more stuff here "re: using fee to discourage dumb questions"
> ...
> ...
>	Guy Harris

I dont understand how you jumped to the conclusion that the 80.00/hr
fee was a way for the company to encourage people to read the manual
and thus to discourage "dumb" questions.  Since we have no 
public figures on the ratio of people on-contract to those 
off-contract, for all we know the 80.00/hour fee does 
exactly the wrong thing, like I suggested:

	Organizations less familiar with the underlying software
	buy the contract and get the right to talk to an SE
	with "dumb" questions.

	Organizations more familiar with the underlying software
	choose not to buy the contract because of their extreme
	familiarity with the software.  Nontheless, they get the
	talk to an SE for 80.00/hour who tells them to send a written
	report in.

In short, I claim the argument the company will be more productive because
of the 80.00/hour fee is fallacious.  If you'd care to cite specific
ratios for service contract/non-contract and try your argument
again then maybe I'd be persuaded.  If we assumed a 50/50 ratio, then 
you'd still have a good percentage of "RTFM"s to give out to 
"on-contract" people.  If we assume 80/20 then you're talking
many, many fewer "RTFMs" for "off-contract" people
and the fee probably does more harm than good - discouraging
important bug reports.  Nontheless, if you believe in constant
number of "RTFM"s, the company is much worse off in the 80/20
ratio.  

Thus, saying an 80.00/hour fee decreases the number of "dumb"
reports makes little sense if there are a very small percentage
of clients "off-contract".  What it does is discourage "useful" 
bug reports - which even a small number of - may be very useful 
for improving the underlying product.

My statement:
>> This is a very bad company policy.  The objective of a small growth
>> company is to develop/adapt software for their special purpose hardware
>> that customers are satisfied with. 

and yours:
> The objective of a small growth company is to make money. 

shows another fundamental disagreement.  What my statement tries
to indicate is market-share is the most important issue for
a growth computer company.  But I think that is beyond the scope 
of this group.

Sorry, this has drifted a bit from the main topics of this group.
I would be very interested in knowing what the average ratio of
clients on-service-contract to not-on-contract are nowadays.  I'm 
sure a  number of people who read this group would be interested as well.
--------------------------------
Brett Fleisch
University of California Los Angeles
LOCUS Research Group
3804-f Boelter Hall
Los Angeles, CA 90024
Phone: (213) 825-2756, (213) 474-5317 

brett at LOCUS.UCLA.EDU
{...sdcrdcf, ihnp4, trwspp, ucbvax}!ucla-cs!brett
-------------------------------------------------------------------------
 



More information about the Comp.unix.wizards mailing list