Por qué el software duradero está casi extinto (y nadie lo quiere admitir)

Cada vez que abres un proyecto viejo y dices "esto todavía funciona", hay un equipo entero deseando reescribirlo desde cero.

Eso es un síntoma de una enfermedad. Durante décadas, escribir software para que durara años —incluso décadas— era una virtud. Hoy, reescribir cada 2-3 años se ha vuelto norma. Y lo peor: lo celebramos como "modernización".

La industria ha normalizado lo absurdo. ¿Cuántas startups han tirado a la basura bases de código perfectamente funcionales solo porque "no escala con nuestro crecimiento actual"? ¿Cuántas empresas han gastado millones reescribiendo lo mismo, pero con un framework distinto?

El problema es sistémico. Los incentivos ya no premian mantener, premian moverse. Los CTOs quieren mostrar "arquitectura moderna" en sus slides. Los ingenieros quieren trabajar con lo último, no con código de 2017. Los VCs quieren ver entregas rápidas, no una factura de refactor de 3 años.

Y así, lo "rápido hoy" se convierte en deuda técnica heredada mañana. Excepto que mañana nadie quiere heredarlo. Todos quieren borrar y empezar de nuevo.

Hay un costo brutal en esto. Cada reescritura es un ejercicio de reinventar ruedas, introducir bugs nuevos y perder conocimiento tribal. Ese conocimiento —por qué se tomó tal decisión, qué workaround evitaba tal race condition— suele morir con el repo viejo.

El software duradero requiere humildad. Requiere decir "no necesitamos GraphQL, REST nos basta". Requiere elegir estabilidad sobre hype. Requiere valorar la previsión de quien escribió código hace 5 años para que tú no tuvieras que arreglarlo hoy.

Ironía máxima: celebramos a los proyectos open source que llevan 15-20 años funcionando (Postgres, curl, Linux) como leyendas... pero en nuestras propias empresas tratamos ese mismo enfoque como "lento" o "anticuado".

Quizá el verdadero lujo en 2026 ya no sea usar el framework más nuevo. Quizá sea tener un sistema que, tras 5 años, simplemente sigue funcionando sin necesidad de una reescritura completa.

La pregunta incómoda: ¿Estamos construyendo software para resolver problemas, o construyendo software para mantenernos ocupados?

Comparte esto si alguna vez has visto a tu equipo proponer "empecemos desde cero" ante el primer síntoma de complejidad.