Si hay algo que cualquier persona relacionada con la programación conoce bien, es el concepto de los “bugs”. Estos fallos, que suelen aparecer en alguna etapa del ciclo de desarrollo del software, a menudo durante la fase de programación, son conocidos en el argot técnico como “bugs” (que en inglés significa “bichos”). Según la leyenda, este término peculiar proviene de un incidente en el que una polilla, sí, una polilla común, causó un fallo en el relé electromagnético de un ordenador.

Foto del origen de la leyenda acerca del primer “bug” informático conocido.

La historia detrás de este primer “bug” informático se remonta a Grace Murray Hopper, una destacada matemática y programadora que trabajaba en el Mark II. Se dice que, al encontrar la polilla causante del fallo, la pegó en la bitácora del equipo y la denominó como “bug”, describiendo así la causa del problema. Si bien esta anécdota puede ser o no cierta, lo que es innegable es que el término ha existido desde los primeros días de la programación.

Durante el proceso de desarrollo de software, es común que múltiples personas trabajen en diferentes partes del sistema, lo que a menudo conduce a la aparición de errores. Estos “bugs” han sido clasificados por los desarrolladores según su comportamiento, y aquí presentamos con un toque de humor algunas categorías que seguramente te resultarán familiares.  

Bug “porque yo lo valgo”

Este es el tipo de bug que no debería existir, pero tiene todas las características para serlo. Se trata de un error provocado por un desarrollador que hace un “commit” a última hora, sin ejecutar las pruebas unitarias, y termina su trabajo sin preocupaciones. A veces, tienes suerte y el servidor de integración continua te alerta sobre el problema; otras veces, te enteras en el peor momento posible.

Bug “bomba ninja”

Este error misterioso surge repentinamente en código que ha funcionado correctamente durante mucho tiempo. Por lo general, se encuentra en el código comentado para pruebas, que accidentalmente se ha subido al repositorio. El resultado puede variar, desde la confesión del desarrollador (“¡mierda, la cagué!”) hasta la sorpresa de un compañero de equipo que se encuentra con el problema (“¡Pero qué pufo me ha dejado!”).

Bug “hazlo tú”

Este tipo de bug está asociado con los desarrolladores entusiastas que incorporan todas las tecnologías posibles en su código. Cuando te enfrentas a su trabajo, es mejor dejar que ellos mismos lo solucionen y decirles: “Te has venido arriba, así que mejor hazlo tú”.

A veces, sin embargo, la situación requiere que “cojas el toro por los cuernos” y te enfrentes al código con valentía y determinación. Te pones a tocar aquí y allí y “que Dios te pille confesado”.

Bug “paranormal”

El más allá existe. No funciona nada y nadie ha tocado nada. Miradas de desconfianza, misterio e indignación para demostrar que ni tú, ni tu equipo sois los culpables.

Las reacciones pueden ir desde el alivio de encontrar la causa hasta la aceptación resignada de que algo externo está interfiriendo con el sistema. Explicamos más al detalle los niveles:

• Nivel “Rocky IV”: Encontramos el problema ajeno y nos regocijamos con orgullo y satisfacción: “Ya había dicho que no habíamos tocado nada y el error no era nuestro”.
• Nivel “Oda Mae Brown”: Ese bug al más estilo pitonisa de la película Ghost. El elemento externo está haciendo algo que se suponía que no hacía y rompe lo nuestro, pero no pasa nada, tenemos la clara excusa de decir que no estaba en nuestras manos prevenir esto.
• Nivel “Mister Bean”: Encontramos un error con lo que no contábamos y que ha llegado para traernos diversión a nuestro monótono día.

Bug “Forrest Gump”

Este bug es aquel que todavía no se ha reportado, por lo que no existe oficialmente. Todos saben que es un problema importante y que tarde o temprano saldrá a la luz, pero ni es el momento ni se dispone de tiempo para pensar en eso. Se opta por ignorar el problema, posponer su solución y vivir con la ilusión de que cuando caiga, nos pille bien lejos… ¡corre, Forrest!

Bug “Ecce Homo”

Hoy es un gran día, te sientes motivado, ves un trozo de código que no es tuyo y dices: “¡Qué cosa más fea!”, y en un arranque de inspiración divina lo rehaces a tu gusto. En este impulso de creerte artista, has olvidado por completo que no conoces el código y cuando el bug salta, no te quedan más opciones que: callarte e intentar deshacer tu obra de arte o dar explicaciones por aquel día tan inspirado y asumir con responsabilidad que tus compañeros te repitan una y otra vez “¿Por qué tocas?”.

Bug “Gandalf”

Ese bug que piensas que se ha solucionado pero no, se ha ido a los p** infiernos y vuelve convertido en mago blanco, más fuerte que nunca.

Bug “Expediente X”

Maldito día, todo falla, imposible encontrar el error. Te vas a casa asqueado y al día siguiente está todo solucionado. No sabes cómo ni por qué, tampoco te importa, solo sabes que “la verdad está ahí fuera…”

Reflexión y agredecimiento

Ya sea en el trabajo o en cualquier aspecto de la vida, el humor es una excelente manera de enfrentar los errores y aprender de ellos.

¿Y tú, prefieres corregir el código o eliminarlo por completo?

Agradezco a Ángel Cereijo por las risas compartidas y enseñarme lo complicado que es ser un buen desarrolladores de software cuando las circunstancias no son las más idóneas.