I was working in the first computer store in my hometown and bought it (using my wages - heh). This and Archon... I lost entire weeks to the two of them.

Someone should be auditing Apache and Linux, and it had better be the vendors making the cash off it. If Red Hat and the others aren't reviewing the code base regularly, I want to know what my support contract's paying for. I should receive an assurance that the system has been audited for most known vulnerabilities, and every patch should have eyes on it (besides the maintainer's) that look for obvious things (buffer overflows, SQL injection vulnerabilities) and oddness (the nightmare of a multi-patch Easter Egg full of badness from a malicious source).

That last bit is one of the things I have to fight most when recommending Open Source to non-techies. I've had them talk about the Jurassic Park scenario, where someone embeds lots of littls things in the code and then they know how to trigger a catastrophic reaction. The easy security vulnerabilities are treatable with monitoring and audits - it's an order of magnitude harder to audit a whole change trail.

YOU may not need a book to know this. but there are intelligent-in-their-area bean-counters who get sold on these things at major companies every year. THEY need this book, and as responsible techies, it's our job to make sure they have it. Remember, if it's in a book, it's not just OUR opinion - it's Official :)

Amen.

One of the things that the metrics can hide, though, is the effect of institutionalizing reviews. If you're on a long project with the same team, everyone begins to perform to a certain level and the code reviews seem to lose their importance. It's ironic, it is.

If you have new folks join the team, though, it usually only takes a few code reviews for them to "get it" and figure out the level of expertise expected.

On my favorite project so far, we had full code reviews for the first phase, and dialed them back to "peer reviews" requiring only 2-3 folks to do online review of the code units. Critical units were also reviewed by the lead developer and systems engineer responsible for that component. It was very much worth it.

"On the other hand, the flight computer has the experience of every simulated and real emergency any plane has ever been through"

No, it doesn't. The flight computer has the control laws of the airplane. It's not an AI - it doesn't learn, although it can be updated. Avionics and airframe manufacturers are always learning more about their planes, and these lead to tweaks in fly-by-wire systems, but the plane doesn't "learn" or gain "experience".

You seem ignorant of the degree to which professional commercial pilots get torture-tested in simulators. FlightSafety International does a multi-million dollar business every year training corporate pilots in handling emergencies, and each of the major airlines in the US and Europe operates their own simulation centers where pilots have to be re-certified every six months or so. They may not live through actual emergencies often, but they go through simulated ones in fully accurate cockpits on motion bases with good graphics outside. Check out http://www.flightsafety.com/fs_service_simulation_systems.php to see what they can do.

Could be worse... I know for a fact that recent Boeings have their flight control systems programmed in a highly constrictive subset of Ada... although at least the programmers weren't forced to use vi.

There are a lot of flying clubs in the US; most mid-sized airports have at least one. Plus, used airplanes for VFR flying are getting pretty cheap these days, and if you can deal with old avionics you can fly most of the country.

That said, I'd upgrade to a Mode S transponder and a moving-map GPS first thing if I had to fly around any of the complex airspace around here (DC, NY, LA, Chicago). And carry a good handheld radio in case the plane's decides to quit.