The F1 World Championship started in 1950. Early years were notoriously dangerous, including spectators who stood on the kerb of whichever road it was they were racing down. Essentially it was all-or-nothing: if everyone kept on the track, no-one got hurt; if someone went off then lack-of-limbs was the best case scenario.
...
So what has this got to do with software? Well, I think there are direct parallels; the history of software is very similar. Thankfully, very little software is responsible for life-and-death issues, although there has been many instances of deaths being directly attributed to faulty software; the failures of software are mostly financial. Money is lost due to either: a) projects being abandoned or significantly over-running; or b) faulty or inefficient software in production.
...

So, how can the software development process improve? How did Formula 1 get to it's current very good safety record? The answer, isn't technical. Technology changes like HANS devices, etc., definitely have worked; but most of the shocking incidents of the 1970's and early 1980's were avoidable. They were caused by lack of preparation (e.g. fire-extinguishers around the track), or lack of communications (e.g. between cars and marshals).

1. Lack of complacency; no-one goes round saying "but why would two cars crash? You need to make a case before I can approve that new helmet".

2. Lack of buck-passing: Race control, from a safety point-of-view, is the ultimate responsibility of one man. He doesn't need to get approval from Bernie Ecclestone before calling out a Safety Car; he has the power. Whilst sporting decisions are made by a panel of stewards, safety issues are dealt with immediately.
...

The moral of the story: responsibility is meaningless without power. If you genuinely want quality, you have to have in your team a single "quality manager" - a person who will be rewarded or sacked based on the fitness-for-purpose of the end deliverable. And, which is even more important, this person must not be in a position where he can be over-ruled on quality issues by other managers.

We recently started taking that approach to quality assurance at work. A single QA person can stop a release. They no longer report to the development manager of the product they're responsible for assuring quality in. Hopefully this will mean less fiery, fiery deaths.