Deuda técnica: las posibles co­n­se­cue­n­cias de ahorrar en el de­sa­rro­llo de software

Cuando un equipo de de­sa­rro­llo actúa de manera aho­rra­ti­va o con prisas en el de­sa­rro­llo de software o en la pla­ni­fi­ca­ción de las in­frae­s­tru­c­tu­ras in­fo­r­má­ti­cas, este ahorro se acaba pagando en forma de deuda técnica. La deuda técnica denomina las co­n­se­cue­n­cias derivadas de las ne­gli­ge­n­cias, errores o de­fi­cie­n­cias de­li­be­ra­das o in­vo­lu­n­ta­rias en relación con el código. Las co­rre­c­cio­nes y medidas de ma­n­te­ni­mie­n­to po­s­te­rio­res frenan la pro­du­c­ti­vi­dad y generan elevados costes adi­cio­na­les. ¿Qué hay que tener en cuenta para evitar la deuda técnica en el de­sa­rro­llo de software?

En 1992, Ward Cu­n­ni­n­gham, pro­gra­ma­dor y coautor del Ma­ni­fie­s­to por el de­sa­rro­llo ágil de software, introdujo la metáfora de la deuda técnica. Con este concepto, Cu­n­ni­n­gham quería ilustrar la im­po­r­ta­n­cia que la re­fa­c­to­ri­za­ción es decir, la co­rre­c­ción regular del código, tiene para el software. Solo de esta forma es posible evitar que un software genere siempre mas deuda por las cre­cie­n­tes de­fi­cie­n­cias ope­ra­ti­vas y es­tru­c­tu­ra­les.

El término deuda también implica intereses, puesto que la deuda técnica es relevante para las empresas co­n­tra­ta­n­tes sobre todo desde el punto de vista fi­na­n­cie­ro. La deuda técnica no solo implica más esfuerzo y una menor pro­du­c­ti­vi­dad debido a las medidas de ma­n­te­ni­mie­n­to po­s­te­rio­res, sino también más costes. Cuanto más descuida la dirección de un equipo el ma­n­te­ni­mie­n­to de una in­frae­s­tru­c­tu­ra o apli­ca­ción in­fo­r­má­ti­ca de­fe­c­tuo­sa, más intereses genera la deuda y más caras resultan las co­rre­c­cio­nes del código.

Según Ward Cu­n­ni­n­gham, la deuda técnica se origina debido a de­fi­cie­n­cias en el código que, por falta de tiempo o pre­su­pue­s­to, obligan a adoptar una solución más rápida del problema, aunque de­fi­cie­n­te. Un código escrito de manera minuciosa y exhau­s­ti­va es laborioso y requiere mucho tiempo. Por este motivo, a veces los de­sa­rro­lla­do­res optan por un código sucio con el objetivo de ahorrar así tiempo y esfuerzo. Pero este ahorro se paga con deuda.

Para Cu­n­ni­n­gham, este aspecto económico de la pro­gra­ma­ción no es algo inusual o an­ti­na­tu­ral. En caso de que la deuda técnica no se compense mediante re­fa­c­to­ri­za­ción ni el código se optimice con re­gu­la­ri­dad, el de­sa­rro­llo acabará por in­te­rru­m­pi­r­se o detenerse debido a los intereses me­ta­fó­ri­cos.

Martin Fowler, autor de Re­fa­c­to­ri­ng: Improving the Design of Existing Code, concretó la metáfora de Cu­n­ni­n­gham y su­b­di­vi­dió la deuda técnica en cuatro tipos, que re­pre­se­n­tó en el cuadrante de la deuda técnica:

Según Cu­n­ni­n­gham y Fowler, la deuda técnica se puede generar tanto de manera de­li­be­ra­da como in­vo­lu­n­ta­ria. Puesto que la te­c­no­lo­gía y la pro­gra­ma­ción incluyen re­vi­sio­nes y mejoras continuas, es prá­c­ti­ca­me­n­te imposible evitar la hediondez del código y la erosión del código. El software también envejece y, a falta de ac­tua­li­za­cio­nes y re­fa­c­to­ri­za­ción, también genera deudas. En la mayoría de los casos, sin embargo, la deuda técnica se debe a de­ci­sio­nes eco­nó­mi­cas o fallos de pro­gra­ma­ción de­li­be­ra­dos o in­vo­lu­n­ta­rios.

Aunque ge­ne­ra­l­me­n­te la deuda técnica siempre tiene los mismos efectos sobre el de­sa­rro­llo de software, las causas pueden ser muy variadas. Aquí se las pre­se­n­ta­mos:

• Falta de gestión de calidad: los proyectos se de­sa­rro­llan sin me­ca­ni­s­mos de prueba, medición y control de calidad y generan deuda de manera continua.
   
• Presión económica: debido a las exi­ge­n­cias del cliente o a la presión de la co­m­pe­te­n­cia, se da prioridad a factores eco­nó­mi­cos y a un de­sa­rro­llo rápido en de­tri­me­n­to de la limpieza del código.
   
• Falta de cua­li­fi­ca­ción: los co­no­ci­mie­n­tos técnicos del equipo de de­sa­rro­llo no se co­rre­s­po­n­den con las exi­ge­n­cias de un código limpio y elegante. La co­n­se­cue­n­cia es una hediondez de código o un código espagueti.
   
• Do­cu­me­n­ta­ción/co­mu­ni­ca­ción in­su­fi­cie­n­tes: el proceso de de­sa­rro­llo tra­n­s­cu­rre sin do­cu­me­n­tar las am­plia­cio­nes y mo­di­fi­ca­cio­nes del código en paralelo. Además, las mo­di­fi­ca­cio­nes del código no se registran ni comunican a los pro­gra­ma­do­res po­s­te­rio­res. Las po­si­bi­li­da­des para la re­fa­c­to­ri­za­ción son limitadas o in­e­xi­s­te­n­tes.
   
