The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: paul.winalski@gmail.com (Paul Winalski)
Subject: [TUHS] Why did PDPs become so popular?
Date: Thu, 28 Dec 2017 10:59:29 -0500	[thread overview]
Message-ID: <CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com> (raw)
In-Reply-To: <20171228140551.B6F9418C079@mercury.lcs.mit.edu>

On 12/28/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Paul Winalski
>
>     > Lack of marketing skill eventually caught up to DEC by the late 1980s
>     > and was a principal reason for its downfall.
>
> I got the impression that fundamentally, DEC's engineering 'corporate culture'
> was the biggest problem; it wasn't suited to the commodity world of computing,
> and it couldn't change fast enough. (DEC had always provided very well built
> gear, lots of engineering documentation, etc, etc.)
>
> I dunno, maybe my perception is wrong?

I think you're right.  The disinterest in marketing and advertising
(Ken Olsen, and therefore DEC, had a "build it and they will come"
mentality) was one aspect of the corporate culture.  An example of its
negative impact:  When the Alpha EV5 came out, it was several times
faster than anything else around.  At the same time, Intel and AMD
were involved in the clock rate race.  Every time Intel leapfrogged
AMD, they trumpeted in the media (both trade and public) that they'd
produced the fastest microprocessor in the world.  DEC did nothing to
counter this false impression.

DEC's corporate culture also led to slow decision making.  DEC
believed in consensus building--everyone had to buy into a decision
before it was final.  We low-level DEC engineers used to joke that any
decision worth making was worth making ten times.  Consensus building
is great if you can reach a consensus, but terrible when you can't.
What was needed was something more like Sun's "lead, follow, or get
out of the way", or Intel's "disagree and commit".

DEC was also prone to over-engineering its products.  This slowed down
time to market and also increased production costs.  It's true that,
particularly in software, spending extra time in design up front pays
back in reduced maintenance costs down the road, but if you can't get
V1.0 out the door within its market time frame, there will never be a
V2.0.

-Paul W.


  reply	other threads:[~2017-12-28 15:59 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-28 14:05 Noel Chiappa
2017-12-28 15:59 ` Paul Winalski [this message]
2017-12-28 16:08   ` Larry McVoy
2017-12-28 23:28     ` Theodore Ts'o
2017-12-29 11:04       ` Kevin Bowling
2017-12-29 23:35         ` Jon Forrest
2017-12-29 23:58           ` Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2017-12-31  5:20 Rudi Blom
2017-12-31 12:56 ` Clement T. Cole
2017-12-31 15:03   ` Steve Simon
2017-12-29 16:38 Larry McVoy
2017-12-29 23:54 ` Kevin Bowling
2017-12-30  0:04   ` Larry McVoy
2017-12-30  0:54   ` Lawrence Stewart
2017-12-30  1:47     ` Kevin Bowling
2017-12-30  2:19       ` Lawrence Stewart
2017-12-30  2:35         ` Paul Winalski
2017-12-30  2:20       ` Paul Winalski
2017-12-31  2:47     ` Henry Bent
2017-12-30  1:07   ` Ron Natalie
2017-12-30  2:30     ` Paul Winalski
2017-12-31  3:00       ` Henry Bent
2017-12-31  9:59         ` Arrigo Triulzi
2017-12-31 15:55         ` Paul Winalski
     [not found] <109152082.5216233.1514413535270.ref@mail.yahoo.com>
2017-12-27 22:25 ` Dave Ritchie
2017-12-27 22:32   ` Dave Horsfall
2017-12-27 23:44     ` Paul Winalski
2017-12-27 23:38   ` Kevin Bowling
2017-12-28  0:07     ` Paul Winalski
2017-12-28  0:45       ` Kevin Bowling
2017-12-28  1:39       ` Ron Natalie
2017-12-27 21:02 Alec Muffett
2017-12-27 21:50 ` Grant Taylor
2017-12-28  1:23   ` Alec Muffett
2017-12-27 21:51 ` Clem Cole
2017-12-27 21:52   ` Clem Cole
2017-12-28  2:14   ` Greg 'groggy' Lehey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABH=_VQBjinz7RsathpQ5-DOAuHv+eSuQEiMQXnnwxOgyTPNHA@mail.gmail.com' \
    --to=paul.winalski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).