Las buenas prácticas en el desarrollo de software no han surgido de la mente de un genio dictador. Son el resultado de la experiencia. Fue Thomas Edison quien dijo, tras lograr que su invento de la bombilla funcionase, que descubrió 999 formas de cómo no hacer una bombilla antes de conseguirlo. Las buenas prácticas son un conjunto de normas que si se cumplen en el trabajo, no se asegura el éxito, pero sabes que tus probabilidades de tener problemas son sensiblemente menores.
No seguir las buenas prácticas en el desarrollo te lleva a acumular deuda técnica, lo que es un problema serio en el futuro y puede llevarte a un lugar del que no puedes escapar, y verte abocado a rehacer gran parte de lo desarrollado desde cero. Pero además, puede ocurrir algo peor, el resultado puede ser directamente una catástrofe, un desastre tecnológico que te lleve incluso a que tu negocio esté en riesgo de poder continuar o incluso a salir en la sección de sucesos en los periódicos.
Me voy a permitir comentar aquí algunos ejemplos que siempre he tenido presentes y que cuento alguna vez cuando un cliente me pide que me adentre con demasiada frecuencia por el camino oscuro de trabajar únicamente orientado a conseguir una fecha de entrega y dejar de lado los aspectos de calidad en el trabajo.
Fuego amigo en la primera guerra del Golfo
25 de febrero de 1991, se lanza un misil Patriot desde Arabia Saudí con el objetivo de destruir un misil Scud iraquí que estaba en pleno vuelo. El fallo es total. En lugar de interceptarlo, explosiona contra una barraca americana y mueren 28 soldados estadounidenses y resultan heridas otras cien personas. Tras investigar el caso, la conclusión del informe es que la causa del error fue un fallo en el software.
La conversión del tiempo en décimas de segundo que se utilizaba en los cálculos para definir la trayectoria del misil perdía precisión durante los cálculos internos, lo que provocaba un error de 0,34 segundos que puede no parecer mucho, pero teniendo en cuenta que un misil Patriot alcanza una velocidad de 1.676 metros/segundo, el error en el objetivo era importante y fue letal.
Radiación excesiva en el Therac-25
Entre los años 1985 y 1987 se utilizó la máquina de radioterapia Therac-25, con indeseables consecuencias en al menos seis casos, ya que causó la muerte de al menos tres pacientes, tras ser sometidos a una dosis masiva de radiación de unas cien veces la recomendada. El origen del problema se identificó como una condición de carrera. Esto quiere decir que en algunas ocasiones, dependiendo del orden en que se ejecutaran determinados procesos en la máquina durante la sesión de radioterapia, se llegaba a este mal funcionamiento.
Fue un caso digno de análisis dentro de la informática médica y que aún hoy está de actualidad, ya que son cada vez más las situaciones en las que las máquinas ayudan a los equipos médicos en las operaciones, con el fin de aprovechar la precisión de los sistemas informáticos para conseguir resultados que serían imposibles para un ser humano. En esta ocasión el fallo se mostraba en la consola, pero podía ser ignorado por el operador y aun así proceder con la dosis con resultados devastadores.
La sonda MCO de la NASA y los sistemas métricos
Tras un viaje de once meses, la sonda Mars Climate Orbiter (MCO) llega a Marte el 23 de septiembre de 1999. Su objetivo era estudiar el clima de Marte y la duración de la misión era de aproximadamente dos años. Sin embargo, duró bastante menos. Conforme pasaba el tiempo, se fue observando desde el control de la misión que la sonda se desviaba de su trayectoria cuanta más influencia tenía la gravedad de Marte, con el resultado de que en lugar de sobrevolar el terreno marciano a unos 150 kilómetros de altura, lo hizo a 57, lo que provocó que la fricción con la atmósfera destruyese por completo la sonda.
El orígen del problema no fue en este caso nada fino. Desde el control en la Tierra se utilizaba el sistema métrico anglosajón y enviaba así los datos a la nave, mientras que la sonda hacía los cálculos con el sistema métrico decimal. En las pruebas que se hicieron en la Tierra con anterioridad al inicio de la misión no se dio suficiente importancia a las desviaciones de trayectoria que se identificaron.
La reforma sanitaria de Obama y su web healthcare.gov
El sistema que soportaba las funcionalidades ofrecidas desde la web healthcare.gov era una de las promesas estrella de la administración demócrata. Había costado 400 millones de dolares y al poco tiempo de entrar en funcionamiento, colapsó. El presidente Barack Obama se había comprometido a que el 1 de octubre de 2013 el sistema estaría en funcionamiento y lo cumplió. Para ello, el proyecto ignoró un buen número de buenas prácticas que hizo que la web no pudiese funcionar con normalidad y las quejas se contasen en cientos de miles. Hubo problemas de integración, de arquitectura del sistema, de requisitos; en definitiva, el arquetipo de proyecto caro, grande y con fechas imposibles.
Este último caso es muy interesante y recomiendo leer el reportaje que publicó Time sobre el equipo que lideró la crisis y que consiguió recuperar la situación hasta lograr que el sistema funcionase de forma aceptable.
El líder del equipo, Mickey Dickerson, definió tres reglas básicas que se debían cumplir durante la crisis y las puso en un tablón, en lugar visible por todos:
1.- Las salas y las reuniones son para resolver problemas. Hay otros lugares donde la gente puede aplicar su energía y creatividad para culpar a otros.
2.- Los que deben estar hablando son las personas que más saben sobre el tema, no aquellas con el rango más alto.
3.- Hay que mantener el foco en aquello que nos haga más daño en las siguientes 24-48 horas.
Puede parecer que estos problemas solo se dan en proyectos grandes de millones de dólares, pero no es cierto. En cualquier sistema informático de una pyme se puede plantear un problema de este tipo, que sea un auténtico desastre para el empresario y que le impacte en el negocio de forma seria. La prevención es la mejor opción, pero en la vida real asumimos riesgos por diversos motivos y esos riesgos en ocasiones se materializan en problemas reales. En estos casos, lo importante es formar un equipo, definir un plan y confiar en que el líder del equipo tenga la suficiente sangre fría y la inteligencia para conseguir minimizar los daños y recuperar la situación.
Imágenes texto: Misiles Patriot, Sonda MCO
Foto portada: Jukka Zitting