Cuando el error nos alcanza - Unas palabras sobre los bugs en los sistemas y como enfrentarlos

Estás con tu familia y de repente un grito te estremece "AGUA!". Se está inundando tu casa.... pero de donde sale el agua. se pinchó un caño?

NO! el origen es el inodoro... que se tapó y desborda.

No hay tiempo que perder!  buscar la sopapa, tira toallones al piso para el agua, el secador de piso y organizarse. 

Una vez pasado el mal trago es momento de un análisis. Que pasó?

- La última persona que utilizó el baño tiró en el inodoro una gran cantidad de papel y lo tapó.
- La válvula de salida del tanque del inodoro no cerraba herméticamente, por lo tanto filtraba agua constantemente.
- El piso del baño no tiene el declive adecuado y el agua en vez de ir a la rejilla va a la puerta.

Son tres causas principales. Las cuales una sin la otra no podían ocasionar el desastre.

Este ejemplo escatológico puede ser extrapolado a la mayoría de los desastres que ocurrieron o pueden ocurrir en diferentes escenarios: choques de trenes, caídas de puentes (como el infame conocido Tacoma Bridge), accidentes de aviones... y por supuesto la caída de sistemas informáticos

Generalmente los grandes problemas son un conjunto de pequeños que se combinan para generar la detonación de un desastre. Habitualmente los problemas no se suman entre si, si no que se multiplican. Un pequeño descuido inocente o premeditado pero luego olvidado se puede sumar a otros no descubiertos y encadenarse para un tsunami de problemas.
Los problemas suelen tener diferentes orígenes y responsables. Acá una breve descripción.

Problemas de plantificación (análisis y diseño).

A veces los errores surgen en el nacimiento mismo de un proyecto. Cuando el análisis no es abarcativo y no tiene en cuenta variables importantes que lo afectan (el efecto del viento en el puente de Tacoma). O incluso cuando el análisis inicial no es correcto y se van haciendo correcciones en el camino que dejan errores ocultos.

Estos errores suelen ser los más peligrosos. Porque significan que todo lo construido encima se basa en premisas incorrectas. Encontrar este tipo de problema suele ser traumático porque implica muchas veces tirar grandes porciones de lo realizado - sino todo - para recomenzar. Me viene a la mente el capitulo de los Simpsons donde queriendo construir una piscina, construyen un granero.

El análisis puede ser correcto pero si el diseño es deficiente, también vendrán problemas. Interfaces incorrectas, inenteligibles o confusas son un ejemplo. Procesos complejos se hacen imposibles si no se parte el problema correctamente.

Acá no hay muchas vueltas que dar, para salir airoso de esta etapa se debe saber escuchar y preguntar. Repreguntar si hay dudas, generar ejemplos, imaginar casos de uso.

Documentar también es clave. Adoptada la metodología que sea la documentación siempre es una aliada para el analista. Lo que es confuso o dejado en manos de la imaginación de terceros suele depararnos sorpresas desagradables.

Estar controlando en el desarrollo es fundamental. Nunca desligarse.

Problemas de desarrollo

 

Hasta el mejor de los análisis y diseños se hace polvo si las personas no idóneas se hacen cargo de su concreción. Elegir algoritmos / estructuras de datos / componentes incorrectos nos van a traer futuro dolores de cabeza.
Tener un equipo de desarrollo capacitado, motivado y bien informado es clave en esta etapa. El apuro y la desorganización son los peores enemigos. Las pruebas críticas.

Ante el error, suele ser mas adecuado romper y volver a generar que emparchar. Parche sobre parche hacen código inmanejable.

Los unit test son importantes en este punto. Pruebas de carga también suelen ser buenas opciones.

Problemas de mantenimiento

Liberado el sistema, entramos a una etapa donde hay que cuidar lo que se tiene. Las cosas suelen romperse con el uso. Los usos suelen cambiar con el tiempo. Los espacios se llenan. Los almacenamientos se desorganizan.

Todo sistema debe contar con la planificación de un mantenimiento. Deben existir criterios de verificación de las partes del mismo. Se debe proveer buenos sistemas de alarmas tempranas y equipos abocados a atacar el problema cuanto antes.

Escuchar y ver al usuario en acción es una etapa de descubrimiento en si. Suelen tener ideas propias de como hacer las cosas. Muchas veces por caminos que uno no previo y que suelen hacer que nuestros sistemas no se comporten adecuadamente. La capitación al usuario es fundamental y no debe ser menospreciada: es una forma de marcarle el camino a quien lo tendrá que transitar.

En resumen...

Hace un tiempo encontré por la web una frase que me pareció pertinente:

"The only program without bugs is the program that has run for the last time"

Trabajar bien es fundamental para hacer sistemas de calidad. Pero, dada la complejidad de los sistemas de hoy en día, aguardar ese bug que nos quite el sueño es una posibilidad real.

En ese caso: A arremangarse, armarse de paciencia y a reparar!

El estudio de los desastres, deja grandes enseñanzas. Reglas que uno puede aplicar en futuros proyectos. ¿Qué experiencias tuvieron?

---

La yapa...

Humor por Scott Adams