Los sistemas complejos tienen accidentes

Esta mañana leía una noticia sobre el accidente del viernes pasado en Valencia en el que se vieron implicados tres trenes:

Diario 20 minutos: Dos de los conductores se confiaron y se saltaron un semáforo en rojo que, además, no se veía demasiado bien porque está justo detrás de una curva. Para más inri, el sol les daba de cara y pudo deslumbrarlos.
Además, el primer tren llevaba 10 minutos de retraso, con lo que la distancia de seguridad entre los tres convoyes se redujo sustancialmente. Tras una primera colisión, de carácter leve, no se avisó al tren que iba detrás porque [...] no dio tiempo.

Lo cierto es que esta conjunción de circunstancias desfavorables se suele dar en los accidentes. Os recomiendo que leáis el artículo Learning From Accidents and a Terrorist Attack, donde se analizan algunos accidentes producidos en la ingeniería civil con el objetivo de aplicar las enseñanzas de dichos accidentes a la ingeniería del software. Porque no olvidemos que los sistemas software son muy complejos. De hecho muchas estimaciones consideran que algunos sistemas software son los objetos más complejos construidos nunca por el hombre.

Algunas conclusiones que yo extraigo del artículo:

• En los sistemas complejos, el peligro no está en los componentes individuales, sino en la forma en que estos componentes encajan. (¿Alguien ve aquí similitudes con las pruebas unitarias y las pruebas de integración?)

• Los sistemas individuales fallarán. Hay que minimizar la cohesión (coupling) entre unos sistemas y otros para evitar que un componente con un fallo se comunique a otros sistemas y haga caer al todo. Hay que conseguir evitar que los incidentes se conviertan en accidentes. (¿Un fallo en la conversión de una fecha que termina corrompiendo una base de datos entera?)

• Hay que diseñar las piezas de tal modo que sea imposible ensamblarlas mal. Ejemplo: Conectores que impidan equivocar los polos positivo y negativo. (Aplicado a nuestro campo: Hay que dar la importancia que tiene al diseño de APIs)

• Es necesario aprender de los errores. En los campos de la ingeniería civil, la aviación civil y muchos otros, la información sobre accidentes se comparte y se publica en libros e informes. (Comparar esto con la industria del software, donde la información sobre los errores y los problemas de seguridad es básicamente escondida por las empresas y en muchos casos ni siquiera sirve como fuentes de información entre grupos de la propia empresa).

Creo que es muy importante mirarnos en el espejo de otras ingenierías, aprender lo que hacen bien y cómo lo hacen. Y creo que la gestión de accidentes, cómo se evitan los errores y cómo se gestionan una vez producidos, es una asignatura que tenemos pendiente.