Deuda técnica: las posibles consecuencias de ahorrar en el desarrollo de software

Cuando un equipo de desarrollo actúa de manera ahorrativa o con prisas en el desarrollo de software o en la planificación de las infraestructuras informáticas, este ahorro se acaba pagando en forma de deuda técnica. La deuda técnica denomina las consecuencias derivadas de las negligencias, errores o deficiencias deliberadas o involuntarias en relación con el código. Las correcciones y medidas de mantenimiento posteriores frenan la productividad y generan elevados costes adicionales. ¿Qué hay que tener en cuenta para evitar la deuda técnica en el desarrollo de software?

En 1992, Ward Cunningham, programador y coautor del Manifiesto por el desarrollo ágil de software, introdujo la metáfora de la deuda técnica. Con este concepto, Cunningham quería ilustrar la importancia que la refactorización es decir, la correcció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 crecientes deficiencias operativas y estructurales.

El término deuda también implica intereses, puesto que la deuda técnica es relevante para las empresas contratantes sobre todo desde el punto de vista financiero. La deuda técnica no solo implica más esfuerzo y una menor productividad debido a las medidas de mantenimiento posteriores, sino también más costes. Cuanto más descuida la dirección de un equipo el mantenimiento de una infraestructura o aplicación informática defectuosa, más intereses genera la deuda y más caras resultan las correcciones del código.

Según Ward Cunningham, la deuda técnica se origina debido a deficiencias en el código que, por falta de tiempo o presupuesto, obligan a adoptar una solución más rápida del problema, aunque deficiente. Un código escrito de manera minuciosa y exhaustiva es laborioso y requiere mucho tiempo. Por este motivo, a veces los desarrolladores optan por un código sucio con el objetivo de ahorrar así tiempo y esfuerzo. Pero este ahorro se paga con deuda.

Para Cunningham, este aspecto económico de la programación no es algo inusual o antinatural. En caso de que la deuda técnica no se compense mediante refactorización ni el código se optimice con regularidad, el desarrollo acabará por interrumpirse o detenerse debido a los intereses metafóricos.

Martin Fowler, autor de Refactoring: Improving the Design of Existing Code, concretó la metáfora de Cunningham y subdividió la deuda técnica en cuatro tipos, que representó en el cuadrante de la deuda técnica:

Según Cunningham y Fowler, la deuda técnica se puede generar tanto de manera deliberada como involuntaria. Puesto que la tecnología y la programación incluyen revisiones y mejoras continuas, es prácticamente imposible evitar la hediondez del código y la erosión del código. El software también envejece y, a falta de actualizaciones y refactorización, también genera deudas. En la mayoría de los casos, sin embargo, la deuda técnica se debe a decisiones económicas o fallos de programación deliberados o involuntarios.

Aunque generalmente la deuda técnica siempre tiene los mismos efectos sobre el desarrollo de software, las causas pueden ser muy variadas. Aquí se las presentamos:

• Falta de gestión de calidad: los proyectos se desarrollan sin mecanismos de prueba, medición y control de calidad y generan deuda de manera continua.
   
• Presión económica: debido a las exigencias del cliente o a la presión de la competencia, se da prioridad a factores económicos y a un desarrollo rápido en detrimento de la limpieza del código.
   
• Falta de cualificación: los conocimientos técnicos del equipo de desarrollo no se corresponden con las exigencias de un código limpio y elegante. La consecuencia es una hediondez de código o un código espagueti.
   
• Documentación/comunicación insuficientes: el proceso de desarrollo transcurre sin documentar las ampliaciones y modificaciones del código en paralelo. Además, las modificaciones del código no se registran ni comunican a los programadores posteriores. Las posibilidades para la refactorización son limitadas o inexistentes.
   
• Refactorización en diferido: la deuda técnica aceptada deliberadamente no se salda a corto plazo, puesto que la refactorización se pasa por alto o se aplaza.
   
• Desarrollo paralelo de aplicaciones: las fases de desarrollo que transcurren en paralelo, pero no se coordinan, provocan la acumulación de deuda.
   
• Código demasiado complejo: los párrafos de código son demasiado complicados o ilógicos. Las pequeñas modificaciones pueden provocar más fallos y multiplicar la deuda. En el peor de los casos, también aquí se genera un código espagueti.
   
• Procesos de desarrollo desestructurados: el desarrollo de aplicaciones comienza antes de que se definan y decidan un diseño o unos procesos concretos.
   
• Externalización del código: las fases de desarrollo se subcontratan y, durante el proceso posterior de unión, provocan errores en el código que la dirección del equipo debe aceptar o ignorar.
   
• Modificaciones repentinas en el proceso: debido a la falta de tiempo, las modificaciones repentinas en el código no se comprueban.

Ward Cunningham no solo definió la metáfora de la deuda técnica, sino que también es coautor y primer firmante del Manifiesto por el desarrollo ágil de software. El objetivo de esta filosofía de desarrollo de software es fomentar un desarrollo y publicación de aplicaciones más flexibles y productivos por medio de principios y axiomas.

En lugar de permanecer durante largos periodos de tiempo ligados a grandes proyectos, los equipos, más pequeños e independientes, se esfuerzan por conseguir fases de trabajo más breves y publicaciones más rápidas de proyectos de menor envergadura, tales como aplicaciones, partes de programas y actualizaciones.

El desarrollo ágil de software tiene como consecuencia que los equipos escriban y modifiquen 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 productividad, aumenta el peligro de producir un código sucio y, con ello, acumular deuda técnica. Sobre todo, cuando el desarrollo ágil de software no va de la mano con la refactorización, la deuda aumenta de manera inevitable.

Los efectos de la deuda técnica se corresponden con los de los créditos en el sector financiero. Si la deuda no se reduce de manera puntual y regular, se generan intereses, que se muestran en forma de desarrollo ralentizado, descenso en la productividad y aumento de los costes.

Por lo tanto, a los clientes les interesa acompañar el desarrollo a largo plazo con un proceso completo de gestión de calidad, para no tener que pagar la rapidez y el ahorro en la producción y la publicación de los productos con costosas correcciones posteriores de errores o, incluso, un parón en el desarrollo.

Debido a las nuevas tecnologías y la evolución en los planteamientos dentro del desarrollo 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 aplicaciones de manera regular y rápida y no atar a los equipos a proyectos de forma prolongada. No obstante, existen medidas preventivas para evitar o reducir la generación o el crecimiento de la deuda:

• Procesos estandarizados para la refactorización y la gestión de calidad.
• Herramientas siempre actualizadas para la medición y el análisis de errores.
• Adaptación de los conocimientos especializados al estado actual de la tecnología de la información mediante formación continua o composición de los equipos de acuerdo con las cualificaciones.
• Diseño claro de códigos mediante división en clases, métodos comprensibles y escritura legible para programadores posteriores o externos.
• Responsabilidades claras y distribución de tareas en equipos para evitar duplicaciones, redundancias y pasos de trabajo contraproducentes.
• Arquitectura informática siempre actualizada por medio de vigilancia, medición y gestión de calidad constantes.