Tener en cuenta este concepto tan simple puede suponer una diferencia enorme entre un proyecto rentable o un agujero negro de dinero.
La deuda técnica.
En el mundo del desarrollo de software se usa mucho un término:
El significado habitual es la consecuencia negativa en el futuro que puede suponer hacer algo mal ahora.
Es decir, hacer algo que ahora funciona, pero que puede complicar las cosas en el futuro.
Porque en programación, las aplicaciones suelen crecer, mejorarse y actualizarse durante mucho tiempo.
Y no pensar a largo plazo es peligroso.
Un código que hoy funciona perfectamente, dentro de unos años puede necesitar una modificación.
Si está bien planteado, estructurado, documentado, puede ser tan fácil como añadir unas pocas líneas de código.
Pero si solo se ha pensado en que funcione hoy, cada modificación necesitará un montón de código.
Lo que en programación de llama código espagueti.
Y eso, algún día puede salir muy caro.
Porque se pueden tocar elementos comunes a varias funcionalidades, provocando que empiecen a fallar cosas que aparentemente no tienen nada que ver.
Y como los síntomas no parecen tener relación, el diagnóstico se complica infinitamente.
Seguro que conoces más de un caso de deuda técnica.
Hay casos muy evidentes, de esos que dices “a quién se le ocurrió está mierda, y quién la autorizó?”.
Pero lo preocupante no es eso.
Porque los casos “de juzgado de guardia” se ven claros.
Quizás son complicados y caros de resolver, pero al menos es fácil entender lo que está mal.
Lo preocupante es otra cosa.
La deuda técnica de efecto compuesto.
Sistemas y mejoras que resuelven un problema hoy.
Que realmente han supuesto un paso adelante.
Una evolución.
Pero a la hora de dar otro paso más avanzado, el sistema no es adaptable.
Hay que deshacer la mejora anterior, replantear y buscar alternativas definitivas.
Y a veces eso no es posible.
Por muchas razones.
Por ejemplo, reconocer que la solución no era la ideal.
Parece una tontería, porque debería valorarse más la voluntad de mejorar, aunque el resultado no siempre sea el esperado.
Pero sucede.
Sobre todo dependiendo del tipo de jefes que tengan.
Otra causa para no querer volver atrás es que quizás cuando se aplicó la primera mejora el contexto era distinto.
Quizás la empresa ha crecido, todo se ha vuelto más complejo, hay más carga de trabajo, y las modificaciones suponen problemas más caros y difíciles de coordinar.
Por eso es doblemente importante hacerlo bien a la primera.
Mejorar algo hoy está bien.
Pero si se hace pensando en evitar la deuda técnica, mucho mejor.
Quizás la solución aplicada sea más cara ahora.
Pero hará que las siguientes serán más baratas.
Y cada una te hará el trabajo más sencillo y seguro.
Por eso es tan importante pensarlo dos veces.
Tienes algún ejemplo en mente?
Cuéntamelo en los comentarios, aquí debajo.
Deja una respuesta