Airlines and Software

This might be a little off topic, but after reading this article from USA Today, I thought the software industry should be inspired by the airline security system.

As far as I know, the reason why air flight is the safest way of traveling is much due to these aspects.

One, all the parts involved work toward ZERO fatalities.

Two, their effort is never "good enough".

Three, they have a very open mind, sharing all the information about problems and crashes (the system was born when planes were "constantly" crashing so the pilots were very interested in sharing their experiences !)

Four, unfortunately aircafts can't really pull over to change a flat tyre or stop to check their engine along the road !
Airplane manufacturers are therefore forced to build better, safer airplanes with improved safety and performance. Maintenance technicians are also forced to improve procedures to enhance reliability and safety and I think that regulators contribute with controlled procedures and checklists to avoid omissions or carelessness, and accident investigators generate a fair and exhaustive analysis of the accidents.

There are also other factors, but they are valid for any other transportation systems: pilots improve their skills, there are better weather forecasts, customers "forced" the industry to adopt new technologies, training methods and to improve human performance, etc.

I guess that software makers (including myself) should think about this !

Comments

Questiologie for complex requirements - Frédéric Falisse

I just watched this TedX video of Frédéric Falisse explaining his Questiolgie and found it very interesting. The video is in french but it has English captions. I think it could be greatly useful while gathering elaborate or difficult requirements. As far as I understand it, he proposes four tips for asking good questions 1. Change of mental posture If the interviewed is already an actor , remove him from the action and ask for a feeling . Do not ask "why do you get stuck" but "what do you feel when you feel stuck ? If instead he starts with an emotion, ask about an action. 2. Double the verb Like in the phrase "What are you afraid of when you are afraid of losing control?" 3. Reconcile Use right and left hands "When you fail a test ... Makes you lose control over future choices" 4. Project in the future i.e. What will happen if you fail the test? Here's his main site https://www.questiologie.fr/ Have a great day!

3. Simple, Complicated, Complex... Chaos !

A few words about the different kind of systems, just so you know in which kind of trouble you are when you start gathering requirements :-) SIMPLE What it is: you can see clearly all the connections between cause and effect . How to handle it: it is usually easy. COMPLICATED What it is: there are cause - effect connections, but it's not easy to see them. There is never a unique solution. How to handle it: ask questions to the experts (if there is any). COMPLEX What it is: it is made of many pieces, and they are highly interconnected. The output is usually part of the system itself and influences it, so it's difficult even to ask yourself the right questions. How to handle it: test some small parts and see what it happens (someone calls it "dance with the system.") CHAOS What it is: high uncertainty, no apparent cause and effect and ... when some rule seem to apply, it will probably change very rapidly. How to handle it: run away !

Vague requirements

An old school tip on vague requirements. A lot of words and sentences that we write in our requirements documents are often too vague . And these kind of unclear requirements have a big chance to cause problems at the end of your work. Blurred Something like: the system must be scalable , the system must be user friendly , the system must be quick . A good way to at least improve these three requirements could be something like this: 1. The system must be scalable up to 1.000 concurrent users without upgrading our servers, 2. The system must be usable by an average 50 years old accountant that only knows Word and some Excel, 3. The system must have any functinality ready on the screen in 1" when all concurrent users are using the system. So, by just exploring a bit more with the stakeholders, you can reduce ambiguity a lot. It's not too difficult and you can have a huge improvement in the end product or service.

REQUIREMENTS !

Search This Blog