juanjonavarro.com

secciones

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.

5 Comentarios
César Tardáguila
14 septiembre 2005, 16:19 — #1
Buen paralelismo, Joaquín. Me gustaría destacar dos de las conclusiones que has extraído. Por una lado, la importancia de las pruebas de integración ( hay sitios donde no sólo no se hacen, sino que las integraciones ni se contemplan en las planificaciones ), y por otro, la importancia de APIs bien hechas, que por un lado, sólo permitan hacer las cosas bien, y por otro, disminuyan el acoplamiento lo más posible. Son dos factores en los que deberíamos poder invertir más tiempo y esfuerzo.
César Tardáguila
14 septiembre 2005, 16:20 — #2
Perdona, Juanjo. Tenía la cabeza en otra cosa, y te he cambiado el nombre...
Joserra
14 septiembre 2005, 18:41 — #3
Creo que el problema es que esto es diferente a otras ingenierías. ¿quién asegura que determinado software funciona bajo unas determinadas condiciones? Sin embargo si te lo pueden asegurar de un puente, en la arquitectura, de un componente eléctrico, en telecomunicaciones, de un componente mecánico bajo determiandas temperaturas, en ingeniería industrial.

Pero aquí no nos cabe en la cabeza un sistema complejo entero, no lo vemos en su totalidad y no es posible ni simularlo, ni someterlo a TODAS las pruebas que pueden existir para verificarlo.

Debemos tender a aprender de todas las cosas que comentas, Juanjo, de eso no tengo ninguna duda. Pero creo que subyace algo diferente en el concepto fundamental.
Miguel Ángel
15 septiembre 2005, 12:22 — #4
Continuando la línea de paralelismos, quizá las pruebas con respeto a un edificio y la arquitectura si son adecuadas. Con las pruebas de carga, cayó este pasado julio la mitad de un edificio supermoderno que estaban construyendo muy cerca de mi casa. ¿Cuánto cuesta realizar unas pruebas de carga equivalentes al esfuerzo que debe soportar un edificio en relación al importe global de su construcción? ¿Cuánto costaría en el caso del software enfrentarlo a pruebas de usuarios respecto al tiempo global de desarrollo? En el caso de mi empresa no existen esas pruebas de carga. No creo que sea un problema del esfuerzo a dedicar, sino que como un fallo no tiene las mismas consecuencias, no importa porque sea la implantación la que pruebe el producto.

Otro punto, resulta curioso que internamente, estamos intentando en mi empresa que se informe a los implantadores sobre los bugs resueltos con cada nueva versión liberada de producto... y no lo conseguimos.
Juanjo Navarro
15 septiembre 2005, 19:08 — #5
Joserra, yo soy el primero que ha defendido siempre que no se puede comparar la ingeniería del software con otras ingenierías (ni, si vamos a ver, a unas ingenierías con otras). Creo que se ha hecho mucho daño intentando comparar a la programación con "una fábrica" (recordar el termino "factoría de software") sin tener en cuenta que una fábrica se caracteriza por el trabajo repetitivo después de una primera fase creativa de "invención" del producto, frente al trabajo creativo y cambiante que tiene lugar en todas las fases del desarrollo de software.

Pero estoy con Miguel Ángel en que no somos "tan" distintos. Es decir:

-¿No es un sistema complejo como una central nuclear suficientemente grande para no cabernos en la cabeza?

-¿Qué es más difícil, probar la aerodinámica de un objeto (para lo cual hay que crear *físicamente* túneles de viento) o probar un componente software?

-¿Porqué no se puede asegurar que un software funciona bajo unas determinadas condiciones?

Y efectivamente, Cesar, creo que una de las claves es el diseño de API. Hay algunas APIs por ahí que es casi "imposible" emplearlas bien. No solo es que están sin documentar sino que parece que las ha creado "el ingeniero venido del infierno". :-)


Comentarios cerrados para este artículo

Siguiente: ¿Idea de negocio? Web de Nombres