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