Hay un momento antes de que el código exista en el que podría ser cualquier cosa. Ese momento es el más peligroso.

La mayoría lo trata como libertad. Yo he llegado a tratarlo como una trampa.

Cuando escribes los tests primero, no estás ralentizando. Estás tomando una decisión diferente: ¿qué significa realmente que algo esté hecho? Te obligas a describir la forma de la cosa antes de que la cosa exista. La mayoría de los ingenieros se saltan este paso. Quieren empezar a construir. Pero construir sin forma es solo movimiento. Y el movimiento no es progreso.

Los estoicos lo llamaban praemeditatio malorum — la premeditación de lo que puede salir mal. Epicteto no hablaba de pesimismo. Hablaba de claridad. Si ya has pensado en los fallos posibles, no te pillan desprevenido. Has construido tu respuesta de antemano. TDD es esa misma disciplina aplicada al código. Escribe la aserción antes que la implementación. Define el límite antes que el interior. Sabe qué puede romperse antes de decidir qué construir.

Cambia cómo piensas. Una vez escrito el test, la implementación se vuelve casi mecánica. El espacio de soluciones posibles se colapsa. Ya no estás eligiendo entre diez enfoques; estás encontrando el único que hace que la aserción pase. La ambigüedad nunca estuvo en el código. Siempre estuvo en la especificación.

Tolkien lo entendía. En el Ainulindalë, los Valar cantaron el mundo antes de que fuera creado. Primero la Música — la forma, la intención, el sonido de lo que sería. Luego Ilúvatar le dio existencia. La tragedia de Melkor no fue su poder ni su ambición; fue que improvisó sin escuchar. Añadió sus propios temas sin comprender el conjunto, y la discordancia que introdujo no pudo eliminarse. Se convirtió en parte del tejido. Todo sistema tiene su Melkor: la decisión improvisada tomada antes de que el diseño fuera claro, ahora calcificada en legado, imposible de deshacer sin romper todo lo que la rodea.

El software malo no suele escribirlo gente con poca capacidad. Lo escribe gente que empezó antes de tener la forma. Se movieron rápido, y lo que construyeron fue rápido — y ahora vive en producción y nadie lo toca porque nadie entiende del todo qué hace.

El test es la forma. La implementación es la cosa. Escribe la forma primero.

Esto no va de metodología. Va de saber lo que quieres decir antes de decirlo. Una disciplina que va mucho más allá del código.

¿Qué cambiaría en tu forma de abordar un problema si tuvieras que describir completamente cómo es el éxito antes de escribir una sola línea de implementación?