Somewhere in my computers I have a PDF of Michael Barr's testimony. I read through it (< 300 pages) one evening with a friend. Both of us had worked in an embed

Somewhere in my computers I have a PDF of Michael Barr's testimony. I read through it (< 300 pages) one evening with a friend. Both of us had worked in an embedded device company that dealt in life and death type devices, such as cars, traffic controls, etc. So we are familiar with the tools and rigor needed to design and develop safety critical systems. It is a matter of great professional interest to us to observe what transpires in legal cases relating to software quality. Some of the key overall findings: The management was at fault, by picking people who were not experienced in developing real-time devices to lead software development (many software faults were those of inexperienced developers, and of developers inexperienced in real-time control). The lead developers were at fault, following extremely poor coding styles. The end code, of course, was badly done, as you might expect from management who didn't understand and leads inexperienced in the field. Toyota, bluntly, messed up in breadth and depth when it came to software quality control. If you can find an unsafe coding practice listed on the web, Barr found it and detailed the precise ways it was unsafe. Huge interrupt service routines, complex logic in the wrong places, huge cyclomatic complexity. It is understood in the world of safety and real-time software that certain designs of code are to be encouraged and others discouraged, based upon painful experience. It is not a handwavy "different strokes for different folks" field. The information from the Barr transcript can be used as a comprehensive manual of things to not do.