Piano piano si va lontano

Hay un proverbio italiano que dice “piano piano si va lontano” y que se traduce a algo como “despacio se llega lejos”. La escuché hace años, cuando empezaba a aprender italiano, y desde entonces se me ha quedado grabada.

En un mundo donde todo lo queremos rápido, esta frase suena contradictoria. Y en el desarrollo de software, más todavía.

#.La falacia de “ir rápido”

En mis primeros años desarrollando software, varias personas me recomendaron leer algunos libros que fueron marcando mi carrera: Clean Code, The Clean Coder, Hackers and Painters, Working Effectively with Legacy Code, entre otros. Cada uno llegó en momentos distintos y con cada lectura aparecían nuevas ideas, preguntas y formas distintas de observar el software que construimos.

Hay una idea que se repite en casi todos estos libros: la velocidad real no viene de ir rápido, sino de ir bien.

En algún momento de nuestra carrera, todos hemos escuchado (o dicho) algo así como “necesitamos entregar rápido” o “hay que moverse más rápido”. Y sí, la velocidad importa. Pero la pregunta que muchas veces no nos hacemos es: ¿rápido hacia dónde?

Ir rápido sin dirección, sin estructura, sin las bases adecuadas, no es velocidad: es desorden con prisa.

#.“Legacy code is simply code without tests”

Hace poco volví a recordar Working Effectively with Legacy Code de Michael Feathers. En el prefacio me encontré con esta definición clara y dura sobre los sistemas legacy:

“Legacy code is simply code without tests.”

Más allá de si la comparto del todo (no la comparto), lo interesante es lo que implica: los tests nos permiten cambiar el sistema con mayor confianza. Nos permiten mitigar lo que Feathers llama el “edit and pray” ^fn-1, que es básicamente hacer cambios y rezar para que nada se rompa.

Esto no es un concepto nuevo. Kent Beck, creador de Extreme Programming y pionero del Test-Driven Development, popularizó una máxima que heredó de su padre y que resume muy bien la idea: “Make it run, make it right, make it fast” ^fn-2. Primero que funcione, luego que esté bien hecho, y después (si es necesario) que sea rápido. El orden importa.

Cuando invertimos el orden, cuando priorizamos la velocidad de entrega sobre la calidad de lo que entregamos, terminamos con sistemas frágiles que ralentizan todo a largo plazo. Ward Cunningham acuñó el término “Technical Debt” (deuda técnica) precisamente para describir este fenómeno: los atajos que tomamos hoy se convierten en el lastre que cargamos mañana ^fn-3.

#.La evidencia: calidad y velocidad no son opuestos

Hay una creencia bastante extendida de que hacer las cosas “bien” toma más tiempo y que la calidad compite con la velocidad. La evidencia dice lo contrario.

En Accelerate: The Science of Lean Software and DevOps ^fn-4, Nicole Forsgren, Jez Humble y Gene Kim presentan años de investigación (respaldada por datos de miles de equipos) que demuestran que los equipos de alto rendimiento entregan más rápido Y con mayor calidad. No es una cosa o la otra: es las dos. Estos equipos despliegan código con mayor frecuencia, con menos fallos y se recuperan más rápido cuando algo sale mal.

¿Cómo lo logran? Con prácticas como integración continua, entrega continua, automatización de pruebas, y sobre todo: con una cultura que prioriza la calidad como parte del proceso, no como algo que se revisa al final.

Martin Fowler lo ilustra muy bien con lo que llama la Design Stamina Hypothesis ^fn-5: al inicio de un proyecto, ignorar el buen diseño puede parecer más rápido. Pero pasado un punto (que llega más temprano de lo que creemos), el buen diseño es lo que permite seguir avanzando a buen ritmo. Sin él, cada cambio es más costoso, más riesgoso y más lento.

#.Lean lo sabía desde antes

Mucho antes de que habláramos de Agile o DevOps, el sistema de producción de Toyota ya había resuelto esta tensión entre velocidad y calidad.

Uno de los principios fundamentales de Lean es Jidoka ^fn-6, que se traduce como “automatización con un toque humano”. En la práctica, significa que cualquier persona en la línea de producción puede detener todo el proceso si detecta un defecto. Parar para arreglar. Suena lento, ¿verdad? Sin embargo, es exactamente lo que permite que el sistema sea rápido a largo plazo, porque los defectos no se acumulan.

Mary y Tom Poppendieck trasladaron estos principios al software en Lean Software Development ^fn-7 y uno de sus principios más importantes es “Build Integrity In”: construir con integridad y calidad desde el inicio, no inspeccionar al final. Si tenemos que “verificar” la calidad después, ya llegamos tarde.

