If programming was as risky as parachute jumping...

Last Friday my company organized a parachute jump. Unfortunately the clouds were, typically for the season, too low and the wind was too hard. But I learned some interesting things anyway as the morning was spend on a crash course testing by Kees Blokland from PolTeq.

One of the major things for testing is risk analysis; the amount of time spend on testing an aspect of the system is proportional to the risk of that aspect (where risk is chance of failure times impact). For fun we made a risk analysis of parachute tandem jumping. To make it more real the instructor and owner of the jumping company also joined the discussion. He told us what he does to keep jumping safe and the risk low. He named two aspects 1) attitude, and 2) an open culture. An open culture is important because incidents must always be reported so that they can be analyzed and prevented in the future.

The attitude aspect coincided well with a discussion we had earlier about the tendency to not test well. Sometimes the client thinks it is not necessary, sometimes developers don't know how to test properly, and sometimes they don't want to.
I asked what the instructor did to maintain a good attitude so that we might apply his lessons in the world of software. Here was his answer:
1. parachute jumping in itself already attracts the right type of people,
2. everybody understands that safety and risk control is paramount,
3. maintain maximum openness about incidents,
4. make an example, even a bruised toe is reported to the authorities, and
5. take disciplinary measures only when there is an attitude problem. These measures are usually drastic, for example a withdrawal of the jumping permit.

So what can we learn from this? Here are my ideas derived from each answer:
1. Attract people with the right mind set. Look out for people that are both result and quality driven.
2. Train you project managers, and require them to organize risk assessments. In software not everything is deadly dangerous and not everythings needs to be tested.
3. Use bug metrics. I am not so sure about this one. But you should at least use automated testing.
4. Even a technical team leader can make bugs. Be sure that everybody knows that.
5. Don't blame people when they do something wrong. But give the pink slip when they refuse to improve.

Even when you will apply these lessons, you will have to realize that only when programming will be as risky as parachute jumping, programs will become bug free.

We made the jump 2 day later. It was great and there were no bugs.