Idea principal

Escribir código costaba tiempo, y ese coste producía un efecto secundario que nadie había decidido: antes de seguir adelante, había que hablarlo a menudo, arbitrar, hacerlo revisar, entender lo que se estaba haciendo. La comprensión no la garantizaba una disciplina, la imponía el precio del gesto.

Cuando bastan unas horas donde hacían falta varios días, ese cortafuegos de hecho desaparece, y no deja nada tras de sí, porque nunca había sido instituido. Se puede entonces avanzar más rápido que la propia comprensión, sobre pantallas que responden, una base de datos que existe y una API que funciona, sin que ningún momento obligue a saber por qué las cosas están hechas así.

La disciplina que falta no es, pues, una disciplina perdida: es una disciplina que nunca tuvo que existir, y que hay que escribir por primera vez.

Por qué es importante

Esto explica por qué los equipos más experimentados también se llevan una sorpresa. No han relajado sus prácticas; han perdido un mecanismo involuntario en el que sus prácticas se apoyaban sin saberlo.

También orienta el remedio: no se trata de volver a las prácticas de antes, sino de hacer explícito —revisión obligatoria, decisión de arquitectura escrita, presupuesto de comprensión por funcionalidad— lo que la lentitud producía gratis.

Matices y límites

Ir más allá de la propia comprensión no siempre es un defecto: es exactamente lo que se busca en exploración, cuando se quiere ver a qué se parecería una solución antes de saber si vale. El peligro empieza cuando la exploración se convierte en producción sin que nadie haya registrado el paso.

Y la lentitud imponía la conversación sin garantizar nunca su calidad: muchos sistemas lentos se entendieron mal a pesar de todo.

Preguntas abiertas

• ¿Con qué señal reconoce un equipo que un prototipo exploratorio acaba de ser promovido a producción sin decisión explícita?