V-22 Osprey: Cool, Fast, and Expensive

Wired News is running a complete overview of the program, so if you want to skip the commentary go over there. There's half a dozen quotes that stand out in the article. The first one that got my attention?

The program took another hit on the ground. Odin Leberman, then a lieutenant colonel and the Osprey squadron commander at New River, ordered marines in his command to falsify Osprey maintenance records. He did it to make the plane appear more reliable than it was, to increase its chances of winning new funding. "We need to lie or manipulate the data, or however you wanna call it," he said in a meeting. A maintenance crew member was secretly running a tape. Leberman was later relieved of duty.

Aside from the "evil military industrial complex" theories, there's a ton of good stuff to learn here. Talk about management screw ups!

"People now actually read my flight test reports," says Steve Grohsmeyer, an Osprey test pilot.

What the heck does that say about the way things used to be run in that program? What were the program managers doing? (Answer: probably paperwork related to securing funding instead of running the program)
As software and hardware engineers, I can't get over the critical importance good program management and good design play. It used to be most software did accounting and number-crunching. Now if something screws up, people die.

One of the nacelles had a catastrophic leak in the hydraulic system, and to compensate, the pilot hit a systems-reset button. Nothing happened. He hit it again. And again, at least eight times. Later, investigators found a glitch in the aircraft's software. Each press of the button had, for some reason, caused the plane to decelerate, making an accident even more inevitable.

I'm just amazed -- it's great we get stuff like this out in the open. But do you think it will make a difference for future programs? Somehow I doubt it.

I remember one time our onboard primary mission computers were failing, and we'd have a black cockpit for 8 or 12 seconds before the software recognized the problem and the backup kicked in," says Gross, the former flight test director. "That's too long to go with no cockpit displays, not knowing our air state. When we wrote it up in our deficiency reports, the program office got extremely angry and frustrated with us. They didn't want us slowing down the program because of unfavorable reports."