Primero que funcione, luego bien, después rápido
Creado el: 26 de septiembre de 2025
"Haz que funcione, hazlo bien, hazlo rápido." — Kent Beck
Una brújula para el desarrollo ágil
Para empezar, la máxima de Kent Beck sintetiza una secuencia de trabajo con raíces en Extreme Programming. En Extreme Programming Explained (1999), Beck prioriza que el sistema entregue valor verificable antes de pulir su diseño y, por último, optimizar su velocidad. El orden importa porque gestiona el riesgo: primero reduces la incertidumbre funcional, luego domas la complejidad, y solo entonces inviertes en rendimiento. Más que un lema, es una brújula para decidir el siguiente paso cuando todo parece urgente.
Haz que funcione: valor de lo tangible
A partir de ahí, haz que funcione exige producir una versión que resuelva el problema real, aunque sea modesta. El Manifiesto Ágil (2001) establece que el software funcionando es la medida principal del progreso; por eso, pruebas automatizadas y el ciclo rojo‑verde de TDD ayudan a confirmar que lo esencial opera. En una fintech, por ejemplo, un flujo de alta de usuarios sencillo liberado en una semana reveló requisitos regulatorios que la documentación había pasado por alto; sin ese contacto temprano con la realidad, el equipo habría pulido la solución equivocada.
Hazlo bien: diseño y legibilidad
Luego, hazlo bien invita a refactorizar para legibilidad, modularidad y simplicidad. Martin Fowler, en Refactoring (1999, 2018), muestra cómo mejorar el diseño sin cambiar el comportamiento, estabilizando el código para futuras extensiones. La Regla del Boy Scout—dejar el código un poco mejor de como lo encontraste—evita que la deuda técnica se acumule. Asimismo, prácticas como nombres claros, límites explícitos y pruebas de unidad expresivas reducen la entropía. Como advierte Beck en Extreme Programming Explained, calidad interna no es lujo: es lo que permite moverse rápido mañana sin romper hoy.
Hazlo rápido: optimización con criterio
Después, hazlo rápido trata de rendimiento percibido y eficiencia real, pero con prudencia. Donald Knuth recordó que la optimización prematura es la raíz de la mayor parte del mal (1974); por ello, se perfila antes de optimizar, y se actúa donde el tiempo se consume. Los SLO/SLI del enfoque SRE guían prioridades—Google SRE (Beyer et al., 2016) muestra cómo los objetivos de latencia y disponibilidad enfocan el esfuerzo. A veces basta con paginar, cachear o elegir estructuras de datos adecuadas; otras, hay que replantear una arquitectura. Sin medir, la velocidad es una ilusión.
Transiciones seguras entre etapas
Con este andamiaje, las transiciones entre etapas se vuelven seguras. El ciclo TDD rojo‑verde‑refactor te mueve de funciona a bien sin perder cobertura, mientras que la integración continua, los despliegues pequeños y los feature flags permiten experimentar con rendimiento sin arriesgar a los usuarios. Accelerate (Forsgren, Humble y Kim, 2018) evidencia que lotes pequeños y tiempos de ciclo cortos correlacionan con mayor calidad y menor tasa de fallos. Así, el flujo encadena aprendizaje, saneamiento y mejora, en vez de convertirlos en apuestas a gran escala.
Más allá del código: producto y equipo
En última instancia, el tríptico trasciende el código y orienta producto y organización. Haz que funcione equivale a validar el encaje problema‑solución con usuarios reales; hazlo bien se refleja en experiencia accesible, seguridad y cumplimiento; hazlo rápido significa escalar sin fricción operativa. Estudios como Accelerate (2018) desmienten la falsa dicotomía entre rapidez y calidad: las organizaciones de alto desempeño logran ambas. Esta secuencia ofrece un lenguaje común para alinear a negocio, diseño y tecnología, reduciendo discusiones abstractas a decisiones concretas y temporizadas.