When I first heard the expression “Controlled flight into terrain” I added it to my euphemism collection as a fun way of saying “Somebody screwed up.” As I’ve read and thought more about CFIT accidents, I’ve noticed a common thread: They are not usually the result of simple “pilot error”. The typical incident involves a series of failures in policies, procedures, training, and human factors design that turn a pilot error into a tragedy.
Which brings me, in my usual roundabout way, to the closest thing to a running theme you can expect to find at this blog. I’ve been working in the software industry for quite a while now, and I’ve always felt that software should be well crafted. Lately, however, I’ve come to feel it is at least as important that software be well used. What that means is that you can expect to read me ranting about both how software gets built and what we build it for.
Of course, to make sure the bar isn’t set too high, you can also expect frivolity, family, kite flying, curling, bicycling, and whatever random shiny things catch my attention.
2 Comments
I’m currently reading “Normal Accidents” (http://www.amazon.ca/Normal-Accidents-Living-High-Technologies/dp/0691004129), which has as its premise that complex systems are naturally prone to accidents because of their complexity, regardless of the amount of education and training given to the humans involved. The book is eight years old now, but still relevant, IMO.
Well-crafted is always good. And in response to Haraldunteresting comment, the premise of Normal Accidents appears to make a great deal of sense. But I feel that most things in life, including software, can be very complex, by neccessity. The trick to making things work could lie in finding the important simple mechanisms within a complex system, and effectively communicating these mechanisms to others.