RE: Networking Pearl Harbor in the Making

Subject: RE: Networking Pearl Harbor in the Making
Date: Mon, 7 Nov 2005 11:11:52 -0500
From: "Hannigan, Martin" <>

> >
> > It's an argument for vendor diversity.
> No it is an argument for code base diversity (or better
> software engineering).
> Vendor diversity doesn't necessarily give you this, and you
> can get this with
> one vendor.

How so? Haven't we recently seen an across the board bug in
multiple version of $vendor code?

Excerpt from "Logic 101 -- Introductory Logical Reasoning":

   "Can" does not mean the same thing as "will".

And, thus, the fact that one vendor has an across-the-board bug does _not_
mean that the same situation exists at =all= vendors..

The bug in multiple versions ov $vendor's code was directly attributable to
those 'multiple versions' all being derived (at different points in time,
and/or for different deployment niches) from the same primary 'code base'.
Note: "code base", *singular*. The problem existed in the core code, so,
naturally, it was present in all the varients of that *single* core.

> Vendor diversity might be a good idea, but for other reasons.

Sure. There are more reasons than one to do it. I was specifically
pointing out that code diversity is a good one - and not forgetting
associated cost and economic impacts as mentioned in a later followup.

Vendor diversity does *not* _guarantee_ diversity in code-base.

You have to *explicitly* spec/check/test for code-base diversity, to ensure
that you have code-base diversity.

It is _possible_ to get code-base diversity with multiple purchases from a
single manufacturer/vendor.
It is _possible_ to have a single common code-base among purchases from
  disparate manufacturers/vendors.

The "probability" of getting things with different code-bases -- *without*
*actually*checking*for*it* -- is higher if you purchase from multiple
manufacturers/vendors, rather than from a single one.

"Higher probability" != "guaranteed" Hence the need to explicitly check,
if said diversity is a requirement.