Cuántas muertes evitables...

Acabo de publicar un material de presentación relacionado a prácticas que han causado problemas críticos en múltiples sistemas. Puedes encontrarlo aquí.

Es una pequeña recopilación de errores supercomunes junto a un recuento de víctimas mortales por no considerarlos.

Todos los problemas que se presentan me los he topado al menos una vez en auditorías de los últimos años, aunque no necesariamente vinculados a ningún accidente. Otros profesionales han referenciado varios de estos errores con trágicos accidentes y numerosas víctimas mortales.

Sobre el número de muertos

Los números NO son reales, los reales pueden ser menores o mayores, nadie lo sabe, pero no es ninguna broma ni hay que frivolizar con ello. Dicho esto, sí que se puede utilizar como crítica a algo con lo que me he topado muchísimo en los últimos cinco años: la falta de rigurosidad a la hora de hablar de muertos en discursos de seguridad y control de calidad.

Hay formas de hablar de muertos con rigurosidad, sin dar cifras que no se tienen y amparándose en casos reales. Un buen ejemplo se describe en el famoso vídeo viral de la presentación de Álvaro Sauras, “La idiotez del coche eléctrico” y el caso (o casos) de los aceleradores defectuosos de Toyota. En él, se exponen relatos con datos históricos, acordes y apropiados.

En dicho vídeo también se expone el famoso cálculo necrocapitalista de Ford, donde se valora el coste de corregir un defecto en su flota de vehículos frente al de indemnizar a la familia de los futuros muertos manteniendo el defecto. Asumiremos ingenuamente y por salud mental, que estas prácticas ya no se realizan, o no tan descaradamente.

Lo que nos encontramos en numerosos discursos de expertos se aleja tangencialmente de la calidad da la presentacion de Sauras: opiniones y datos sacados de la manga. Especialmente en aquellas presentaciones “de puertas para dentro” y no publicadas.

Y es que ya he tenido que preguntar en no pocas ocasiones por el origen de las fuentes, algo que puede percibirse violento, incluso aunque lo hagas en privado tras la exposición. He llegado a escuchar a un profesor asegurar que la falta de llaves en un if provocó la caída en picado al mar de avión de pasajeros de Boeing. La respuesta siempre suele ser la misma: “no recuerdo ahora, fue de un estudio ahí…”, “me lo dijo Pepito que es un reconocido experto en seguridad…”, etc.

Lo cierto es que rara vez se revela código en los resultados de auditorías internas, sin importar el daño que haya podido causar. Es realmente difícil asociar fallos de programación concretos a víctimas mortales, no porque no se produzcan, no porque no se haya determinado la causa, sino porque no se revela públicamente el detalle. En su lugar se resume en “error o negligencia de programación”.

¿Y la razón? A lo mejor te preguntas si es que los jueces son gilipollas o qué, pero resulta que matar gente no es motivo para revelar tu inversión, amparado por la ley de propiedad intelectual, aunque esto pudiera ayudar a que otros no cometan el mismo error.

Doy fé de que en muchas auditorías se encuentran fallos que por muchísima suerte no llegan a producir víctimas mortales, pero que eventualmente y sin lugar a dudas las producirían de no haberse auditado. Las auditorías suelen contar con al menos una clausula de confidencialidad, que solo se podría romper en caso de que la empresa auditada no estuviera dispuesta a iniciar un proceso con carácter inmediato para corregir el defecto potencialmente mortal, paralizando cualquier servicio si es necesario.

Todo esto hace que el número de víctimas habidas y por haber sea un completo misterio, pero que las hay y las habrá, no cabe duda. Como sea, cualquier alarmismo y exageración es bienvenida si eso implica evitar accidentes mortales por malas prácticas de programación, y aún más si viene acompañado de tips y soluciones.

Soluciones

Los problemas seleccionados tienen algo en común: son fácilmente prevenibles incluso de manera automática, y aún así siguen estando muy presentes en múltiples desarrollos.

Algunos quedarían totalmente evidenciados con tan solo un correcto linter + formateador. Otros se podrían prevenir con un flujo de trabajo que implique una correcta especificación de requisitos y el desarrollo de tests adecuados.

Por supuesto, lo más importante es la divulgación y menos cultura punitiva para no disuadir del informe de errores. Esto es un problema que afecta al desarrollo de software en general, libre o privativo.

Aclarar que estas soluciones deberían aplicarse siempre, haya o no vidas humanas en juego, pues influyen en la calidad de cualquier desarrollo.

Próximamente

Aprovecho a comentar que este mes de abril me encontraré por la península, asistiendo a algunos eventos e impartiendo dos cursos relacionados al tema de esta entrada:

• Valladolid. Del 1 al 4 de abril. Impartiendo un curso de “Seguridad en el desarrollo” para la junta de Castilla y León.
• Mérida. Del 21 al 24 de abril. Impartiendo un curso de “Calidad del software, estándares y metodologías”, orientado a ingenieros y/o técnicos de la Dirección General de Digitalización de la Administración de la Consejería de Economía, Empleo y Transformación Digital de la Junta de Extremadura.

Entre medias quedo a disponibilidad para cualquier servicio presencial, algo que rara vez realizo porque soy muy comodón de cara a salir de las islas.