El 8 de Diciembre del 2005 hubo un accidente aéreo en Chicago durante una tormenta de nieve: el avión del vuelo 1248 de SouthWest airlines no logró frenar a tiempo y siguió de largo, saliéndose de la pista y chocando a dos automóviles en un cruce aledaño.

Resultado: un niño de seis años murió y 8 personas quedaron heridas de mayor o menor gravedad, todos ellos estaban en dos automóviles que el avión chocó. La investigación probablemente durará un año hasta evacuar su informe final, pero ya hay avances, y algunos ya han dado su opinión: "error humano".

Pero, ¿error de quién? >> Parece haber certeza respecto a una cosa: si no hubiera habido una demora de 18 segundos en comenzar a utilizar el frenado por empuje reverso (reverse thrust), el avión habría podido frenar.

Más precisamente, si al software que se utilizó para calcular el largo del frenado bajo las condiciones actuales, se le indica que existirá esa demora de 18 segundos, el software habría indicado que la pista no alcanza y no se hubiese intentado el aterrizaje. La discusión entonces se centra, equivocadamente, en si la culpa es del piloto que no activó el empuje reverso al instante de tocar el suelo, o si se debió haber activado automáticamente y existe una falla de diseño.

Eso, hasta que entra en escena Donald "Don" Norman, dejando en claro su categoría de ídolo. Cuando alguien como Don Norman golpea la mesa para decir algo, se puede tener la certeza que lo que viene es bueno. El tirón de orejas de Norman dice lo siguiente:

1. El concluir "error humano" generalmente tiene como objetivo quedarse tranquilo y olvidarse del tema (hasta el próximo "error humano"). En cambio, cuando algo se declara como "error técnico", sí se intenta reparar el error.
2. En general, alrededor 75% de los accidentes son atribuidos a "error humano", casi siempre del piloto. En rigor, el 25% restante también debe ser considerado error humano: si hay fatiga de material, es un error por parte del diseñador no haberlo previsto, o por parte del mecánico por no haberlo reemplazado cuando correspondía.
3. Asumiendo que hay una mayoría de falla humana, ¿por qué no solucionamos el problema en vez de contentarnos con haberle echado la culpa a alguien?: podríamos disminuir la cantidad de fallas humanas con buen diseño y buena ingeniería.

Y aquí viene la parte genial ... son esas explicaciones que, luego de haberlas leído, te dejan con esa sensación de que el problema era trivial, preguntándote "¿por qué no se me ocurrió a mi?". Y es que uno siempre asume que en un cálculo, mientras más preciso sea es mejor; el problema es que cuando un sistema entrega un resultado con demasiado nivel de precisión, asumimos que el error es pequeño.

Este es un problema viejo en física experimental. Al reportar el resultado de un experimento que produce una cantidad numérica, uno jamás debería entregar cifras significativas más allá del error experimental. Por ejemplo, si un medidor marca "213.5 ± 4.8", entonces la respuesta que tenemos es simplemente "210" y nada más. El "3.5" restante está por debajo del error, y por lo tanto reportarlo es, en términos físicos, simplemente falso.

En el caso del avión, hay muchos factores que afectan la frenada: qué tan mojada está la pista, la temperatura exacta, cuánto peso lleva el avión en carga + personas + combustible, cuánto demorará en activarse el empuje reverso, qué velocidad tendrá el avión al tocar suelo y en qué lugar preciso de la pista lo hará, entre otros factores. Entonces, al dar una respuesta exacta, digamos "distancia de frenado calculada: 3246.8 metros", y la pista tiene 3600 metros de largo, asumimos que estaremos bien. Pero en realidad la distancia, considerando el error de la estimación, era más bien "distancia de freno estimada: entre 2800 y 3650 metros", lo que es muy distinto. Quizás eso no hubiese solucionado este incidente particular, pero es algo a tener en cuenta.

En caso de utilizar representaciones gráficas, se debiera colocar un rango o, mejor aún, un manchón en proporción al error, con lo cual es bastante obvio cuál es la precisión del valor. Esta es una solución simple y por lo mismo, brillante, que se puede aplicar en muchos contextos en que un sistema automático debe comunicar sus estimaciones o hallazgos a un operador humano.