La polilla del Mark II ni fue el primer bug ni sabemos quién la encontró

Hoy, 9 de septiembre, se cumplen años del bug más famoso de la historia. La fecha es cierta. La palabra no nació allí. Y no sabemos quién encontró la polilla.

El 9 de septiembre de 1947, durante unas pruebas del Mark II en el laboratorio de computación de Harvard, el equipo localizó una polilla atrapada en el relé número 70 del panel F. La retiraron, la pegaron con cinta adhesiva en el cuaderno de operaciones y escribieron al lado:

«First actual case of bug being found.»

La página, con la polilla todavía pegada, está hoy en el Museo Nacional de Historia Americana del Smithsonian.

La página del cuaderno de operaciones del Mark II, con la polilla todavía pegada. Debajo, la nota: «First actual case of bug being found.» Foto: Naval Surface Warfare Center, Dahlgren, dominio público, vía Wikimedia Commons.

Lo que no es verdad

No es el origen de la palabra. Es la creencia más extendida y la más fácil de desmontar, porque la desmonta la propia nota: si escribes «el primer caso real de un bicho encontrado», es porque «bicho» ya significaba fallo para quien lo lee. El chiste consiste precisamente en que esta vez había un insecto de verdad.

La palabra venía de mucho antes. Edison escribía sobre los bugs de sus inventos en la década de 1870. En la ingeniería eléctrica y mecánica era vocabulario corriente desde hacía décadas.

Y probablemente tampoco la encontró Grace Hopper. Ella formaba parte del equipo del Mark II, pero no hay evidencia sólida de que fuera quien halló la polilla: el Smithsonian atribuye el hallazgo a los ingenieros que trabajaban con la máquina y señala que el cuaderno probablemente no era suyo, aunque no identifica de forma inequívoca a la persona concreta. Lo que sí está documentado es que fue ella quien contó la historia durante décadas, tantas veces y tan bien que la anécdota acabó quedándose con su nombre; y que al contarla situó a veces el episodio en 1945 en lugar de 1947.

Y conviene decirlo en positivo, porque no es mérito pequeño: que un apunte de cuaderno se siga contando casi ochenta años después se debe en gran parte a ella.

La historia bien contada desplaza al hecho

Esto no va de corregir a nadie en una cena. Va de un fenómeno que tienes dentro de tu empresa ahora mismo.

En cualquier equipo con unos años de vida hay verdades que nadie ha verificado nunca y que todo el mundo repite:

• «Ese servidor no se puede reiniciar.» Nadie sabe por qué. Lo dijo alguien que ya no trabaja aquí, en 2019.
• «El cliente exige que sea así.» El cliente lo pidió una vez, hace cuatro años, y la persona que lo pidió cambió de empresa.
• «Esa librería no la actualizamos porque rompe la exportación.» Rompía la exportación en la versión 2. Vamos por la 6.
• «Eso lo probamos y no funcionó.» Lo probó una persona, una tarde, con una configuración que ya no existe.

Ninguna tuvo por qué nacer como mentira: eran decisiones o experiencias concretas que, a fuerza de repetirse sin fecha y sin contexto, acabaron convertidas en política. Y tienen una propiedad muy incómoda: cuanto más se repiten, más caro sale comprobarlas, porque poner en duda algo que todo el mundo da por hecho parece una falta de respeto al que lo dijo.

La forma barata de romper ese ciclo es fecharlas. En cuanto escribes «esto se decidió en marzo de 2021 por este motivo», la afirmación deja de ser folclore y pasa a ser un hecho revisable. Con fecha, cualquiera puede mirar si el motivo sigue existiendo.

Lo que sí merece la pena copiar

Y aquí llega la parte que casi nunca se cuenta, que es la única que sirve para trabajar.

Olvídate de la polilla y mira el cuaderno. Lo que hizo aquel equipo en 1947 fue:

• Anotar la hora. 15:45.
• Identificar el componente exacto. Panel F, relé 70. No «un relé». No «la máquina».
• Adjuntar la evidencia física al registro, junto a la anotación.
• Dejarlo donde el siguiente turno lo iba a leer.

Eso es una entrada de operaciones extraordinariamente útil, resuelta en unas líneas: fija la hora, identifica el componente, registra lo que se encontró y conserva la evidencia. En 1947. Sin plantilla, sin herramienta de ticketing y sin una reunión para decidir el formato.

Compáralo con el estado habitual de un incidente resuelto hoy: alguien lo arregla, lo cuenta por un canal de mensajería del que nadie ha comprobado nunca cuánto tiempo se guarda, y a los seis meses nadie recuerda ni qué falló ni por qué se hizo así. Volvemos a diagnosticar desde cero el mismo problema cada dos años. Lo vimos en los 97 correos de Knight Capital: la información existía y no estaba donde tenía que estar.

El registro que sí funciona

No hace falta ceremonia. Hace falta que exista, que sea buscable y que tenga estos campos:

1. Cuándo. Con hora, no solo con fecha.
2. Qué componente. El equivalente a «panel F, relé 70»: el servicio, el fichero, la versión concreta.
3. Qué se vio. El síntoma observable, no la interpretación. «Devolvía 502 el 30 % de las veces», no «estaba petado». Es el mismo problema que el «falla el sistema» a secas, solo que aquí el que se queda sin contexto eres tú dentro de seis meses.
4. Qué se hizo y qué se descartó. Lo descartado vale tanto como lo hecho: es lo que evita que el siguiente repita el camino.
5. La evidencia. El log, la captura, la traza. Pegada, no referenciada a un enlace que caducará.

Y una regla que ahorra muchas horas: el historial no puede depender solo de un chat. Un chat está hecho para que la conversación avance, no para conservar conocimiento operativo: es una cinta transportadora, no un archivo. El registro tiene que vivir en un soporte buscable, persistente y atado al proyecto. Vale un fichero de texto en el repositorio.

Cuando el incidente es propio, además, escribirlo cuesta el doble y vale el triple. Aquí quedó el mío con unas claves de API, que es de las cosas más útiles que he publicado precisamente porque no me deja olvidarlo.

Feliz aniversario

Tres cosas para hoy:

1. Elige la creencia más repetida de tu equipo y compruébala. Solo una. Ponle fecha al resultado, sea cual sea.
2. Coge el último incidente que resolviste y escríbelo con los cinco campos. Vas a tardar diez minutos y no vas a recordar la mitad. Esa es exactamente la demostración de por qué hay que escribirlo el mismo día.
3. Busca dónde vive el historial de incidentes de tu proyecto. Si la respuesta es «en un canal» o «en la cabeza de Fulanito», ya tienes tarea.

(Y ojo con la moraleja fácil: aquel equipo no estaba intentando hacer historia. El incidente se habría quedado anotado como tantos otros; lo que probablemente salvó esta página del olvido fue la broma y la polilla pegada. Nunca sabes qué registro va a acabar importando —el mensaje con el que Linus Torvalds presentó Linux se abría con «solo un hobby»—, así que más vale escribirlo aunque hoy parezca rutinario.)