Idea principal

La experiencia técnica se construye en un bucle corto: se prueba, se falla, se busca, se entiende, se corrige, y algo de la corrección se queda. Media hora con un bug acotado, un día con un endpoint que se resiste, un problema retomado al día siguiente: es ese rodeo el que enseña a reconocer las señales débiles de un código y a intuir que una solución demasiado fácil esconde un coste.

No es el dolor lo que forma, es la analizabilidad. Mientras el defecto cabe en un perímetro que se puede abrir, leer y vincular a una decisión, enseña. Cuando aparece sobre un sistema que ha crecido, cuyas capas se han apilado, cuyas decisiones son implícitas y cuyas pruebas validan quizá una mala comprensión de la necesidad, ya no se puede referir a nada: ya no se sabe por qué todo se derrumba.

El gesto que sigue es entonces el parche. No se entiende mejor, se añade una capa más sobre una arquitectura que nunca se ha habitado.

Por qué es importante

Esto redefine lo que hay que proteger cuando se quiere que un equipo aprenda. No es la presencia de errores —los habrá—, es su tamaño y su plazo de aparición, dos magnitudes sobre las que se puede actuar mediante la división, las pruebas y la frecuencia de puesta en producción.

También explica por qué un equipo puede acumular años de incidentes sin ganar competencia: sus errores llegan siempre demasiado tarde y demasiado grandes para enseñar nada.

Matices y límites

Algunos errores tardíos forman notablemente bien, a condición de que un dispositivo los haga analizables a posteriori: un post-mortem serio, una cronología reconstruida, una traza de explotación. La analizabilidad puede, pues, restablecerse, a un coste que ya no es el del momento.

Y un bucle demasiado corto tiene su propio defecto: enseña el gesto local sin exponer nunca a los efectos de sistema, que solo aparecen a gran escala.

Preguntas abiertas

• ¿Qué plazo máximo entre una decisión técnica y su primera consecuencia observable mantiene todavía el bucle formativo?