Cuentos de bichos: Mariposas en el código

 La polilla, una de esas pequeñas mariposas nocturnas que se sienten atraídas por la luz y cuya larva destruye la materia donde anida, es un lepidóptero. En fin, que es un bicho. En telegrafía, y en las primeras compañías telefónicas, era habitual usar la expresión “bichos en el cable de teléfono” para referirse al ruido y las interferencias en la comunicación. Si bien es cierto que la palabra inglesa «bug» ya fue usada para indicar un defecto industrial, y que el mismísimo Thomas Edison dispuso de ella con esta finalidad, es probable que fuera Grace Murray Hopper quien la aplicó por vez primera al ámbito de la informática. Ésta licenciada en física trabajaba como programadora en el Mark II, uno de esos primeros ordenadores que estaba formado por componentes electrónicos y electromecánicos, cuando investigando la causa de un fallo en el mastodóntico computador de IBM, halló una polilla bloqueando el relé 70 del panel F. El hecho se documentó de modo metódico, y el insecto quedó inmortalizado en una foto junto a un texto que rezaba “primera vez que se encuentra (en un ordenador) un «bug» de verdad”. Así comenzó la leyenda del primer bug informático conocido.

 En la historia del sofware han sido muchos, y de muy diversa índole, los bichos que han querido alcanzar la fama que ostenta en el mundo de la ingeniería informática la polilla del relé 70. Los bichos han procurado realizar incursiones en los desarrollos de software desde la primera línea escrita de código, no discriminan ninguna posibilidad. Procuran infectar todo tipo de proyectos, tanto aquellos en los cuales apenas tienen el potencial de provocar pequeños inconvenientes, como eso proyectos susceptibles de costar tres billones de dolares a una empresa de automoción; o como aquel caso, en el que uno de esos malévolos bichos pudo haber desencadenado la tercera guerra mundial: En 1983 el sistema de alerta temprana de la Unión Soviética había detectado el lanzamiento de cinco misiles balísticos, el «bug» que se había colado dentro de aquel sistema hizo que éste confundiera el reflejo del sol sobre unas nubes con unos amenazantes proyectiles. El oficial soviético que se encontraba al mando en ese momento dedujo fríamente que, siendo real el ataque, el número de venablos a cohete superaría cinco con creces. De no ser por su acertada decisión de no reaccionar ante la señal de alerta, el ficticio ataque habría recibido una represalia difícil de explicar a la comunidad internacional.

 Para realizar estas correrías los «bugs» aprovechan cualquier resquicio: falta de conocimientos, poca experiencia, descuidos, momentos de baja concentración… Si bien es cierto que hay quien define que la expresión “sofware libre de «bugs»” es un oxímoron, y que desarrollar sin cometer ningún error que les abra la puerta a estos pequeños enemigos es utópico, hay métodos para combatirlos y reducir su presencia lo máximo posible. Llegados a este punto, es obligatorio nombrar a aquellos que defienden el uso de la programación funcional como modo de evitar los estados mutables (especialmente cuando el proyecto tiende a una explosión combinatoria), reduciendo drásticamente la presencia de «bugs», pero lo que realmente viene a la cabeza al pensar en un modo de desarrollar evitando bugs son los modelos de desarrollo. Uno de los primeros modelos que se nombra cuando se toca este tema es el desarrollo guiado por pruebas (TDD por sus siglas en inglés), en el cual se describen las pruebas de que el código funciona sin errores antes que el propio código. Las técnicas y principios del TDD fueron combinadas posteriormente con los análisis y diseños propios de la programación orientación a objetos (OOP) y el diseño guiado por dominios (DDD) para dar lugar al desarrollo guiado por comportamientos (BDD), el cual es, con casi toda seguridad, el más extremo y completo método de desarrollo de software en lo que a evitar «bugs» se refiere. Este modelo de desarrollo exige un fuerte apoyo en herramientas como, por ejemplo, Cucumber, lo cual puede conllevar un gasto económico extra que, sumado al inevitable aumento del tiempo de desarrollo, hace pensar que no es apto para todos los proyectos.

 Aunque hay proyectos que exigen un aumento del nivel de atención a la gestión de posibles «bugs», éste siempre debe ser, por defecto, lo más elevado posible. A modo de símil, es obvio que no es necesario el mismo nivel de asepsia en el entorno en el se cura una rozadura que en el que se opera a corazón abierto; no obstante, en el caso más laxo de los dos, es indiscutible que también se toman unas precauciones mínimas de higiene. No es necesario usar el mismo modelo de desarrollo para añadir un módulo personalizado a un blog en Worpress y para poner en funcionamiento la transitada tienda web de una empresa de ropa deportiva, la cual conlleva un elevado número de transacciones económicas y no es un proyecto tan inocuo como el primero, pero el nivel mínimo de prevención de «bugs», desde el cual partiremos en ambos casos, ha de ser suficientemente elevado; el error imperdonable, y que nunca se ha de cometer, es rebajar nuestra cota de intolerancia a los «bugs» en pos de la productividad. Una buena conclusión a todo lo expuesto sería la que sigue: En el momento de iniciar un proyecto debemos determinar cuanto es necesario aumentar nuestro estándar de intransigencia a los «bugs» para evitar mariposas en el código.