• Re­fa­c­to­ri­za­ción en diferido: la deuda técnica aceptada de­li­be­ra­da­me­n­te no se salda a corto plazo, puesto que la re­fa­c­to­ri­za­ción se pasa por alto o se aplaza.
   
• De­sa­rro­llo paralelo de apli­ca­cio­nes: las fases de de­sa­rro­llo que tra­n­s­cu­rren en paralelo, pero no se coordinan, provocan la acu­mu­la­ción de deuda.
   
• Código demasiado complejo: los párrafos de código son demasiado co­m­pli­ca­dos o ilógicos. Las pequeñas mo­di­fi­ca­cio­nes pueden provocar más fallos y mu­l­ti­pli­car la deuda. En el peor de los casos, también aquí se genera un código espagueti.
   
• Procesos de de­sa­rro­llo des­es­tru­c­tu­ra­dos: el de­sa­rro­llo de apli­ca­cio­nes comienza antes de que se definan y decidan un diseño o unos procesos concretos.
   
• Ex­te­r­na­li­za­ción del código: las fases de de­sa­rro­llo se su­b­co­n­tra­tan y, durante el proceso posterior de unión, provocan errores en el código que la dirección del equipo debe aceptar o ignorar.
   
• Mo­di­fi­ca­cio­nes re­pe­n­ti­nas en el proceso: debido a la falta de tiempo, las mo­di­fi­ca­cio­nes re­pe­n­ti­nas en el código no se co­m­prue­ban.

Ward Cu­n­ni­n­gham no solo definió la metáfora de la deuda técnica, sino que también es coautor y primer firmante del Ma­ni­fie­s­to por el de­sa­rro­llo ágil de software. El objetivo de esta filosofía de de­sa­rro­llo de software es fomentar un de­sa­rro­llo y pu­bli­ca­ción de apli­ca­cio­nes más flexibles y pro­du­c­ti­vos por medio de pri­n­ci­pios y axiomas.

En lugar de pe­r­ma­ne­cer durante largos periodos de tiempo ligados a grandes proyectos, los equipos, más pequeños e in­de­pe­n­die­n­tes, se esfuerzan por conseguir fases de trabajo más breves y pu­bli­ca­cio­nes más rápidas de proyectos de menor en­ve­r­ga­du­ra, tales como apli­ca­cio­nes, partes de programas y ac­tua­li­za­cio­nes.

El de­sa­rro­llo ágil de software tiene como co­n­se­cue­n­cia que los equipos escriban y mo­di­fi­quen un código en pequeños pasos y las fases de trabajo se finalicen a más velocidad. Cuando la atención se centra en la rapidez y la pro­du­c­ti­vi­dad, aumenta el peligro de producir un código sucio y, con ello, acumular deuda técnica. Sobre todo, cuando el de­sa­rro­llo ágil de software no va de la mano con la re­fa­c­to­ri­za­ción, la deuda aumenta de manera in­e­vi­ta­ble.

Los efectos de la deuda técnica se co­rre­s­po­n­den con los de los créditos en el sector fi­na­n­cie­ro. Si la deuda no se reduce de manera puntual y regular, se generan intereses, que se muestran en forma de de­sa­rro­llo ra­le­n­ti­za­do, descenso en la pro­du­c­ti­vi­dad y aumento de los costes.

Por lo tanto, a los clientes les interesa acompañar el de­sa­rro­llo a largo plazo con un proceso completo de gestión de calidad, para no tener que pagar la rapidez y el ahorro en la pro­du­c­ción y la pu­bli­ca­ción de los productos con costosas co­rre­c­cio­nes po­s­te­rio­res de errores o, incluso, un parón en el de­sa­rro­llo.

Debido a las nuevas te­c­no­lo­gías y la evolución en los pla­n­tea­mie­n­tos dentro del de­sa­rro­llo de software, no es posible evitar la deuda técnica por completo. De hecho, incluso se la acepta con el fin de publicar programas y apli­ca­cio­nes de manera regular y rápida y no atar a los equipos a proyectos de forma pro­lo­n­ga­da. No obstante, existen medidas pre­ve­n­ti­vas para evitar o reducir la ge­ne­ra­ción o el cre­ci­mie­n­to de la deuda:

• Procesos es­ta­n­da­ri­za­dos para la re­fa­c­to­ri­za­ción y la gestión de calidad.
• He­rra­mie­n­tas siempre ac­tua­li­za­das para la medición y el análisis de errores.
• Ada­p­ta­ción de los co­no­ci­mie­n­tos es­pe­cia­li­za­dos al estado actual de la te­c­no­lo­gía de la in­fo­r­ma­ción mediante formación continua o co­m­po­si­ción de los equipos de acuerdo con las cua­li­fi­ca­cio­nes.
• Diseño claro de códigos mediante división en clases, métodos co­m­pre­n­si­bles y escritura legible para pro­gra­ma­do­res po­s­te­rio­res o externos.
• Re­s­po­n­sa­bi­li­da­des claras y di­s­tri­bu­ción de tareas en equipos para evitar du­pli­ca­cio­nes, re­du­n­da­n­cias y pasos de trabajo co­n­tra­pro­du­ce­n­tes.
• Ar­qui­te­c­tu­ra in­fo­r­má­ti­ca siempre ac­tua­li­za­da por medio de vi­gi­la­n­cia, medición y gestión de calidad co­n­s­ta­n­tes.