nanog mailing list archives
Re: Revisiting the Aviation Safety vs. Networking discussion
From: bross () pobox com
Date: Fri, 25 Dec 2009 13:22:55 -0500 (EST)
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
Current thread:
- RE: Revisiting the Aviation Safety vs. Networking discussion, (continued)
- RE: Revisiting the Aviation Safety vs. Networking discussion Vadim Antonov (Dec 25)
- RE: Revisiting the Aviation Safety vs. Networking discussion Mikael Abrahamsson (Dec 25)
- Re: Revisiting the Aviation Safety vs. Networking discussion Anton Kapela (Dec 25)
- RE: Revisiting the Aviation Safety vs. Networking discussion George Bonser (Dec 25)
- RE: Revisiting the Aviation Safety vs. Networking discussion Vadim Antonov (Dec 25)
- Re: Revisiting the Aviation Safety vs. Networking discussion Michael Sinatra (Dec 28)
- Re: Revisiting the Aviation Safety vs. Networking discussion Owen DeLong (Dec 28)
- Re: Revisiting the Aviation Safety vs. Networking discussion Robert Boyle (Dec 28)
- BCPs, Exercising emergency process et al Jared Mauch (Dec 25)
- Re: BCPs, Exercising emergency process et al Sean Donelan (Dec 26)
- Re: Revisiting the Aviation Safety vs. Networking discussion bross (Dec 25)
- Message not available
- Re: Revisiting the Aviation Safety vs. Networking discussion Robert Boyle (Dec 26)
- Re: Revisiting the Aviation Safety vs. Networking discussion David Hiers (Dec 28)
- Re: Revisiting the Aviation Safety vs. Networking discussion Bill Woodcock (Dec 28)
- Re: Revisiting the Aviation Safety vs. Networking discussion Owen DeLong (Dec 28)
- RE: Revisiting the Aviation Safety vs. Networking discussion Frank Bulk (Dec 25)
- Re: Revisiting the Aviation Safety vs. Networking discussion Joe Provo (Dec 25)
