> From: Vernon Schryver <vjs@calcite.rhyolite.com>
>> Anyway, simple protocols, like PPP and ARP (another canonical subject
>> of abuse) get reused in vile ways because the architecture which they
>> are components of is fundamentally under-provisioned with mechanisms.
> The architectures that are not "under-provisioned with mechanisms" are
> total disasters, as anyone who was even slightly technically involved
> with TP1-4 knows instinctively
Ahem. Just because your name is "Vern" doesn't mean my name is "not-Vern".
Similarly, not all architectures which are <not under-provisioned> are
<over-provisioned>. There is a space in the middle...
> It is a fraud and a deceit to claim to be able to "architect"
> provisions for a significant or even noticable part of the unforeseen
> future. If your design covers any of the real future, as opposed to the
> future you predicted, you're very lucky. It is not honest to confound
> great luck with great skill or talent.
I don't agree with your contention that it's luck.
Let's take as an example Unix, which I would argue has lasted as long as it
has for two reasons: first, it was written in a basically portable language,
and second, the initial system provided basically the right set of
fundamental mechanisms/objects. Looking at the latter point, I think Unix V6
had the things it had not through luck, but because Ken Thompson et al
displayed *exactly* "great skill and talent".
It is true that if you're striking off into a new area, it's more of a gamble
- and when you have a success, sometimes there is some luck involved. For
instance, in TCP/IP, I think it's lucky that the system has working
congestion control - because we certainly didn't understand how to do it
right when we went down the "no congestion control in the switches" road back
in the mid/late-70's. It's to some degree luck that there was a workable
solution for someone clever to figure out. So when people are moving into a
new area, it often takes a while before you find out what the envelope of
what's viable is.
However, outside things like that, there is clearly a great part of system
layout where study of past systems and how they failed and succeeded, along
with some guidelines, allows people to design "great architecture". If you
look, you will actually find that quite often they knew that they had created
a successful architecture, and knew how and why they had done it, a long time
before it became obvious. Go look at the classic Thompson/Richie paper on V6
Unix for an example; and there are numerous others. The System/360
architects, and the PDP-11 architects, for example, both knew they had great
designs at a very, very early stage in the life cycle.
Also, you need to distinguish between "commercially successful" and
"technically successful". Sometimes systems fail to succeed in the market,
but not because they are poorly architected (i.e. a technical failure), but
because the company screws up in other ways. Multics is a classic example; I
was involved with one in the router business.
Someone (maybe Napoleon - or maybe someone said it of Rommel) once said that
great generals make their own luck. So it is with system architects.
Noel