Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: The Airplane Example (was Re: Streaming XML)
 On Fri, 31 Dec 2004 07:03:25 -0800 (PST), Benjamin Franz <snowhare@n...> wrote: > And yes - commercial planes _HAVE_ crashed where one of the proximate > causes was broken software (accidents are rarely 'one thing' - they are > usually two or more things in unusual combination): Put American Airlines > Flight 965 into a search engine. I did, and got some interesting information. (This was the "controlled descent into terrain" incident near Cali Colombia). One phrase "pilots may be overconfident in automation" leaped out at me; that's certainly relevant to our discussion of procedural/declarative approaches if you think of declarative as more "automated." > > I'm of the opinion that software is where engineering was about a century > ago: In demand, unregulated, and open to anyone who wants to call > themselves a 'programmer', regardless of skill or training. Disasters > directly traceable to poor 'engineering' by people with neither skill or > training killed a number of people and laws were passed restricting who > can legally call themselves an 'engineer'. From what I took away from a quick scan of the AA 965 incident, the problem wasn't so much poor engineering as bad specwriting (or "program management" maybe)-- everything worked as designed, but the designs did not really "work" for human beings who had to cope with an unexpected situation -- there was no graphic display of the terrain, the pilots failed to revert to traditional navigation techniques when they should have, and so on. Arguably the mechanical/software engineering was too good, or too optimized for situations that prevail 99.99% of the time, so the overall *system* degraded precipitously when, uhh, the brown smelly stuff hit the fan. Did you have a different take on this from your more extensive reading? What poor engineering killed people on AA965? More importantly, is there really a well defined state of the art for the overall systems engineering -- including the human factors -- that could be taught/certified? I admit that I'm a bit biased (or perhaps defensive, since I don't have an engineering degree or certification and have had a bunch of jobs with "engineer" in the title). I wouldn't disagree that this is a Bad Thing, and that laws should be made to make the term "engineer" mean something in the software world. I will guess that continual *updates* to training and education are more important than certifications and licenses per se. For example, look at the sample chapter in Writing Secure Code, 2nd Edition http://www.microsoft.com/mspress/books/sampchap/5957.asp#SampleChapter. How many people with degrees/certifications in software engineering that are more that a few years old would "treat all input as evil unless proven otherwise"? And how many would knwo all the perverse ways that have been found to subvert code written to 1990's best practices for validating lengths before calling strcpy(), memcpy(),-like methods? My point is not to disagree about the need for rigor, but to argue that it is not enough -- designers of safe systems also need a lot of attention to touchy-feely human issues, a dose of Machiavellianism to deal with the people who will deliberately try to make them fail, and and appreciation for the possibility that Father Darwin tends to design more robust systems by trial and error than an Intelligent Designer can realistically hope to. :-) I have not idea how to create a licensing exam to test for this kind of stuff. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
