Revisiting the Aviation Safety vs. Networking discussion

bross at pobox.com bross at pobox.com
Fri Dec 25 18:22:55 UTC 2009


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 course with another plane).

This has been mentioned by others in this thread, but not to the level of 
importance I think it represents.  I, too, am a pilot.  The pilot in 
command of an aircraft always has the final say on the safety of the 
flight, not the controller, and not the design engineers.  If the pilot in 
command violates the rules and the result is negative (crash, loss of 
separation, etc.) you better believe there will be questions to be 
answered and a possible loss of the pilot's license (or life!) may result. 
On the other hand if the pilot's decision to violate the rules results in 
a positive outcome (see Sullenburger or any other number of emergencies 
that happen every day that you never hear about) there will often never 
even be a single question about why the rules were violated.

This can be applied directly to network engineering work.  If I assign an 
engineer to do a network change, yes, they better have a 
plan/checklist/etc. before they start and they better follow it.  When 
things go wrong, I expect that engineer to make the right decisions to 
minimize the damage.  Sometimes that means following the rules to the 
letter.  Sometimes that means breaking the rules.  If the rules are 
broken, there darn better be a good reason for it, but frankly, a good 
engineer will always have a good explanation, just like the good pilot.

Rigid procedures are no better than the lack of procedures.  Process is 
very important, don't get me wrong, but so is the knowledge and experience 
to know when you should throw them out the door.  Any organization that 
doesn't recognize that is doomed to inefficiency at best, and failure at 
worst.

-- 
Brandon Ross                                              AIM:  BrandonNRoss
Director of Network Engineering                                ICQ:  2269442
Xiocom Wireless                    Skype:  brandonross  Yahoo:  BrandonNRoss




More information about the NANOG mailing list