Re: Thoughts on the book: DEC is dead, long live DEC

Sharon wrote:

....

Manufacturing wasn't too concerned about efficiency, and it seemed that
throughout DEC, money was no object and they were perfectly happy making
high cost items as long as they were also high quality. There were too
many plants around the world and no real central controls (remember
those independant kingdoms).

Indeed, the priority was quality at any cost.

I'm afraid that while the statement you quoted is flat-out wrong (cost was *never* irrelevant), your own response is simply meaningless. 'Quality' is a continuum, and as any engineer can tell you there is *always* a trade-off with cost made along that continuum.

Perhaps what you were trying to say was that there was a quality threshold below which a product was considered unacceptable (i.e., below which quality would not be further traded off for low cost).

It shows how idealistic
that Olsen was.

No, it shows what he had learned over more than two decades of outstanding success in his chosen field: that innovative high-quality products at fair prices sell well. The only problem was the appearance of what people now like to call disruptive technology that changed the rules by enabling the creation of lower-quality products at lower cost (whereas before you just couldn't save all that much no matter how much quality you sacrificed).

Had Olsen had the foresight to embrace the PC for what it was rather than forge ahead with what had suddenly become an out-dated vision of low-end computing, the subsequent history of DEC would likely have been quite different. But it's not clear that even then DEC could have *built* PCs at competitive prices: it just didn't know how and would have found it difficult to learn - OEMing boxes from someone who already had that knowledge would have been the most feasible approach, and would have allowed DEC to concentrate on the unique value it could *add* to the PC by integrating it into a business framework backed by DEC minis.

Just as inexpensive 16-bit PCs were the (disruptive) killer micros of the first half of the '80s, inexpensive 32-bit workstations were the (disruptive) killer micros of the second half. But while the underlying disruptive technology was similar, the guise was sufficiently different that DEC got blind-sided again: whereas it was easy to ruefully write off its PC debacle as due to the market clout of the IBM brand, these new workstations were built by no-name upstarts out in Silicon Valley and ran software that could not hold a candle to VMS.

But they were cheaper and/or faster, both powerful inducements to workstations users who would cheerfully put up with some idiosyncrasies if the alternative were to have no workstation at all. I've never looked at the numbers, but I suspect that DEC didn't sell all that many fewer workstations than ever - just that the total number of workstations in the industry exploded, and that DEC's relative market (and mind) share therefore eroded.

All this is much easier to see in hindsight, of course, where we have the Awful Example to make it clear that the so-often-prudent course of sticking to one's highly-successful knitting was the wrong choice (at least in those two significant areas) during that decade. Even so, if DEC had been able to manage its growth and field a competitive RISC VAX-replacement significantly earlier it *still* could have remained healthy despite the major losses its abortive PC efforts cost and the erosion of its workstation markets.

But given the degree to which internal turmoil reigned, it could do neither. As I said earlier, I have no idea whether Olsen could have pulled DEC out of its tailspin had Doriot been around to help - and I think people despise Palmer not because they think that he destroyed a healthy company but because he made so many obviously-bonehead moves (also demonstrating a complete lack of appreciation for what he had to work with) that accelerated DEC's decline. Could Olsen, even without Doriot's help, have done any *worse*? I tend to doubt it, unless he was completely fed up with having to deal not only with the problems of the company itself but with a BoD that didn't have a clue and wouldn't give him room to find a good solution.

Perhaps I give him too much credit, but I think he earned it over his first 25 years at the helm, whereas I don't see where the Monday-morning quarterbacks ever earned much of any at all.

Along with the lack of central controls, they had no way for the geographically-disperse groups to communicate. I'm not sure why that was, I don't remember if the author analyzed it. (After all, was this before WAN's and All-In-1 or VaxNotes?)

No, it was not. IIRC DEC facilities (and most of the employees in them) were connected world-wide by 1980 at the latest. VAXnotes use was rampant in the early (I think *very* early) '80s (an outgrowth of its predecessor Notes-11, though I don't remember that being all that wide-spread). I tried to Google up exact dates, but (somewhat surprisingly, at least to me) the closest I got was a tentative reference to 1980 as the birth date of VAXnotes. All-In-1 was created in the same time-frame (didn't find an exact date for that, either - again, I was surprised, but I didn't look that hard: too many memories of what a pig that product was before hardware advances made that more irrelevant - a foretaste of Microsoft bloatware well ahead of its time).

- bill
.

Relevant Pages

  • Re: MB reliability
    ... it creates a lower quality product, but for the business it is good. ... cost of production of the vehicle, which for them is too expensive, and ... Compared to the US, Mercedes pays ... technology in their cars, but that isn't the whole story. ...
    (alt.auto.mercedes)
  • Re: How do you make decisions that optimize software quality?
    ... > total cost of development and deployment - that means, ... due to the defects, which in turn cascades into lost sales, etc. ... The second limb of this is that code quality directly affects ... Executable acceptance tests. ...
    (comp.object)
  • Re: How do you make decisions that optimize software quality?
    ... > total cost of development and deployment - that means, ... due to the defects, which in turn cascades into lost sales, etc. ... The second limb of this is that code quality directly affects ... Executable acceptance tests. ...
    (comp.lang.java.softwaretools)
  • Re: more lockup laptop problems with dapper
    ... The quality of the participants is the biggest factor. ... Other products are subsidized through cost shifting. ... deliver money and folks to apply for and get money. ... them to deliver money to developers. ...
    (Ubuntu)
  • Re: MB reliability
    ... it creates a lower quality product, but for the business it is good. ... cost of production of the vehicle, which for them is too expensive, and ... Compared to the US, Mercedes pays ... technology in their cars, but that isn't the whole story. ...
    (alt.auto.mercedes)