[ih] Lessons to be learnt from Internet history

[Larry Sheldon]

On 2/19/2013 3:14 AM, Bob Hinden wrote:
[Ed. note:  I don't who said what is quoted immediately below--"Ian"?]

>> 1. Think long term.
>>
>> Plenty of examples discussed here (good and bad). We need to plan
>> for an Internet that is around forever, not for a quick fix that
>> patches an immediate problem while giving rise to longer term
>> problems.

> While this sounds good, I think in practice it has significant
> problems.  Many of the problems we see now were understood when the
> Internet was first developed, but we didn't have practical solutions
> to them.  Had we insisted on solving everything, it's very likely
> that nothing would have been done, or it would have been impractical
> to deploy given the technology at the time.  Just because you
> understand the problem, doesn't mean you can solve it.

I think that may be the the most prevalent and at the same most poorly 
understood in all of my experience with systems development.

I was a grunt in several large-scale projects to mechanize the 
production of telephone directories from the data on the service orders.

The first one was to mechanize all directories--White Pages (delivered 
to subscribers), information reprint (delivered to the Information 
Operators monthly) and its supplement (delivered daily--an interesting 
document printed on IBM 1403's with print trains make of letters lying 
on their sides), Delivery Lists (arranged for the walking path of the 
ring-and-flingers) and labels (for the ones that were mailed), and the 
Yellow Pages.

That one accomplished all but the last.  The Yellow Pages are, it turns 
out a very different product from the White Pages and have little in 
common with them once you get a few yards away from the presses.

The second one was a Bell Labs project that I was not a part of, but 
since we were the only Operating Company with a functioning White Pages 
system, we were selected as the trial company.

The third one was back with us after Bell Labs gave up.

Remember that I was a pretty small gear in each of these, but from my 
perspective (both then and more maturely -- better aged -- now) the 
single thing that killed the first two project were what we have here.

In the first case, the designed system was required to be perfect in 
every regard--an impossible task from the gitgo because the policies and 
practices of the company's Northern Region were very different and often 
contrary to those of the Southern Region.  (Some of us realized that the 
policies and practices of the Southern Region were more like those of 
the "independent" company that had the franchise for most of the land in 
the southern region.  My guess is that both we and the "independent" had 
to use the same printer-contractor because the PUC required that the 
listings be interfiled.)

I think Bell Labs ran aground on a much bigger sand bar--trying to 
develop a system for 21 or 22 operating companies.

We finally succeeded by an undocumented practice of "settling" all 
issues for 50% (or so) of what was wanted, then immediately filing a 
change request for 100% of the balance.

> I also note that "forever" is a very long time.  We aren't that good
> at predicting the future to know what will be needed in 10 years,
> much less a hundred years or more.

Another aspect of the "forever" notion is that for any system with more 
than a few variable, the number of permutations and combinations quickly 
reaches an astronomical number.  Until you get into the Real World™ 
there is know way to know which really exist--there were uncounted 
"features" that cost a lot that were never exercised, and a similar 
number of things that had not made the cut that were frequent flyers. 
(I recall an incident where a program that ran daily in each of the nine 
computer centers failed in several of them the same night.  It turns out 
that the problem was a coding error that had been made when the program 
was first coded a number of years before.

There is a technical term that used to be popular for the idea that 
everything has to be perfect for a thousand years before anything is 
implemented--analysis paralysis.

-- 
Requiescas in pace o email           Two identifying characteristics
                                         of System Administrators:
Ex turpi causa non oritur actio      Infallibility, and the ability to
                                         learn from their mistakes.
ICBM Data:  http://g.co/maps/e5gmy        (Adapted from Stephen Pinker)