Construir bien no es más lento que construir rápido

Hay una falsa dicotomía que persiste en el desarrollo de software: puedes construir rápido o puedes construir bien, pero no los dos a la vez.

No es así. La mayoría de las veces, construir mal es más lento.

Lo que confundimos con rapidez es frecuentemente aplazamiento. Saltarte los tests, hardcodear un valor, copiar código sin entenderlo: todo esto da velocidad en el momento y la quita multiplicada más adelante. La deuda técnica no es metáfora; es literal. Tiene intereses.

Lo que realmente acelera el desarrollo es claridad: saber exactamente qué estás construyendo antes de empezar a construirlo. Un sistema bien diseñado es más fácil de cambiar. Un test bien escrito te da confianza para moverlo. Una API clara reduce la superficie de errores.

Cuando empiezo un proyecto, me tomo el tiempo que haría falta para diseñar la estructura correctamente. Invariablemente, ese tiempo me lo devuelve con intereses a las dos semanas, cuando necesito añadir algo que no habría cabido en la primera versión.

No siempre consigo construir todo bien. Pero reconocer cuándo estoy eligiendo rapidez sobre calidad —en lugar de hacerlo sin darme cuenta— ya es la mitad del problema resuelto.