Por qué el buen software necesita tiempo y no se apura

Flask tardó ocho años en llegar a la versión 1.0. SQLite lleva en desarrollo activo desde el año 2000 y sigue recibiendo mejoras importantes. El kernel de Linux tiene más de tres décadas y, con los años, se diría que está mejor que nunca. Mientras tanto, se espera que una startup financiada por VC muestre tracción en 18 meses o explique por qué no.

Existe una desconexión creciente entre cuánto tiempo lleva construir buen software de verdad y cuánto esperamos que tarde. La presión por lanzar rápido no está mal en sí misma, pero crea una cultura en la que la paciencia se ve como falta de ambición, y en la que los proyectos que perduran se tachan de «lentos» durante los años en que, en silencio, están haciendo las cosas bien.

El mito del éxito de la noche a la mañana

Casi todos los «éxitos de la noche a la mañana» en software tienen una larga historia detrás. React se usó internamente en Facebook durante más de un año antes de ser open source. Rust estuvo siete años en desarrollo antes de llegar a la 1.0. PostgreSQL empezó como un proyecto de investigación en 1986 y no se convirtió en la base de datos de referencia en producción hasta la década de 2010: casi 30 años de mejora constante y discreta.

Lo que parece una aparición repentina suele ser el resultado de mejoras acumuladas que cruzan un umbral de visibilidad. El software llevaba todo ese tiempo mejorando. Lo que pasaba es que nadie prestaba atención hasta que se volvió lo bastante bueno como para ser innegable.

Armin Ronacher, el creador de Flask, escribió sobre esto directamente. Flask nació como una broma del 1 de abril en 2010. Se convirtió en un proyecto serio casi por accidente. Años de trabajo incremental —corregir casos límite, mejorar la documentación, repensar las APIs— lo convirtieron en uno de los frameworks web de Python más populares. Ninguno de esos años se desperdició. Cada uno fortaleció la base.

Por qué el software tiene un componente de tiempo irreductible

Hay problemas que no se resuelven más rápido por añadir más personas o trabajar más horas. Fred Brooks lo identificó en 1975 con The Mythical Man-Month, y la idea central sigue vigente: ciertos aspectos del desarrollo de software son secuenciales, no paralelizables.

• Entender el dominio del problema. No puedes comprender por completo un espacio de problema hasta que has vivido en él durante un tiempo. La primera versión de cualquier software codifica tus suposiciones iniciales. La segunda codifica lo que aprendiste con la primera. La comprensión real requiere iteraciones, y las iteraciones requieren tiempo.
• Diseño y estabilidad de la API. Las buenas APIs surgen del uso. No puedes diseñar una API perfecta en el vacío: necesitas usuarios reales que den con casos límite reales. Las librerías que se apresuran a llegar a la 1.0 suelen lamentar sus decisiones de diseño iniciales durante años.
• Casos límite y endurecimiento. El primer 80% de una funcionalidad lleva el 20% del tiempo. Los casos límite restantes, el manejo de errores y las peculiaridades de cada plataforma se llevan el otro 80%. Esta proporción no es pereza: es la naturaleza fundamental de hacer el software fiable.
• Comunidad y ecosistema. Una herramienta no es realmente útil hasta que tiene documentación, tutoriales, plugins y una comunidad que responde preguntas. Este ecosistema no se puede fabricar; crece orgánicamente con el tiempo.

El daño de la urgencia artificial

«Muévete rápido y rompe cosas» era un lema razonable para una red social que buscaba encajar en el mercado. Es una pésima filosofía para infraestructura, herramientas de desarrollo, bases de datos o cualquier cosa de la que dependan los sistemas de otras personas. Cuando apuras el software fundacional, las roturas se acumulan.

He visto implosionar varios proyectos open source prometedores por intentar crecer más rápido de lo que sus cimientos podían soportar. El patrón es predecible: un proyecto se vuelve popular, los mantenedores sienten presión para lanzar funcionalidades rápido, la calidad cae, los colaboradores se queman y los usuarios se pasan a algo más estable. La ironía es que frenar les habría llevado más lejos.

