In general, it seems that a field has to be aware that it can kill (or
has killed) an embarrassing number of people before its members accept
the need for controls such as processes and checklists.
Here's a couple if incidents in which gruesome, public loss of life
was necessary to for thought to
The connection may not be immediately apparent, but I think Philip
Greenspun's article critiquing Malcolm Gladwell's musings on cranial
metrics etc. has some bearing:
http://philip.greenspun.com/flying/foreign-airline-safety
...or is at least an interesting read. In observing network
On 12/25/09 7:57 AM, Anton Kapela wrote:
What I'm getting at is that after following this thread for a while,
I'm not convinced any amount of process-borrowing is going to solve
problems better, faster, or even avoid them in the first place. At
best, our craft is 1/3rd as old (if that's somehow
On Dec 24, 2009, at 11:08 PM, Scott Howard wrote:
On Thu, Dec 24, 2009 at 6:27 PM, George Bonser gbon...@seven.com wrote:
So you can put a lot of process around changes in advance but there
isn't quite as much to manage incidents that strike out of the clear
blue. Too much process at that
On Dec 25, 2009, at 7:57 AM, Anton Kapela wrote:
On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov a...@kotovnik.com wrote:
The ISP industry has a long way to go until it reaches the same level of
sophistication in handling problems as aviation has.
It seems that there's a logical fallacy
At 03:38 PM 12/28/2009, Owen DeLong wrote:
There are lessons to be learned that are valuable. Both from
things aviation has done well that we could emulate, and, from
things aviation has done poorly that we should avoid. There
are also additional lessons to be learned about the differences
in
At 02:08 AM 12/25/2009, Scott Howard wrote:
On Thu, Dec 24, 2009 at 6:27 PM, George Bonser gbon...@seven.com wrote:
So you can put a lot of process around changes in advance but there
isn't quite as much to manage incidents that strike out of the clear
blue. Too much process at that point
Just clearing a small point about pilots (I'm a pilot) - the
pilot-in-command has ultimate responsibility for his a/c and can ignore
whatever ATC tells him to do if he considers that to be contrary to the
safety of his flight (he may be asked to explain his actions later,
though). Now, usually
On Fri, 25 Dec 2009, Vadim Antonov wrote:
The ISP industry has a long way to go until it reaches the same level of
sophistication in handling problems as aviation has.
Well, to counter this one might talk about the medical business (doctors)
which hasn't been able to embrace the checklists
On Fri, Dec 25, 2009 at 5:44 AM, Vadim Antonov a...@kotovnik.com wrote:
The ISP industry has a long way to go until it reaches the same level of
sophistication in handling problems as aviation has.
It seems that there's a logical fallacy floating around somewhere
(networks have parts and are
On Thu, Dec 24, 2009 at 01:09:26PM -0500, Randy Bush wrote:
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Whimsical deviations don't
On Thu, 24 Dec 2009, Scott Howard wrote:
His actions were then subject to the consensus of those on the conference
bridge (ie, ATC) who could have denied his actions if they believed they
would have made the situation worse (ie, if what they were proposing would
have had them on a collision
What I'm getting at is that after following this thread for a while,
I'm not convinced any amount of process-borrowing is going to solve
problems better, faster, or even avoid them in the first place. At
best, our craft is 1/3rd as old (if that's somehow I measure of
maturity) as flight and
of real world issues.
Frank
-Original Message-
From: Michael Dillon [mailto:wavetos...@googlemail.com]
Sent: Thursday, December 24, 2009 6:02 PM
To: NANOG list
Subject: Re: Revisiting the Aviation Safety vs. Networking discussion
imagine a network engineering culture where the concept
I can see situations in the future where people's lives could be
dependent on networks working properly, or at least endangered if a
network fails.
Actually it's not the future. My father's design bureau was making
hardware, since 70s (including network stuff) for running industrial
processes
On Dec 24, 2009, at 9:51 AM, Randy Bush wrote:
I'm more persistent than smart, and I tell ya, if you prep well
enough, you can hand your checklist to a stoned intern and you'll
have no worries at all.
this works in a tech culture where folk follow mops obsessively. my
experience is that
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
randy
On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
randy
=]
The networking group is
Eddy Martinez wrote:
On Dec 24, 2009, at 10:09 AM, Randy Bush wrote:
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
I find the thought
On Dec 24, 2009, at 1:09 PM, Randy Bush wrote:
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Are you trying to suggest that this is
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Are you trying to suggest that this is something horrible, or that
it's the future of network engineering? :)
neither. it is one [type of] ops engineering culture, and a very
successful
I _do_ create action plans and _do_ quarterback each step and _do_
slap down any attempt to deviate.
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Are you trying to suggest that this is something horrible, or that it's the
: this works in a tech culture where folk follow mops obsessively. my
: experience is that most north americam engineers are too smart to do
: that, and take shoprtcuts
and _do_ slap down any attempt to deviate
: imagine a network engineering culture where the concept of 'attempt to
:
flameproof panties == ON :-)
:mops work.
It depends on who wrote it and the experience the person has (on the particular
network) who generated it..
scott
imagine a network engineering culture where the concept of 'attempt to
deviate' just does not occur.
Are you trying to suggest that this is something horrible, or that it's the
future of network engineering? :)
The model of network engineering that grew up during the 1990s is
forever gone
On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote:
It would be interesting to see what others have to say about this answer.
I think it's a pretty accurate summation of how these things work in a lot of
big organizations, all over the world.
There's a detrimental side to it, in that in the
-Original Message-
From: Dobbins, Roland
On Dec 25, 2009, at 7:01 AM, Michael Dillon wrote:
It would be interesting to see what others have to say about this
answer.
I think it's a pretty accurate summation of how these things work in a
lot of big organizations, all over the
On Dec 25, 2009, at 9:27 AM, George Bonser wrote:
Capt. Sullenberger did not need to fill out an incident
report, bring up a conference bridge, and give a detailed description of
what was happening with his plane, the status of all subsystems, and his
proposed plan of action (subject to
On Thu, Dec 24, 2009 at 6:27 PM, George Bonser gbon...@seven.com wrote:
So you can put a lot of process around changes in advance but there
isn't quite as much to manage incidents that strike out of the clear
blue. Too much process at that point could impede progress in clearing
the issue.
1. I grew up at the local airport watching my CFII pop train an
endless stream of pilots.
2. The checklist for my last production gear swap had over 400 steps
and 4 time/task gates (each with a rollback plan). As I did each
sequence of steps, I called it out, and someone read their copy of the
30 matches
Mail list logo