Wednesday, December 12, 2007

Not what Tom Petty had in mind about free fallin'

Slashdot had an interesting pointer to a study at Baylor about perception of time during a crisis:
In The Matrix, hero Neo wins his battles when time slows in the simulated world. In the real world, accident victims often report a similar slowing as they slide unavoidably into disaster. But can humans really experience events in slow motion?
You can watch a video.

Speaking of scary things, I was reading an entry in Risks to the Public again, and didn't quite understand it, but it had an interesting link to Boeing slides called "Statistical Summary of Commercial Jet Airplane Accidents: Worldwide Operations 1959-2006". Page 22 shows interesting data. For example, 57% of a typical 1.5 hour flight is at "cruise", yet only 10% of the fatal accidents are at cruise. On the other hand, 32% of fatal accidents are in the 20% of the flight phases of final approach and landing. Anyway, I haven't finished thinking about this, but it does remind me of the non-linear relationship between software faults and failures observed by Adams, oft cited by proponents of statistical "usage based" software testing. In undergrad software engineering I've been known to say:
One of the classic papers in the field is by E.N. Adams from IBM. He analyzed volumes of failure data for IBM products. The only thing you need to look at is Table 2 on page 8 of Adam's paper. Adam's data showed that there are a few high-frequency faults and many low-frequency faults. If you want to find the high-frequency faults -- with the intent to fix them and thereby dramatically increasing MTTF -- test the way the software will be used. That is, generate random test cases that are typical of the way the software will actually be used. Because those random test cases are modeled after actual users' inputs, the test cases should expose the failures that your actual users would experience. The rarely-experienced failure will probably not be exposed by usage-based random test. On the other hand, your actual users probably won't experience those rare failures either.

Speaking of IBM, an article by Michael Swaine in the January 2008 issue of Dr. Dobb's Journal reminded me of work done by IBM on physical environments for software developers (Steve McConnell -- you should be reading his blog -- talks about the IBM research in Rapid Development): "IBM's Santa Teresa Laboratory - Architectural design for program development" way back in 1978 (flip through the paper to see floorplans and pictures). Swaine includes examples of how software developers use ambient interfaces to communicate project/process status.

If you're interested in this kind of stuff, take a look at McConnell's "Quantifying Soft Factors", the "Retrospectives on Peopleware" from ICSE 29, "Programmer performance and the effects of the workplace" by DeMarco and Lister, and "How Office Space Affects Programming Productivity" by Capers Jones.

Need something to listen to? mp3's and some mp4 video files are posted from the USENIX Security '07 conference. Two that caught my eye were probably the most non-techie:"How the iPod Shuffled the World as We Know It" by Newsweek editor Steven Levy who introduced Bill Gates to the iPod, and "Covering Computer Security in The New York Times" by John Schwartz. Speaking of security, Usenix is sponsoring a one-day workshop on Usability, Psychology, and Security.

Finally, here's a completely unrelated bonus link: What good is a state beach if you can't get to it?