Criterio técnico vs. velocidad de entrega: cuándo elegir cada uno

Hay una falsa dicotomía que circula en los equipos: o entregas rápido, o entregas con criterio. Como si fueran mutuamente excluyentes. No lo son. Pero tampoco son lo mismo, y confundirlas tiene un coste real.

La trampa de la falsa elección

Cuando un product manager pregunta “¿se puede tener para el viernes?”, hay tres respuestas honestas:

1. Sí, y aguantará seis meses.
2. Sí, pero solo aguantará seis días sin tocarlo.
3. No, salvo que tengamos el lunes para diseñarlo.

El error frecuente es responder “sí” sin marcar la diferencia entre la opción 1 y la opción 2. Y un mes después, cuando hay que añadir una pequeña funcionalidad encima, descubrimos que la “deuda técnica” no era deuda: era un préstamo a interés compuesto.

Cuándo prima la velocidad

Hay decisiones donde la velocidad es legítima, e incluso correcta:

• Validar una hipótesis de producto. Si no sabes si los usuarios van a usar la feature, no tiene sentido diseñar la arquitectura definitiva. Lo barato y rápido gana.
• Bloqueo crítico. El sitio está caído. La pasarela de pago no funciona. No es momento de refactor; es momento de hotfix.
• Plazos externos no negociables. Una campaña con fecha de lanzamiento, un cliente con presentación al inversor, un cierre fiscal. La realidad manda.
• Código desechable. Una landing para un evento de fin de semana. Un script de migración que se ejecuta una vez. La elegancia es un lujo que aquí no rinde.

En estos casos, escribir “el código perfecto” es ego, no oficio.

Cuándo prima el criterio

El criterio gana en el lado contrario:

• Decisiones de arquitectura. La estructura de la base de datos, los contratos de las APIs públicas, los límites entre módulos. Aquí cada atajo se paga durante años.
• Código que va a ser leído cien veces. Si un módulo lo van a tocar cinco devs en los próximos dos años, la claridad rinde mucho más que la velocidad de escribirlo.
• Seguridad y datos sensibles. Aquí no hay “lo mejoramos después”. El después llega cuando un atacante encuentra el agujero o cuando legal te llama por una fuga.
• Onboarding del próximo developer. El código se escribe una vez y se lee cien. Si necesitas explicarlo cada vez que entra alguien nuevo, ya estás pagando intereses.

La pregunta no es “¿prima velocidad o criterio?”. Es “¿cuántas veces vamos a tener que tocar este código en los próximos dos años?”. Si la respuesta es muchas, el criterio gana incluso aunque el plazo apriete.

El test del lunes por la mañana

Una heurística práctica que uso con clientes:

Imagina que es lunes por la mañana, otro developer (no tú) abre este archivo por primera vez. ¿Cuánto tarda en entender qué hace y cómo cambiarlo?

Si la respuesta es “diez minutos”, el código es bueno. Si la respuesta es “una mañana entera leyendo y rezando”, el código es deuda disfrazada de feature.

Este test ignora deliberadamente “lo entiende fácil porque es brillante el autor”. El código no se mide por la inteligencia que necesitó para escribirse, sino por la que necesita para leerse. Donald Knuth lo dijo mejor: “Programs must be written for people to read, and only incidentally for machines to execute.”

El falso ahorro del “lo limpiamos después”

Hay una frase que oigo en muchos sprints: “hagamos la versión rápida y luego refactorizamos”.

En cuatro años de producción, he visto ese “luego” cumplirse exactamente cero veces. No porque la gente sea mentirosa, sino porque el momento en el que se podía refactorizar nunca llega: siempre hay una nueva feature urgente, un nuevo bug crítico, un nuevo plazo apretado. Y la deuda crece.

La regla que yo aplico: si el código va a vivir más de un mes en producción, lo refactorizas antes de mergear, no después. Aunque parezca que tarda más, te ahorra reescribirlo cuando ya tenga tres dependencias encima.

Cómo se ve el criterio en mi trabajo

Cuando entro a un proyecto, hago tres preguntas antes de tocar nada:

1. ¿Cuánto tiempo va a vivir esto? Una landing para un evento puntual no merece la arquitectura de una plataforma SaaS.
2. ¿Quién lo va a mantener? Si nadie del equipo del cliente va a poder tocarlo, entonces lo dejo lo más simple posible aunque el resultado sea menos elegante.
3. ¿Qué falla si esto se rompe a las 3 de la mañana? Si la respuesta es “nada importante”, puedo permitirme experimentar. Si la respuesta es “el negocio se para”, el criterio gana sí o sí.

La diferencia entre prisa y velocidad

Hay una distinción que aprendí escribiendo filosofía y que aplico todos los días al código: prisa no es lo mismo que velocidad.

La velocidad es entregar lo que toca en el tiempo que toca, sin desperdiciar pasos. La prisa es saltarse pasos para llegar antes y descubrir luego que has llegado al sitio equivocado.

Un equipo veloz entrega rápido sin generar deuda. Un equipo apresurado entrega rápido y la deuda la paga el siguiente trimestre.

Conclusión

No hay una respuesta universal. Pero hay un test universal: el día que entregas, pregúntate honestamente cuánto va a costar el próximo cambio. Si la respuesta es “lo mismo o menos”, has elegido bien. Si la respuesta es “más, porque ya estoy montando andamios para sostener esto”, entonces no entregaste rápido: entregaste prisa.

El criterio técnico no es lo contrario a entregar rápido. Es la única forma de entregar rápido dos veces seguidas.