brett@LOCUS.UCLA.EDU (Brett Fleisch) (09/03/85)
> 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. > 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 brett@LOCUS.UCLA.EDU {...sdcrdcf, ihnp4, trwspp, ucbvax}!ucla-cs!brett -------------------------------------------------------------------------
guy@sun.uucp (Guy Harris) (09/06/85)
> > 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. 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
karsh@geowhiz.UUCP (Bruce Karsh) (09/07/85)
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 <2762@sun.uucp> guy@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
root@bu-cs.UUCP (Barry Shein) (09/09/85)
Re: problems with companies charging to chat with SEs about problems 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@umcp-cs.UUCP (Chris Torek) (09/09/85)
>Re: problems with companies charging to chat with SEs about problems >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@LOCUS.UCLA.EDU (Brett Fleisch) (09/09/85)
> From: guy@sun.uucp (Guy Harris) > Subject: Re: Masscomp > Date: 6 Sep 85 06:54:28 GMT > To: unix-wizards@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@LOCUS.UCLA.EDU {...sdcrdcf, ihnp4, trwspp, ucbvax}!ucla-cs!brett -------------------------------------------------------------------------
jbn@wdl1.UUCP (09/16/85)
This is more of a problem in the middle range of systems. With the big mainframes, one has the manufacturer's system engineers available; there are often a few on site. With the PC-class machines, one has independent product reviews in the trade magazines, and critics like Pournelle. But in the middle, in the range from the Sun to the Pyramid, we have neither. Of course, we do have the net. John Nagle
dan@neuro1.UUCP (Dan Johnston) (09/19/85)
We would like to provide an alternate experience. Overall, we are
quite satisfied with our 2 masscomp systems. Yes, we have had problems
and frustrations, but masscomp has been very responsive to our needs.
Service has been wonderful, our local salespeople have done everything
possible to make us happy, and we have had open communications with
corporate headquarters, including conversations with several vice
presidents (I even spoke to the CEO once).
That is not to say that masscomp is without faults. For example,
their choice of a mux was awful, the original monochrome graphics
station was unreliable, and they were slow bringing out their promised
floating point and array processor boards. One could argue that perhaps
they have tried to do too much for a small company--real time data
acquisition, proprietary floating point and array processor boards, and
graphics--and that this is why bugs in some products are more numerous
than one would like. Nonetheless, I believe that they have excellent
engineering and they are dedicated to bringing state-of-the-art products
to market at reasonable cost.
One must keep in perspective that they were one of the first and
still one of the few to do real time A/D under un*x, and their 1 M Hz
sampling rate is hard to beat. The floating point performance has been
improved by a factor of about 20 since we bought our system (Jan 84)
through the addition of floating point hardware and improved fortran
environment, and they appear dedicated to continue to do so. Ethernet
is up and running between our two systems, and we have experienced no
problems. We have bench marked (our programs) on a number of un*x
systems in the same price range, and masscomp still looks good even
though the CPU is nearly obsolete (68010). They will be announcing new
hardware shortly that should put them nearly in a class by themselves in
price/performance.
In summary, we do not share your experience with masscomp. We are
quite pleased and will probably be buying their new generation equipment
in the near future. They are a good company suffering from the ills of
newness. We are happy to have an alternative to DEC for laboratory
computers. Anyone wish to trade DEC war stories?
dan johnston
dept of neurology
baylor college of medicine
ihnp4!shell!neuro1!dandan@neuro1.UUCP (Dan Johnston) (10/02/85)
Because of the recent discussion about masscomp in this newsgroup, I
thought that there might be some interest in excerpts from an Oct. 1
newsrelease from them:
"MASSCOMP INTRODUCES INDUSTRY'S FIRST FAMILY OF MICRO SUPERCOMPUTERS..."
"MASSCOMP 5000 Family Provides Million Dollar Computing Capability for
Between $15,000 and $250,000; New Class of Computer Uses Technological
Innovations to Provide Affordable, Distributed Supercomputing
Performance..."
"Five Systems and Nine Models Offer A Wide Range of Computing
Capability..."
"The new micro supercomputers are compatible with a wide array of
software programs used by scientific and technical users. Two of the three
buses are "open" standards Multibus (TM) and STD+Bus (TM) (based on the
STD bus). This makes it easy for customers to mix and match equipment for
MASSCOMP and other vendors. Because the new micro supercomputer family's
operating system is UNIX (TM) based, an abundance of application-level
tools widely used by scientists and engineers are available. The new micro
supercomputers work with popular technical and scientific languages such as
C, ANSI-validated FORTRAN, ANSI-validated Pascal-2 (TM), Franz LISP and
Assembler and support two of the industry's most widely accepted network
communications standards: Ethernet TCP/IP, and X.25..."
"Key to the new micro supercomputers' power are several hardware and
software technological innovations. These include a triple bus architecture
design that gives technical users three optimized data paths (thus more
highways to move information); a high performance floating point arithmetic
processor called "Lightning;" a two-way associative cache that speeds up
computation by managing memory references in parallel fashion and an
enhanced version of UNIX, RTU (TM) (Real-time UNIX), compatible with both
AT&T UNIX System V and Berkeley 4.2BSD..."
"The MASSCOMP 5000 family micro supercomputers provide up to one million
samples per second data acquisition sampling rates and offer performance
ranges of .7 to 10MIPS (million instruction per second); 625,000 to over
12,000,000 Whetstones per second; and up to 13 MFLOPS (million floating
point operations per second). These three performance measures are the
industry's most popular ways to measure computing speed..."
dan johnston
baylor college of medicine
ihnp4!shell!neuro1!dan