¿Bug? ¡Quita bicho!

Cualquier persona que se dedique a la programación o se haya aproximado al mundo del software sabe lo que es un “bug”. Los fallos que aparecen a lo largo del proceso de cualquiera de las etapas del ciclo del software, frecuentemente en la fase de desarrollo y programación son los denominados coloquialmente “bugs” (que en inglés significa “bichos”). Cuenta la leyenda que este curioso nombre se debe a que una polilla (si, si un bicho de esos de la ropa) se metió en el ordenador y provocó un fallo en el relé electromagnético.

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

Grace Murray Hopper, licenciada en Física y destacada matemática que trabajó como programadora en el Mark II, pegó el insecto con cinta adhesiva en la bitácora y se refirió a ella como “bicho” para describir la causa del problema. 

Sea verdad o no esta leyenda, el origen del término es tan antiguo como la programación en sí misma. 

Durante las etapas de desarrollo de software, son muchas las personas que se encuentran programando en diferentes partes del sistema, y no suelen ir trabajando al mismo ritmo, por lo que sus desarrollos no finalizan de manera simultánea y provocan errores que los informáticos han clasificado según su “comportamiento“.

Con la intención de poner un poco de humor al trabajo de los programadores, clasificaremos los “bugs” según las experiencias vividas por muchos de vosotros. ¡Al lío! 

Bug “porque yo lo valgo” 😎

Es ese bug que no tiene porque llegar a serlo pero tiene madera para ello. Es un error provocado por un desarrollador que hace un commit a última hora, sin ejecutar los test unitarios y se va a su casa tan pancho, orgulloso de su trabajo. Si tienes suerte, el servidor de integración continua te avisa y te advierte del problema, si no, ya te enterarás en algún bonito momento. 

Bug “bomba ninja” 😳

Error que aparece “incomprensiblemente” en cualquier momento sobre código que ha funcionado correctamente durante mucho tiempo. El problema se suele encontrar en el código comentado para algún tipo de prueba y que se ha subido al repositorio. Nos podemos encontrar con 2 posibilidades que:

  1. Al desarrollador que le toque ver el código, sea el mismo que lo ha comentado y oigas de repente: “¡mierda!, la cagué”.
  2. El desarrollador sea cualquier otra víctima que no ha tocado nada de ese código y se encuentre una sorpresita maravillosa. Si además el originario del “pufo” se ha ido tranquilamente de vacaciones o ha abandonado el proyecto, te ha dejado un romántico regalo de despedida.

Bug “hazlo tú” 🙄

Esos desarrolladores “cracks” que les apasiona meter todas las tecnologías del mundo y dicen frases cargadas de emoción como: ”Ruby a tope, ¡qué pasada!”. Como sabes la que te espera si intentas meter mano en su código, prefieres hablar directamente con el emocionado en cuestión y decirle: “te has venido arriba, así que mejor hazlo tú”, aunque todos sabemos que no siempre se puede optar por esa medida, es entonces cuando el ego se apodera de ti, te armas de valentía y te pones a tocar aquí y allí, y que “dios nos pille confesados”.

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. 

El resultado puede ser variado:

  • Nivel “Rocky IV”: Encontramos el problema ajeno y no regocijamos con orgullo y satisfacción “ya había dicho que no habíamos tocado nada y el error no era nuestro” (uahahahaha) 
  • Nivel “Oda Mae Brown”: Ese bug al más estilo pitonisa de la película de 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” 😐

Fallo todavía no reportado así que de momento no existe. Todos saben que es un “marrón” de los grandes 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 lejosss ¡corre Forrest!.

Bug “Ecce Homo” 💡

Hoy en un gran día, te sientes motivado, ves un trozo de código que no es tuyo y dices: “¡que cosa más fea”, y en un arranque de inspiración divina lo rehaces a tu gusto. El problema surge porque en ese impulso de “me creo artista y punto” has olvidado que no conoces el código (#fail) y cuando el bug salta no te quedan más opciones que:

  • Callarte e intentar deshacer tu obra de arte (¡ainssss!)
  • Le toca a otro arreglarlo y tienes que darle explicaciones por aquel día tan inspirado, asumiendo tu culpa y escuchando la gran frase de tu compañero: “¡no toques!, ¿por qué tocas?”. 

Bug “Gandalf” 😕

Ese bug que piensas que se ha solucionado pero ¡noooo! se ha ido a los p**** infiernos y volverá convertido en mago blanco, más fuerte que nunca. (ohhh myyyy) 

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, sólo sabes que “la verdad está ahí fuera…”


Ya sea en nuestro trabajo o en cualquier aspecto de nuestra vida, no hay mejor forma de aprender de nuestros errores que con humor. ¿Y tú? ¿Añades código correctivo o eliminas el código erróneo? (sin ofender ¿eh?)

Gracias a Ángel Cereijo por enseñarme lo complicado que es ser un buen desarrollador de software cuando las circunstancias no son las más idóneas, y por cada una de las risas compartidas escribiendo este post. 😉