Un jueves de julio me senté a revisar mi propia infraestructura de casa. No buscaba nada en concreto. Terminé el día con siete cosas rotas, y lo que me quitó el sueño no fue que estuvieran rotas.
Fue que ninguna de las siete me lo había dicho. Al contrario: seis de ellas llevaban meses diciéndome que todo iba bien.
La misma historia, siete veces
Tengo un vigilante de la calidad del aire. Lee una estación meteorológica, y si algo se dispara, avisa. Ese día su registro decía lectura OK. La estación no estaba devolviendo ningún dato. Ninguno. El OK no significaba “he medido y está bien”: significaba “he llegado al final de la función sin reventar”.
El mismo vigilante, un rato después, dejó escrito episodio remitido con su palomita verde. Nadie había medido nada. El “todo despejado” se había fabricado desde la ausencia de dato: como no hay lectura que supere el umbral, no hay alerta, y si no hay alerta es que se está bien. Impecable. Y falso.
Tengo un monitor de servicios, de esos con el panel lleno de puntos verdes. Todo en verde. Una de las fuentes de datos que consume llevaba seis días muerta. El monitor comprobaba que el servicio respondía. Y respondía: respondía muy rápido, con nada dentro.
El notificador de ese mismo monitor —el que me manda el aviso al móvil— llevaba dieciocho días mudo. Lo comprobé, y el webhook devolvía un 200 perfecto. Un 200 OK es un acuse de que alguien recibió tu petición, no una promesa de que hizo algo con ella. Yo había leído dieciocho días de silencio como “no ha pasado nada”.
Tengo un script para responder correos. Terminaba imprimiendo RESPUESTA ENVIADA. Y la enviaba, sí. A casi todos: en los hilos con varios destinatarios se dejaba uno fuera. El mensaje salía, el script no fallaba, y la persona que faltaba simplemente no se enteraba de nada. Nadie se queja de un correo que no ha recibido.
Tengo un grillo, un aviso diario que me recuerda lo que llevo demasiado tiempo sin hacer. Llevaba días dándome la brasa con unas bandejas sin vaciar. Estaban vaciadas. Lo que faltaba era el sello que lo registraba. El grillo no miraba las bandejas: miraba si alguien había dicho que las había mirado.
Y el séptimo, que es mi favorito. Al cerrar un proyecto —una radio que tuve emitiendo un año— revisé que no quedara nada colgando. Encontré unas tareas programadas, vivas, preparadas para volver a anunciar el cierre de la radio en julio de 2027. Se habían programado como anuales sin querer. La radio llevaba meses apagada y su maquinaria seguía ahí, en silencio, esperando su turno para dar una noticia de hace un año.
Lo que tienen en común
Ninguno de estos siete es un error de programación. Todos hacen exactamente lo que les dije que hicieran.
El problema es qué le pregunté a cada uno, y en los siete casos me equivoqué de pregunta de la misma manera:
| Lo que preguntaba | Lo que debería haber preguntado |
|---|---|
| ¿Ha terminado la función? | ¿Ha medido algo? |
| ¿Responde el servicio? | ¿Responde con datos? |
| ¿Aceptaron mi petición? | ¿Llegó el aviso a mi móvil? |
| ¿Salió el correo? | ¿Salió a todos? |
| ¿Alguien dijo que se vació? | ¿Está vacía? |
Todas las de la izquierda se pueden contestar sin salir de casa. Todas las de la derecha obligan a ir a mirar. Y por eso escribí las de la izquierda: son más fáciles, más rápidas y no fallan nunca.
Ese es justo el problema. No fallan nunca.
Un error ruidoso se arregla. Uno que miente en verde te enseña a no mirar
Si un script revienta con un stack trace de veinte líneas, lo arreglas esa tarde. Molesta, canta, interrumpe. El error ruidoso es un aliado maleducado.
El que miente en verde hace algo mucho peor que fallar: te educa. Cada día que ves el panel entero en verde, tu confianza en ese panel sube un poquito. A los seis meses ya no lo lees: lo ojeas. Y el día que de verdad se rompa algo, tendrás delante la misma pantalla verde de siempre y la mirarás con los mismos ojos con que se mira un cuadro que lleva años colgado en el pasillo.
El sistema no te ha fallado ese día. Te ha estado entrenando durante seis meses para que no le hagas caso.
Por eso los siete casos me parecieron el mismo caso. No es una racha de mala suerte, ni siquiera un problema de código. Es un problema de diseño de la confianza: había construido siete cosas que me decían que estaban bien, en lugar de siete cosas que comprobaran si lo estaban.
La regla que saqué, que cabe en una línea
Comprueba el estado real. No te fíes de una declaración de estado.
El grillo se preguntaba "¿me han dicho que se vació?" cuando podía preguntar "¿está vacía?". La diferencia entre esas dos preguntas es todo el artículo.
Y tiene una consecuencia incómoda: un chequeo que siempre pasa no es un chequeo. Si llevas un año sin que salte una alarma, hay dos explicaciones, y solo una es buena. Merece la pena romper la cosa a propósito de vez en cuando para ver si alguien se queja. Si nadie se queja, ya sabes lo que tienes.
Lo dice mucho mejor un proverbio que me recordaron hace poco: el camino del infierno está empedrado de buenas intenciones. La versión original, la de verdad, no habla del daño que hacemos queriendo ayudar. Habla de deseos que nunca se llevaron a cabo. De la distancia entre querer y hacer.
Una comprobación que no comprueba nada es exactamente eso. Una buena intención.