Los proyectos que perduran no son los que más rápido se lanzaron. Son los que tomaron buenas decisiones a tiempo, para no tener que reescribirlo todo más adelante.

La deuda técnica no es solo código desordenado. Son decisiones tomadas bajo presión de tiempo que limitan posibilidades futuras. Cada atajo para lanzar más rápido es un impuesto sobre cada cambio posterior. Algunos atajos merecen la pena, pero conviene tomarlos de forma deliberada, no porque alguien haya decidido arbitrariamente que la fecha límite es el próximo martes.

Cómo se ve la paciencia en la práctica

La paciencia en el desarrollo de software no significa avanzar lento por avanzar lento. Significa ser deliberado sobre lo que construyes y honesto sobre cuánto tardan las cosas. Estos son algunos patrones que he visto funcionar bien:

• Publica pronto, pero compromete despacio. Lanza tu software a los usuarios cuanto antes para recibir feedback, pero sé muy conservador con lo que prometes como API estable. Usa el versionado 0.x con generosidad. Deja claro que las cosas podrían cambiar.
• Di que no a funcionalidades. Cada funcionalidad que añades es una que mantienes para siempre. Los mejores proyectos tienen opiniones claras sobre su alcance. SQLite enumera explícitamente las cosas que nunca hará, y esa disciplina es la razón por la que es la base de datos más desplegada del mundo.
• Invierte en lo fundamental. Documentación, pruebas, mensajes de error, rendimiento: no son glamurosos, pero se acumulan. Un proyecto bien documentado y con una buena suite de pruebas puede avanzar más rápido en el año tres que uno mal documentado en el año uno.
• Protege la energía de los mantenedores. El agotamiento es el principal enemigo de los proyectos open source. Un ritmo sostenible importa más que la velocidad en sprints. Un mantenedor que dedica 20 horas concentradas a la semana durante cinco años entrega más que otro que trabaja 80 horas semanales durante seis meses y luego desaparece.

La trampa de velocidad de las startups

Las startups enfrentan una tensión legítima: necesitan moverse rápido para sobrevivir, pero hacerlo demasiado rápido crea sistemas frágiles que se convierten en un pasivo al escalar. Las empresas que lo gestionan bien suelen distinguir entre dos tipos de velocidad.

Velocidad de iteración: qué tan rápido puedes probar ideas, obtener feedback de usuarios y cambiar de rumbo. Esta debe maximizarse. Ciclos cortos, prototipado rápido, disposición a tirar cosas a la basura.

Velocidad de compromiso: qué tan rápido fijas decisiones de arquitectura, APIs públicas y modelos de datos. Esta debe minimizarse. Mantén las cosas reversibles el mayor tiempo posible. Cuanto más puedas aplazar las decisiones irreversibles, más información tendrás cuando por fin las tomes.

El error más común en las startups es confundir ambas. Se comprometen con arquitecturas tan rápido como iteran en funcionalidades y luego pasan los dos años siguientes pagando el impuesto de las decisiones prematuras.

Lo que aprendemos de los proyectos que perduraron

Los proyectos de software de los que más dependemos comparten un rasgo: en algún momento se consideraron «lentos». PostgreSQL era la opción aburrida mientras MySQL era la rápida y despreocupada. Python era «demasiado lento» mientras Perl era la elección pragmática. Git tardó años en ser utilizable por personas normales.

Lo que estos proyectos tuvieron fue tiempo: tiempo para equivocarse, aprender de los errores y construir algo sólido. No intentaron ser todo para todos en el primer año. Intentaron ser excelentes en su propósito principal, y estuvieron dispuestos a dejar que esa excelencia tardara lo que necesitara.

La próxima vez que te frustre que un proyecto «tarde demasiado», piensa que las cosas en las que más confías —tu sistema operativo, tu base de datos, tu runtime de lenguaje, tu control de versiones— tardaron más de lo que nadie esperaba. Y precisamente por eso funcionan.

Algunas cosas simplemente requieren tiempo. La mejor respuesta no es luchar contra esa realidad, sino construir sistemas, equipos y expectativas que la tengan en cuenta.