Es la misma idea que W. Edwards Deming, el padre de la gestión de calidad moderna, predicó durante décadas: “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place” ^fn-8. La calidad no se inspecciona, se construye.

#.Velocidad no es prisa

Quiero ser claro en algo, porque sé que todo lo anterior puede leerse como un argumento en contra de la velocidad. No lo es.

La velocidad importa. Pero hay una diferencia enorme entre velocidad y prisa, y confundirlas es uno de los errores más costosos que he visto en equipos de software. La prisa es entregar rápido sin importar lo que viene después. La velocidad —la velocidad que realmente sirve— es la que viene de eliminar waste, de quitar todo lo que no aporta valor y no sirve al sistema. El primer principio de Lean Software Development de los Poppendieck es precisamente ese: “Eliminate Waste” ^fn-7. No “ir más rápido” ni “presionar más al equipo”: eliminar lo que estorba. Hay una diferencia fundamental ahí.

El problema es que cuando estamos bajo presión, es fácil confundir las dos cosas. Empezamos a ver los tests como waste. Las revisiones de código como waste. La documentación, las pausas, el tiempo para pensar: todo parece waste cuando el reloj aprieta. Pero esas cosas no son waste: son exactamente lo que sostiene el ritmo. Quitarlas es como quitarle el aceite al motor para que vaya más rápido. Funciona por un rato y luego todo se detiene.

El octavo principio del Manifiesto Ágil lo dice de forma que me parece difícil de mejorar: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” ^fn-9 Un ritmo constante, indefinidamente. Eso es lo opuesto a la prisa. Y en mi experiencia, un equipo que mantiene ese sustainable pace durante seis meses supera sistemáticamente a uno que aceleró a fondo los primeros dos y luego se tropezó con su propia deuda acumulada.

#.Y entonces llega la IA

Todo esto —la velocidad que elimina waste y el ritmo que se sostiene— cobra nueva urgencia en un momento donde las herramientas de IA nos permiten generar código cada vez más rápido.

Si antes el reto era escribir código rápido, ese problema ya casi no existe. La IA puede generar cientos de líneas en segundos. Pero generar código no es lo mismo que construir software. El código generado necesita ser entendido, mantenido, probado y evolucionado. Si no tenemos las estructuras, las prácticas y la disciplina para sostener lo que generamos, la velocidad de generación se convierte en velocidad de acumulación de deuda.

No se trata de ser reacios al cambio, todo lo contrario. Se trata de crear las condiciones para abrazarlo y que el cambio sea seguro, entendible y sostenible. Una buena suite de pruebas, una arquitectura clara, un proceso de revisión de código, convenciones compartidas: estas no son cosas que te hacen “más lento”. Son las cosas que te permiten seguir siendo rápido cuando el sistema crece, cuando el equipo cambia, cuando los requisitos cambian.

El noveno principio del Manifiesto Ágil lo dice textualmente: “Continuous attention to technical excellence and good design enhances agility” ^fn-9. La excelencia técnica no es un lujo ni una fase posterior: es lo que hace posible la agilidad.

#.Lo que realmente acelera

Después de varios años trabajando con equipos de distintos tamaños y en distintos contextos, he llegado a una conclusión simple: lo que realmente acelera a un equipo no es la presión por entregar rápido, sino la confianza de que lo que entregan funciona y se puede cambiar sin miedo.

Un equipo que tiene buenas pruebas automatizadas puede refactorizar sin miedo. Un equipo con una arquitectura clara puede agregar funcionalidades sin romper lo existente. Un equipo con convenciones compartidas puede incorporar nuevos miembros sin que todo se detenga.

Esa seguridad es precisamente lo que permite que los equipos mantengan (o incluso aumenten) su ritmo de desarrollo. No es ir lento: es ir con paso firme.

Fred Brooks, en su ensayo “No Silver Bullet” (1986), ya nos advertía que no hay balas de plata en la ingeniería de software ^fn-10. No las hay. Ni la IA, ni un framework nuevo, ni una metodología mágica van a resolver la complejidad inherente de construir software. Lo que sí ayuda es la disciplina, las buenas prácticas y el compromiso con la calidad.

#.Piano piano

Piano piano si va lontano. Despacio se llega lejos.

No es una invitación a ser lentos. Es un recordatorio de que la velocidad sostenible requiere bases sólidas. Que los atajos de hoy son los problemas de mañana. Que invertir en calidad, en estructura, en buenas prácticas no es perder tiempo: es ganarlo.

Y si al final del día, después de poner las bases correctas, quieres usar la IA para ir más rápido: adelante. Pero asegúrate de que esas bases existan primero.

Porque ir rápido es fácil. Llegar lejos es lo difícil.