Saber cuándo abandonar un barco que se hunde
El mayor enemigo de tu proyecto no es un bug. Es tu propio ego.
¿Alguna vez te has encontrado defendiendo un proyecto, una tecnología o incluso unas pocas líneas de código, no porque creyeras en su futuro, sino por todo el esfuerzo que ya habías invertido? Si la respuesta es sí, has sido víctima de la falacia del coste hundido.
En el mundo de las finanzas, un coste hundido es aquel en el que has incurrido y no puedes recuperar. Como desarrolladores, hacemos exactamente lo mismo, pero nuestra moneda es el tiempo, el esfuerzo y el ego.
💸 ¿Qué es el coste hundido en el desarrollo de software?
Es ese proyecto que lleva meses de desarrollo y que, siendo honestos, ya no responde a una necesidad real del mercado. Son esas miles de líneas de código en un sistema legacy que seguimos parcheando una y otra vez, porque reescribirlo desde cero parece un “desperdicio” de todo el trabajo anterior. Es esa funcionalidad compleja que nadie usa, pero en la que seguimos invirtiendo horas para “mejorarla” y justificar su existencia.
Estos costes —el tiempo, las líneas de código escritas, las noches sin dormir— ya no se pueden recuperar. Se han “hundido”. El problema es que permitimos que esa inversión pasada nuble nuestro juicio sobre el futuro. Nos aferramos a una mala decisión por el simple hecho de que nos costó mucho tomarla.
🧠 La trampa psicológica
Caemos en esta trampa por aversión a la pérdida. Admitir que un proyecto debe morir o que una elección tecnológica fue un error se siente como un fracaso personal. Nos decimos: “Con un poco más de esfuerzo, lo sacaremos adelante”, cuando en realidad solo estamos cavando un agujero más profundo.
💪 ¿Cómo escapar?
La próxima vez que te enfrentes a una decisión difícil sobre un proyecto estancado, no pienses en lo que ya has invertido. En su lugar, hazte esta pregunta brutalmente honesta:
“Si empezara hoy desde cero, con los recursos y el conocimiento que tengo ahora, ¿elegiría este mismo camino?”
Si la respuesta es “no”, ya sabes lo que tienes que hacer.
Ser un gran desarrollador no solo consiste en escribir código limpio y eficiente. También se trata de tener la valentía de tomar decisiones racionales, de saber cuándo pivotar y, sobre todo, de entender que matar una mala idea a tiempo no es un fracaso, sino una victoria estratégica que libera recursos para lo que de verdad importa.
Dejar ir es una de las habilidades más difíciles y valiosas que podemos aprender.