Masscomp
Brett Fleisch
> to a software engineer If you are covered under a software contract.
> The software engineer will politely tell you that you are experiencing
> a software problem and that you should send in a Software Quality
> Report.
> If you are not covered under a service contract, they will also let you
> talk to a software engineer, for $80/hr. They first ask you for a
> purchase order number to bill to.
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.
What happened to the old days when people would pay you to find
bugs? Remember Knuth Vol 1, 2, & 3? Didn't Knuth offer $0.25
per error?
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
br...@LOCUS.UCLA.EDU
{...sdcrdcf, ihnp4, trwspp, ucbvax}!ucla-cs!brett
-------------------------------------------------------------------------
Guy Harris
> > to a software engineer If you are covered under a software contract.
> > you talk to a software engineer, for $80/hr.
>
> 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.
I think Masscomp is no longer at the stage where they can afford to hold
every single customer's hand. Back when a small growth company is *very*
small, it has considerably fewer customers, and they are taking a flyer on
that company's products and are more likely to be technically knowledgable.
As the company grows, it gets more calls from people who ask "why won't my
screen come on?" when they haven't plugged the machine in, or ask why the
machine is just typing everything back at them when they've just typed
<commands>; grep
instead of
<commands> | grep
or other such questions. These questions need not even be "dumb", but
they're not the appropriate thing to bug a developer with.
Also, developers tend to get *very* grouchy and unproductive if they end up
having to deal with a question which really *is* dumb; grouchy and
unproductive developers tend not to develop products which help the small
growth company make money.
Yes, it's not as nice as having a direct hotline to the developers. Nobody
ever said that life was fair. (Also note that Knuth is far less likely to
be bothered by naive questions or comments about spelling errors - it's not
an appropriate comparison.)
Guy Harris
Bruce Karsh
In a previous article, I complained about some problems that we
were having with a computer system at our site. From the responses I
received I have come to understand what a difficult problem the
computer manufacturers have.
This is a topic that is of concern to unix-wizards, even though
it doesn't concern i-nodes, uucp, or group permissions. Nearly
all wizards must take either in the manufacturers' position or the
customers' position, depending on the nature of the problem.
In article <27...@sun.uucp> g...@sun.uucp (Guy Harris) writes:
>
>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.
This is a real problem. There are a lot of users out there who
can not read the manuals. Certainly, they should have to pay for
consulting help.
But what about cases where the customer has found a problem (i.e.
a system bug, read the manual carefully in order to determine
that the problem actually is a bug, and carefully characterizes
the problem to the point where the problem can be reproduced
at the factory. It seems clear to me that it would be a big
mistake for companies to treat these kinds of reports the same way
as they treat "why does my Fortran compile give me all these
error messages?" type reports.
This is definitely a problem for the computer companies. It takes
time to determine whether a problem is a real bug, or an RTFM.
And time is money; big money in the case of software engineers.
Can a cursory inspection of a problem report reliably separate RTFM's
from bugs? How are the various computer companies handling the problem?
Secondly, what should a manufacturer's responsibilities be in the
case of software failures. In the case of hardware failures,
almost all companies have the same policy: fix it quickly. In the
case of IBM mainframes, "quickly" normally means within hours.
In the case of minis, quickly usually means within a couple of
days. Of course, if you don't have a service contract, they will
charge a lot for repairs. But you can still get them done pretty
rapidly.
But broken software is fundamentally different from broken hardware.
First, hardware problems are usually component failures and are
repaired by replacing failed components with standardized interchangable
parts. Wouldn't it be nice if we could do this with software? ( I.e.,
"This loop is broken. Let's see if we have another one in the supply
room." ) Secondly, hardware failures are not normally design failures.
Software failures are always design failures. Thus they require a much
deeper understanding of the whole system in order to repair them.
On the other hand, from the point of view of the user, a software
failure is as damaging as a hardware failure if they both prevent you
from doing what you need to do. Thus the user needs the same kind
of response to both kinds of failure.
So the question is, should manufacturers repair software failures
with the same rapidity as they do hardware failures?
--
Bruce Karsh
U. Wisc. Dept. Geology and Geophysics
1215 W Dayton, Madison, WI 53706
(608) 262-1697
{ihnp4,seismo}!uwvax!geowhiz!karsh
John Gilmore
> What happened to the old days when people would pay you to find
> bugs?
What happened is that people started running Unix, which comes with as
many bugs as you care to find, and no support.
Since AT&T doesn't seem to do maintenance releases, preferring instead
to generate an entirely new version of Unix every time they make a
release, even if they do take the time to fix bugs (I don't know if
they do), the fixes don't make it into customers' hands for many years --
until each manufacturer decides to upgrade from "system 1 release 0"
(which they know and have hacked over til it mostly works) to "system 5
release 2 version 2" or whatever (which is an unknown).
Barry Shein
versus them getting swamped with non-problems.
I agree with both sides (hey, just when I am ready to rip the damn
phone out of the wall it rings to tell me something real is up!)
The obvious solution for a company is to hire some lower-level people
and charge a reasonable fee to be able to let them listen and screen
problems. Even better, limit a site to a few designated people who can
use the service, so problems get one more filtering.
I prefer the method of reducing as many problems as possible to a
reasonable price. $80/hr is steep and open ended, what would your
reaction have been if it were $100/month so you could just budget it?
Usually the last sound before a 'CLICK' that someone hears from me
when they say they don't want to pay anything for a service is:
"If it aint important to you, then it aint important to me either."
-Barry Shein, Boston University
Chris Torek
>versus them getting swamped with non-problems.
>The obvious solution for a company is to hire some lower-level people
>and charge a reasonable fee to be able to let them listen and screen
>problems. Even better, limit a site to a few designated people who can
>use the service, so problems get one more filtering.
How about simply dropping the charge if it's a true problem?
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland
Brett Fleisch
> Subject: Re: Masscomp
> Date: 6 Sep 85 06:54:28 GMT
> To: unix-w...@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.
--------------------------------