Las tres normas de Gremlins son las tres normas del desarrollador

Hoy, 8 de junio, cumple años Gremlins. Se estrenó en 1984, la dirigió Joe Dante y salió de Amblin, con Spielberg como productor ejecutivo y guion de Chris Columbus.

Y viene con uno de los mejores manuales de operaciones jamás escritos. Tres normas. Tres. Cortas, memorables y entregadas antes que el sistema:

1. No lo mojes.
2. Mantenlo lejos de la luz fuerte; la del sol lo mata.
3. No lo alimentes después de medianoche.

Cualquiera que haya trabajado en producción sabe cómo acaba esto. Y también sabe que el problema nunca fue el Mogwai.

Yo tengo mis tres normas. Llevo más de veinte años repitiéndolas y las sigo viendo romperse con una regularidad que ya no me sorprende:

1. No hagas deploy el viernes.
2. No toques producción directamente.
3. No hagas un UPDATE sin WHERE.

El paralelismo no es solo una gracia: unas y otras se rompen de maneras que se parecen mucho.

Cartel de Gremlins (Warner Bros., 1984), reproducido a título de cita. Derechos de sus titulares.

Norma 1: no lo mojes → no hagas un UPDATE sin WHERE

Esta es la pareja perfecta, y no por el chiste: por la multiplicación.

Mojas un Mogwai y no tienes un Mogwai mojado. Tienes cinco. El daño no es proporcional a la acción: se reproduce solo.

-- Lo que querías
UPDATE usuarios SET plan = 'premium' WHERE id = 4213;

-- Lo que ejecutaste
UPDATE usuarios SET plan = 'premium';

Ocho caracteres de diferencia. Y no has modificado un registro de más: has modificado todos. Cuarenta mil. Como fue un solo comando y terminó sin error, la base de datos responde Query OK y se queda tan tranquila.

Eso es exactamente el agua sobre la piel del Mogwai. Una acción pequeña, un resultado que se extiende por sí mismo y ningún aviso.

Lo que hago cuando toco datos a mano:

• Escribir el WHERE primero. Literalmente: empiezo la frase por el final y luego escribo el UPDATE delante.
• Ejecutarlo antes como SELECT. Si ese WHERE devuelve cuarenta mil filas, me entero antes de romper nada.
• Abrir transacción cuando el motor lo permite: BEGIN, mirar el número de filas afectadas y solo entonces COMMIT.
• Y no trabajar cansado sobre la base de datos de producción, que es la norma que de verdad previene el incidente y la que no suele aparecer en ningún procedimiento.

Norma 2: nada de luz fuerte → no toques producción directamente

Aquí la película es más precisa de lo que se recuerda: la luz fuerte les hace daño, pero la del sol los mata en el acto. Hay grados, hasta que dejan de haberlos —al final, Gizmo abre una claraboya y ese es el final de Stripe—, y el problema es que desde fuera todas las exposiciones se parecen.

Producción funciona igual. En tu portátil te equivocas y lo vuelves a intentar. En el entorno de pruebas te equivocas y avisas por el grupo. En producción te equivocas y ya está: los datos que has pisado estaban vivos, el pedido que has borrado era de una persona real y el correo que ha salido a nueve mil suscriptores no vuelve.

Una de las diferencias entre un equipo que va sobrado y uno que va tirando no está en la calidad del código, sino en si existe un camino y solo uno para llegar a producción. Cuando hay dos —el proceso y, además, el acceso directo por si acaso—, el segundo se acaba usando. Sobre todo un viernes a las siete.

Y ojo con la trampa que veo a menudo: tener el proceso montado y saltárselo justo cuando hay una urgencia. Es como decir «los Gremlins no salen de día, salvo cuando hay prisa».

Norma 3: no lo alimentes después de medianoche → no hagas deploy el viernes

Aquí está la norma más famosa, la más rota y la que esconde el mejor chiste técnico de la historia del cine, aunque nadie lo escribiera con esa intención.

Porque la norma es clara, es memorable y es imprecisa. Piénsalo dos segundos:

¿Después de medianoche hasta cuándo?

Siempre es después de medianoche. Son las cuatro de la tarde y también es después de la medianoche de hoy. ¿A qué hora deja de ser tarde? ¿Al amanecer? ¿Y en qué zona horaria: la del Mogwai, la de la tienda de Chinatown, la del huso donde lo compraron?

Es una especificación sin zona horaria ni ventana definida, o sea, uno de los errores más caros y más repetidos del oficio. Todos hemos vivido su versión moderna:

