A Default Is a Decision You Stopped Making

Un local me avisó que su evento no aparecía en el sitio público. Ese fue todo el reporte, y era exacto.

El evento existía. Estaba activo, el local estaba activo, y la tarifa había quedado exonerada en cero sobre una factura que se había procesado correctamente. Todo lo que normalmente sospecharía estaba en orden.

Era un booleano, puesto un mes antes, por una razón que había dejado de ser cierta.

Parecía plata

Mi primer instinto fue la facturación, porque el local estaba con una exoneración y las exoneraciones son nuevas. Una factura en cero es justo el tipo de cosa que puede dejar un registro a medio escribir, y un local que nunca paga es un local que nunca activa ninguna de las verificaciones que construiste alrededor de pagar.

Así que miré ahí primero y no encontré nada mal. La factura estaba exonerada y cerrada. La cuenta estaba activa, con su marca de tiempo. El evento estaba vivo.

Esto pasa lo bastante seguido como para que ya debería esperarlo. La parte más nueva y menos confiable de un sistema atrae sospechas sin importar si tiene algo que ver, y el culpable real suele ser más viejo y más aburrido. La facturación era inocente y lo había sido todo el tiempo.

Era una bandera de agosto

Todos los eventos de ese tipo se crean como privados. No por configuración ni por elección. El valor está escrito directamente en el camino de creación.

Fue una decisión deliberada, y cuando se tomó era la correcta. En ese momento los eventos de esa clase no debían listarse públicamente. El acceso era por credencial, el público era invitado, y una lista pública habría estado mal. Alguien escribió un comentario corto al lado explicando justamente eso, y por eso conozco el razonamiento en vez de adivinarlo.

Después el producto cambió. Esos eventos ganaron una agenda pública, una página pública, y un modelo de ingresos que depende de que la gente los encuentre. Todo eso daba por sentado que los eventos serían visibles.

El razonamiento detrás del valor por defecto caducó. El valor por defecto no.

Nada te avisa cuando una razón muere

Esta es la parte que sigo dando vueltas, porque no se me ocurre un mecanismo que lo hubiera detectado.

El comentario era cierto cuando se escribió. Ninguna prueba falló, porque el comportamiento era intencional y las pruebas codificaban esa intención. Ninguna alerta sonó, porque no había nada roto en ningún sentido que una máquina pueda medir. El sistema hizo exactamente lo que le dijeron, y lo que le dijeron era correcto en agosto e incorrecto en septiembre.

Un valor por defecto es una decisión que se sigue aplicando mucho después de que alguien deje de pensarla. Ese es todo su sentido, y también su modo de falla. Cada uno carga una suposición sobre el mundo, y el mundo no manda un aviso cuando se mueve.

La parte que lo empeoraba

Incluso sabiendo que el valor estaba mal, el local no podría haberlo arreglado.

El camino de creación escribía la bandera sin condiciones. El de edición ni siquiera llevaba el campo, así que no existía ninguna petición que alguien pudiera hacer para cambiarlo. Un solo escritor, un solo valor, y ninguna segunda opinión en todo el producto.

Vale la pena separar eso de la decisión original, porque es un error distinto. Elegir un valor por defecto es un juicio, y los juicios pueden envejecer mal. No ofrecer ninguna forma de anularlo es una decisión de diseño que elimina la posibilidad de recuperarte de tu propio juicio. Una configuración que los usuarios no pueden cambiar no es un valor por defecto. Es una ley.

El arreglo tuvo dos partes. Hubo que corregir el valor guardado directamente para el evento que ya estaba en vivo, y después el producto necesitaba el control que debió existir desde el principio: una casilla visible, desmarcada, tanto al crear como al editar.

Lo que me llevo

No creo que la respuesta sea tener menos valores por defecto. Los valores por defecto son lo que mantiene usable un software, y pedirle a un local que decida todo al momento de crear sería peor que este error.

Lo que quiero es un disparador. Cuando el modelo de un producto cambia de forma grande, y el nuestro cambió cuando esos eventos pasaron a ser cosas públicas con páginas públicas, el trabajo no termina en la función nueva. En algún lugar del código están los valores que codificaban el modelo viejo, todavía aplicados por código que no tiene idea de que el mundo se movió.

No se van a anunciar solos. No fallan. Siguen haciendo exactamente lo que pediste, y la única señal que recibes es un cliente contándote que falta algo.