Cuando decimos «Deuda Técnica» nos referimos a la analogía que utilizó Ward Cunningham para explicar a personas que no son del área de sistemas por qué se debe invertir en realizar análisis y refactorización de código.
Según Martin Fowler, en su libro Refactoring: Improving the Design of Existing Code «la refactorización es el proceso por el cual se realizan cambios en el código de un sistema en una manera que no altera su funcionamiento externo pero sí mejora su estructura interna».
En el desarrollo de todo sistema de información los recursos son finitos y por eso los sistemas tienden a tener cierto nivel de polución en el código, es decir, cierta deficiencia en la calidad interna que, a mediano y largo plazo, complica cada vez más la implementación de nuevas funcionalidades.
¿Y por qué ocurre esta falta de calidad en el código? por causas que son comunes a la organización de todo proyecto de Software: Deadlines irreales, cambios solicitados a último momento, deficiencia en el análisis inicial de los requerimientos, presupuesto muy acotado, estimaciones demasiado erradas.
Ward Cunningham utiliza la analogía de la «deuda» porque, al implementar nuevas funcionalidades en el sistema, se termina gastando más recursos de los que se gastarían si esta deuda no existiera. Estos recursos extra que se pagan, principalmente en forma de tiempo y por consecuencia en dinero, es el interés de la «deuda».
Hasta cierto punto, mientras el interés a pagar sea pequeño, es posible mantener esta deuda a raya. El problema real ocurre cuando el interés eleva demasiado el «costo total» de las nuevas funcionalidades a implementar. Va a llegar un punto donde se deberá analizar si no conviene dedicar recursos a pagar primero el interés de la deuda, es decir, refactorizar o mejorar el código ya existente, y luego continuar con desarrollos o modificaciones nuevas.
En este artículo, súper interesante por cierto, Martin Fowler justifica que la mejor forma de lidiar con la «deuda» técnica es hacerlo progresivamente. Se pueden distinguir dos tipos de áreas con «polución» o «deuda». Las áreas de alta actividad y las áreas de baja actividad.
Las áreas de alta actividad son aquellas en las que se realizan modificaciones muy regularmente. Estas admiten poca tolerancia de «deuda» técnica. En estas áreas es donde puede ser conveniente solucionar, refactorizar, o mejorar paulatinamente el código. Esto nos ahorrará mucho tiempo en todas las implementaciones.
Por el contrario, en las áreas de baja actividad aunque tengan también una «deuda», ésta se pagará en el momento en que se deba trabajar en dicha área y no será tan regularmente como en las de alta actividad, por tal motivo, pueden tener menos prioridad a la hora de refactorizarlas.
Diga lo que diga cualquier persona la «deuda técnica» existe y siempre va a existir en todo sistema de información, especialmente en aquellos sistema de gran envergadura. Lo que se debe intentar es reducirla al máximo y encontrar la mejor manera de gestionarla. Es importante para cualquier líder de equipo de desarrollo de proyectos tener en cuenta estos conceptos en el día a día.
Photo by Skitterphoto from Pexels
