Idea principal

El contexto que absorbe los correos de una comunidad de vecinos empieza con un archivo context.md y una frase: agrega y trocea por temáticas. Ese nivel aguanta hasta que se constata que el estado actual ha borrado el historial de la obra — y se añade un log cronológico. Vuelve a aguantar hasta que los homónimos y los apellidos dobles producen fichas duplicadas — y se escriben directrices de negocio. Luego el archivo supera las mil líneas y la ventana del modelo se pierde en él — se sacan las directrices, y después se trocea por temática. Luego el vocabulario técnico se repite en cada archivo — se centraliza en un glossary.md.

Cada escalón tiene, pues, una causa que se puede nombrar, y esa causa es siempre una avería del nivel anterior, nunca una mejora deseada en abstracto. Es lo que distingue una subida en complejidad de un sobreingeniería: la primera responde a una necesidad que se ha manifestado, la segunda a una arquitectura que parecía bonita. La prueba está disponible antes de cada piso — ¿qué problema concreto, ya encontrado, suprime este piso?

El orden que resulta tampoco es intercambiable: solo se puede trocear limpiamente por temática después de haber sacado las reglas de tratamiento, si no, no se sabe qué hay que copiar en cada trozo. Y en cada escalón se dispone de un sistema que funciona — no de una obra a medias que solo servirá una vez terminada.

Por qué es importante

Esto da la vuelta a la manera de abordar un sistema descrito por otro. Ante un modelo completo — carpetas, manifiestos de carga, notas atómicas enlazadas —, la lectura natural es la de un plano que instalar; la lectura útil es la de una trayectoria, de la que solo se retoman los pisos cuya avería ya se ha encontrado.

También da un criterio de decisión para las versiones siguientes: se cambia de versión porque las necesidades han crecido, y constatar que una necesidad no ha crecido es razón suficiente para quedarse donde se está.

Matices y límites

Algunas averías son previsibles para quien ya ha construido un sistema comparable, y esperar a que ocurran cuesta una migración que se habría podido evitar. La regla protege de la sobreingeniería, no de la ingenuidad.

Y no todas las averías se manifiestan como una carencia. La pérdida de precisión de un modelo sobre un archivo largo no produce ninguna alerta: degrada lentamente respuestas que siguen siendo plausibles, y el escalón siguiente solo se franquea si alguien ha nombrado el mecanismo de antemano.

Preguntas abiertas

• ¿Qué indica, en un sistema ya instalado, que ha dejado de bastar, cuando la avería no toma la forma de una respuesta manifiestamente falsa?