¿Qué es la deuda tecnológica?
¿Os habéis encontrado alguna vez con código mal escrito que es difícil de mantener y más difícil de reutilizar? Apuesto a que sí.
Ese código muchas veces no es chapucero porque el programador no sepa hacerlo mejor, sino porque se ha hecho con prisas y sin preocuparse en que ese código pueda extenderse con facilidad en el futuro. Se ahorra tiempo, por ejemplo, en técnicas como los test unitarios que mejoran considerablemente la calidad del código.
Cuando uno se ve forzado a trabajar con una base de código muy mal escrita, los proyectos acaban tardando mucho más de lo necesario. Lo que podíamos haber hecho en dos días acaba tardando diez. O cuarenta. Todo es mucho más complicado porque tenemos que enfrentarnos a las problemas que nos presenta el código legado.
Para explicar las consecuencias del código hecho con prisas Ward Cunningham acuñó el término deuda tecnológica. Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.
A veces la deuda tecnológica tiene sentido. Puede que tengamos que terminar un producto antes que un competidor, o puede que si no terminamos pronto perdamos una gran oportunidad de negocio. En ese caso, la deuda tecnológica tiene el mismo sentido que la deuda financiera: incurrimos en algo de deuda para obtener unos beneficios tan grandes que compensan de sobra el pago de los intereses.
Sin embargo, la deuda tecnológica, como la financiera, también tiene un aspecto muy peligroso: recurrir a la deuda es una manera muy sencilla de tapar los problemas que tiene nuestro negocio. Entra dinero y crea la ilusión de que el negocio sigue funcionando, aunque en realidad sólo hemos aplazado los problemas al tiempo que los empeoramos.
Con la deuda tecnológica pasa lo mismo. Hacer constantemente chapuzas puede dar la sensación de que los proyectos avanzan. Sin embargo, al poco tiempo acabamos con una maraña de código inmantenible; lo que debería ser muy sencillo se convierte en complicado y los desarrollos avanzan cada vez más despacio.
Es porque todo nuestro esfuerzo se invierte en pagar los intereses de la deuda tecnológica.
Totalmente de acuerdo. Muchos programadores no piensan en el largo plazo, en la mantenibilidad, en comentar el código (aunque parezcan obviedades en ese momento), en aplicar patrones, etc…
La rapidez con la que a veces nos ‘obligan’ a entregar desarrollos nos puede hacer dejar de lado todas las buenas prácticas y en este caso debe ser todo lo contrario. Suscribo totalmente la filosofía Debian: el desarrollo está listo cuando esté testeado y completado. Al diablo con los milestones !!.
Creo que el problema no es de los programadores, sino de los responsables de proyecto, que marcan los plazos.
El problema es de ambos. Primero de los responsables de proyecto que se piensan que el desarrollo de software se puede equiparar a una cadena de montaje. Y los segundos responsables somos nosotros que muchas veces permitimos subir algo a producción cuando realmente no está listo por ‘necesidades de negocio’.
Opino que desarrollar software es totalmente incompatible con la tradicional planificación de plazos al cual están acostumbrados tantos y tantos gestores. Si no les gusta cómo funciona la metodología de desarrollo, que se vayan a gestionar fábricas de piezas de plástico.