• El informe «de ayer» que a las 00:30 sale vacío porque el servidor está en UTC y el usuario en Madrid.
• La suscripción que caduca «a medianoche» y se corta a las 22:00 para media plantilla.
• El cambio de hora de octubre, cuando las dos y media de la madrugada ocurre dos veces y el proceso nocturno se ejecuta dos veces con ella.
• El BETWEEN de fechas que se deja fuera el último día porque compara contra medianoche en punto.

Si tu sistema tiene una regla que depende de la hora, la regla no está escrita hasta que diga la zona horaria y los dos extremos del intervalo. «Después de medianoche» no es un requisito: es una conversación pendiente.

Y en cuanto al viernes, el motivo no es superstición ni pereza. El coste de un incidente no lo determina el fallo, sino el tiempo que tardas en enterarte y quién hay disponible para arreglarlo. El mismo error un martes a las diez son veinte minutos con el equipo delante; el viernes a las siete pueden ser dos días de degradación con una persona de guardia mirando código que no escribió.

No es que el viernes se rompa más. Es que el mismo fallo cuesta mucho más.

El problema nunca fue Gizmo

Y esta es la parte que de verdad importa, porque es la que se repite en los informes de incidencia que he tenido que escribir.

Las normas existían. Estaban dichas y eran correctas —imprecisa la tercera, como acabamos de ver, pero correcta—.

Y conviene fijarse en cuáles se rompen de verdad, porque no son las tres a partes iguales. Las dos que desencadenan el desastre son la del agua y la de la comida, y ninguna de las dos se incumplió por una decisión consciente:

• La del agua se rompió por un tropiezo. Nadie decidió mojar a Gizmo: un amigo de Billy le derramó encima un vaso de agua. El accidente doméstico más común del mundo contra una norma bien escrita y bien entendida.
• La de la medianoche se rompió porque el instrumento mentía. Los Mogwai le cortaron el cable del despertador a Billy, así que cuando les dio de comer creía sinceramente que aún no era esa hora. No falló la norma ni falló la persona: falló el reloj, que era la única fuente de verdad disponible para cumplirla.

La de la luz juega en otra liga. No es la que provoca la catástrofe, sino la que la termina: es la vulnerabilidad conocida de los Gremlins y acaba funcionando como el interruptor de emergencia de la película. Todo sistema debería tener una de esas, y conviene saber cuál es antes de necesitarla.

Ahí está la lección, y no es sobre disciplina. Una norma que depende de un dato —la hora, un contador, un estado— hereda la fiabilidad de ese dato. Si el reloj está mal, el procedimiento está mal, y quien lo sigue no tiene forma de saberlo.

A eso se suma que nadie explicó el porqué. «No lo mojes» sin «porque se multiplican» es una superstición, y las supersticiones se saltan en cuanto molestan. Encima la información llegó por el peor canal posible: se la dio de pasada, en la calle, el nieto del dueño de la tienda, que además vendió el Mogwai a espaldas de su abuelo, precisamente porque este se había negado a venderlo. La documentación que no vive pegada a la cosa que documenta no existe.

Por eso los procedimientos no bastan por sí solos y hace falta lo aburrido: monitorización, alertas y copias restaurables. Lo preventivo protege de lo que imaginaste; lo que detecta y lo que recupera protege del resto, que suele ser la mayoría. De eso va insistir en el mantenimiento cuando nadie quiere pagarlo: no es evitar que entre agua, es tener claro qué pasa cuando entre.

Y encima es una película de Navidad

Detalle que me hace una gracia enorme: Gremlins transcurre en Navidad. El Mogwai es un regalo de Navidad y todo se va al infierno en plenas fiestas.

O sea que la película consiste en un sistema nuevo puesto en marcha la semana en la que no hay nadie de guardia.

Cualquiera que haya vivido una campaña de diciembre sabe por qué las empresas serias congelan los cambios en esas fechas. No porque diciembre sea peligroso, sino porque diciembre es el mes en el que el equipo no está.

Los Gremlins no eligieron la Navidad por casualidad. Eligieron la ventana de menor cobertura, que es donde aparecen casi todos los incidentes que acaban siendo caros.

Feliz aniversario

Cuarenta y dos años de la mejor documentación de operaciones del cine.

Si hoy te apetece hacer algo con esto, coge una norma de tu equipo y escríbele el porqué al lado. Si no puedes, no es una norma: es una costumbre. Y si esa norma depende de la hora, comprueba de dónde saca la hora, porque Billy también creía que la sabía.

Y sobre todo: escribe el WHERE primero.

(Gizmo, por cierto, se portó bien toda la película. El único que cumplió el manual fue él.)