16 Jan
2019
16 Jan
'19
4:55 p.m.
On 1/16/19, Kevin Bowling <kevin.bowling(a)kev009.com> wrote:
I’ve heard and personally seen a lot of technical
arrogance and
incompetence out of the Masshole area. Was DEC inflicted? In
“Showstopper” Cutler fled to the west coast to get away from this kind of
thing.
Having worked at DEC from February 1980 until after the Compaq
takeover, I would say that DEC may have exhibited technical arrogance
from time to time, but certainly never technical incompetence. DEC's
downfall was a total lack of skill at marketing. Ken Olsen believed
firmly in a "build it and they will come" philosophy. Contrast this
with AT&T's brilliant "Unix - consider it a standard" ad campaign.
DEC also suffered from organizational paralysis. KO believed in
decisions by consensus. This is fine if you can reach a consensus,
but if you can't it leads to perpetually revisiting decisions and to
obstructionist behavior. There was a saying in DEC engineering that
any decision worth making was worth making 10 times. As opposed to
the "lead, follow, or get out of the way" philosophy at Sun. Or
Intel's concept of disagree and commit. DEC did move towards a
"designated responsible individual" approach where a single person got
to make the ultimate decision, but the old consensus approach never
really died.
Dave Cutler was the epitome of arrogance. On the technical side, he
got away with it because his way (which he considered to be the only
way) was usually at least good enough for Version 1, if not the best
design. Cutler excelled in getting V1 of something out the door. He
never stayed around for V2 of anything. He had a tendency to leave
messes behind him. A Cutler product reminded me of the intro to "The
Peabodys" segment of Rocky & Bullwinkle. A big elaborate procession,
followed by someone cleaning up the mess with a broom.
Cutler believed in a "my way or the highway" approach to software
design. His move to the west coast was to place himself far enough
away that those who wanted to revisit all his decisions would have a
tough time doing so.
On the personal side, he went out of his way to be nasty to people, as
pointed out elsewhere in this thread. Although he was admired
technically, nobody liked him.
-Paul W.
16 Jan
16 Jan
5:14 p.m.
On Wed, Jan 16, 2019 at 11:55 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
... Cutler excelled in getting V1 of something out the
door. He never
stayed around for V2 of anything. He had a tendency to leave
messes behind him. A Cutler product reminded me of the intro to "The
Peabodys"
segment of Rocky & Bullwinkle. A big elaborate procession,
followed by someone cleaning up the mess with a broom.
One of the first times I met him, was during an argument that Fossil
remarked to something like: 'Dave, why do you care. You'll be doing
something else and these guys have to make it work.' I've never forgotten
the look DC gave Roger. He was (is) just not good at listening. And
that is to me, the best example of his arrogance. He was quick to point out
other's bad ideas; but I don't think he ever looked back and said --
"We'll
that was a bad idea *I made*. *I (even we) called that one wrong*."
That said, to Dave's credit by the time of Tru64 and he had left for MSFT,
everything at DEC had to be 'perfect' before it would ship. And thus things
were late or never made it out the door. DC's magic was getting to the
nut of the problem and getting what people cared about implemented quickly
and out for users to try it. The problem was his scheme, was that he was
never part of the team that fixed it later. I think I would have had
more respect if he had quickly gotten the product out and then said, 'ok,
we took these short cuts. Let's fix them' But as you pointed out, Dave
never seems to see them as short cuts. He was 'done.'
And when I think about engineers that I really respect, are the ones that
can get the first version out the door with that want matters, then work as
to polish it and make them better. This means listening to the users and
other developers and really taking input from other people. i.e. listening.
Clem
ᐧ
5:33 p.m.
On Wed, Jan 16, 2019 at 12:14:30PM -0500, Clem Cole wrote:
DC's magic was getting to the
nut of the problem and getting what people cared about implemented quickly
and out for users to try it. The problem was his scheme, was that he was
never part of the team that fixed it later. I think I would have had
more respect if he had quickly gotten the product out and then said, 'ok,
we took these short cuts. Let's fix them' But as you pointed out, Dave
never seems to see them as short cuts. He was 'done.'
Ah, yes, the 1.0 person. That's a nice gig if you can get it, but it is
rare that a company will put up with it. The fact that DEC did sort of
indicates a broken engineering culture.
Sun, at least when I was there, would never put up with that. If you
pushed something out the door you were expected to stick around and
do the dot dot releases that fixed it before you got to move on to
the next thing. That was just part of the culture when I was there,
I sort of thought they over did it and people sort of polished the
turd forever. I escaped that by focussing on performance, that let
me bounce all over the place, which was fun.
--lm
5:29 p.m.
On Wed, Jan 16, 2019 at 11:55:03AM -0500, Paul Winalski wrote:
DEC's downfall was a total lack of skill at
marketing.
I have a different view, having been at Sun when Sun was eating DEC's
lunch. Sun made stuff that was just as good as what DEC built but they
were cheaper. DEC couldn't adapt to decent machines that didn't cost
a big pile.
History repeats itself, Sun couldn't wean itself off $20,000 workstations
when you could get an almost as fast PC for 1/4th or less of that price
point.
I think perhaps the problem is that companies like that get big revenue
and can afford to do crazy amounts of engineering. Then the market
shifts and they can't really shift with it, they tell themselves they
don't want to ship junk.
6:13 p.m.
On Wed, Jan 16, 2019 at 12:30 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Wed, Jan 16, 2019 at 11:55:03AM -0500, Paul
Winalski wrote:
I think you are both right actually and in some ways saying the same
thing. I refer to this as the economic of solution argument. It's right
out of Clay Christensen <http://www.claytonchristensen.com/>'s book The
Innovator's Dilemma
<https://www.amazon.com/Innovators-Dilemma-Technologies-Cause-Great/dp/1565114159>
The problem as Larry point out, is that when some one else does something
that is economically a better solution, it is marketing jobs to understand
that. and help lead the company with products that work. The problem is
that marketing rarely says, "We need to eat out own lunch/children ...
etc." Instead they talk to customers who tell them make XXX for their
futhure more specialized and higher end system, which of course has higher
margins. I worked with a VP that once said: "I'd rather sell a $100K
system then a $10K one, because the cost of sale is the same." What he
did not realize is that Sun was selling 20 systems for $10k, while DEC (or
Masscomp) sold one at $10k.
Clem
ᐧ
DEC's downfall was a total lack of skill at
marketing.
Sun made stuff that was just as good as what DEC built but they were
cheaper. DEC couldn't adapt to decent machines that didn't cost a big
pile.
History repeats itself, Sun couldn't wean itself off $20,000 workstations when
you could get an almost as fast PC for 1/4th or less of that price point.
6:24 p.m.
On Wed, Jan 16, 2019 at 01:13:30PM -0500, Clem Cole wrote:
The problem as Larry point out, is that when some one
else does something
that is economically a better solution, it is marketing jobs to understand
that. and help lead the company with products that work.
I'm sure I'm not alone in being an engineer that was interally very
critical of our own products (didn't matter which company). It is a
HUGE mistake to let engineers even hear their own marketing.
Marketing is, if not outright lieing, a lot like a first date. You put
the best version of you possible forward, you leave all the other crud
in the closet.
Engineers need to be running benchmarks, seeing how hard/easy it is to
build X11, they need to be looking for the places their products are
weak instead of listening to marketing talking about the places where
the product is strong.
I took no end of shit for doing exactly that, people thought I was
disloyal. Which is rubbish, you can't fix your crap until you face it.
Doesn't matter, seems like all engineering orgs fall into the trap of
believing their own marketing. If I were still looking for work that
would be a red flag.
Getting back to TUHS, it's interesting to note that Unix has prevailed, in
spite of many companies doing their best to "improve" it out of existence.
Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as I know, but
the basic Unix model lives on in Linux. I wish one of the decent Unix
variants was still vibrant just so Linux doesn't get complacent.
2 Feb
2 Feb
2:34 p.m.
On 2019-01-16 6:24 pm, Larry McVoy wrote:
Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as
I know, but
the basic Unix model lives on in Linux. I wish one of the decent Unix
variants was still vibrant just so Linux doesn't get complacent.
I have to ask -- which of the old Unix variants do you consider decent,
and why? :)
-- fao
PGP fingerprint: 739B 6C5C 3DE1 33FA
"Too enough is always not much!"
9:22 p.m.
On Sat, 2 Feb 2019, Finn O'Leary wrote:
I have to ask -- which of the old Unix variants do you
consider decent,
and why? :)
I quite liked BSD/OS (aka BSDi), until WinDriver bought them out and shut
them down; most users then flocked towards FreeBSD, which I still use to
this day.
-- Dave
3 Feb
3 Feb
7:57 p.m.
[replying to a wrong message, please excuse]
Larry McVoy wrote:
Yeah, HPUX/IRIX/AIX/Solaris/etc are all dead so far as
I know, but
the basic Unix model lives on in Linux. I wish one of the decent Unix
variants was still vibrant just so Linux doesn't get complacent.
While Solaris development is apparently ceased, at least according to
Mr. Simon Phipps, Hockey Pucks and AIX are alive, Wikipedia says.
The problem could be that neither support amd64 and/or nobody cares
about commercial Unix systems anymore.
As far as commercial systems go, even CentOS has a far larger market
share on the supercomputer territory than RHEL does, according to
TOP500.
Regarding Solaris, even new releases are getting out quite regularly,
I don't think it has changed a bit since late 2000s-early 2010s.
--
caóc
16 Jan
16 Jan
10:09 p.m.
On Wed, Jan 16, 2019 at 09:29:50AM -0800, Larry McVoy wrote:
I have a different view, having been at Sun when Sun was eating DEC's
lunch. Sun made stuff that was just as good as what DEC built but they
were cheaper. DEC couldn't adapt to decent machines that didn't cost
a big pile.
History repeats itself, Sun couldn't wean itself off $20,000 workstations
when you could get an almost as fast PC for 1/4th or less of that price
point.
This is applicable in the Open Source world as well, and there it's a
much more clearly an example of the "Better is Worse", "New Jersey
Style" vs. "The MIT Approach"/"The Right Thing" debate.
Example: Linux had PCMCIA support before the *BSD variants, and even
when the BSD's had PCMCIA support, the PCMCIA card (most commonly, for
WiFi) had to be plugged when the system was booted. Where as for
years ahead of *BSD, Linux had hot-plug PCMCIA support --- but if you
ejected the card, there was a 30-50% chance the system would crash.
(Which could be lowered if you carefully shutdown the network, and
waited until all open/pending TCP connections that couldn't be closed
had timed out, etc.) Eventually, the *BSD's pulled ahead of Linux,
and had rock-solid PC Card support, and it took a lot longer for
Linux's hot-eject support to be fully stable.
For most users, of couse, hot-pluggable PCMCIA was way more important
than stability problems when you ejected the card, especially when it
usually worked (especially if you were careful). And if you have more
users, you are much more likely to get bug reports, and more likely to
recruit developers (which in the open source world, are more likely to
stick around if you are willing to accept less-than-perfect patches,
as opposed to insisting that they be picture-perfect before they can
be committed). There's a downside with this approach, of course,
which is that it may take a lot longer to get the code cleaned up
after the 1.0 "launch" of the feature.
- Ted
1908
days inactive
1926
days old
10 comments
8 participants
participants (8)
-
Arthur Krewat -
Clem Cole -
Cág -
Dave Horsfall -
Finn O'Leary -
Larry McVoy -
Paul Winalski -
Theodore Y. Ts'o