[ih] Lessons to be learnt from Internet history
LarrySheldon at cox.net
Tue Feb 19 13:33:12 PST 2013
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
> 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
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
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)
More information about the Internet-history