Evil Flower said:
There's also the fact that most software engineers who work on defense/medical/you name it software simply aren't very good programmers. In the games industry where I work software engineers usually keep a much higher standard - not just because games development is more difficult but because we actually need to meet our deadlines. Contrast the US Government with any publisher who will simply outright cancel a project or even close the entire studio if they aren't happy with the development process.
So your argument is essentially "game developers can get sacked at the drop of a hat if they don't push something out the door by a set date, so they therefore produce better, more reliable code"?
Excuse me for a moment; I almost passed out from laughing so hard.
I test fly-by-wire systems for a living, at a company that makes products for the private sector--in other words, we don't suck the government teat for our development funds, either. Our testing process is rigorous, time-consuming, and expensive, because when the hardware and software that goes on our airplanes has a bug, that's a problem--on the scale of people getting KILLED, not just pissing off some 12-year-old because his game froze up. And unlike the game industry, we don't have the luxury of pushing out a buggy product to make the Christmas deadline, and then patching it later. A graphics glitch in a game is an annoyance; a graphics glitch on avionics software at the wrong time can cause a deadly accident.
When we test our products, we don't just pay a bunch of kids to sit in front of computers and play games. We spend hundreds of hours testing every single software load on the ground (on a full-size test rig) just to clear it for flight--and then we go fly it on an airplane, at tens of thousands of dollars per hour, and with people potentially risking their lives. If we find a bug, the whole process starts over again, because you can't just retest the situation that caused the bug, but you have to test everything else to make sure your fix didn't break something else.
That's what takes so long with our development process. It's not the coding or design work that takes so long--that goes relatively quickly. It's the testing and documentation that you have to do. You have to test the hardware and software to make sure it works the way it's supposed to. You have to prove that your test procedure is testing everything it should. You have to document your process and prove that every item and every part you make (and its software) is actually what you say it is, and that your production process is consistent. Do game manufacturers run functional checks on every CD that comes out of the factory?
Our (the aerospace industry's) software has to work all the time. It has to work even when your sensors start giving erroneous readings, when the user does something stupid, when other components start failing. The hardware has to work in arctic cold, desert heat and dust, in tropical rain, or covered in hydraulic fluid, not just sitting in a living room at room temperature. And in order to meet redundancy requirements for safety, some items have to be independent of each other. For example, the hardware in each flight control computer might be designed independently by separate groups to the same specification. The software for both will be written to the same spec, but by different groups. That's twice the development and testing work, but it helps reduce the chance that a given bug will take down all of your most critical pieces of hardware at once.
Go read up on the development of the Space Shuttle's flight computer and its software. That's about as bug-free as software can be. Yes, it's slow and laborious. It's absolutely glacial compared to the game development process. But it simply cannot be allowed to fail.