Deuda técnica: toda empresa necesita un programa de corrección de la deuda técnica

La guía de desarrollo de aplicaciones de Gartner para 2012 recomienda encarecidamente abandonar la cascada, adoptar un enfoque ágil y poner en marcha un programa de corrección de la deuda técnica. Esto debe ser impulsado por el Product Owner y apoyado por la dirección. Pero, ¿qué es la deuda técnica y cómo podemos gestionarla?

IEEE Software (noviembre de 2012) dedica un número entero a este problema con muchos análisis y puntos de vista esclarecedores. En las páginas anteriores se muestra cómo asignar una cifra financiera a los datos técnicos. Por otro lado, se defiende que la deuda técnica tiene más alcance que cualquier cifra financiera y puede conducir al éxito o al fracaso de productos y empresas.

Punto: La deuda técnica como metáfora de la calidad del código por Israel Gat
A diferencia de la deuda financiera, la deuda técnica no puede calcularse únicamente a partir del historial. El crecimiento de la deuda financiera en función del tiempo se determina computando los intereses y sumando los dólares adeudados por deudas más antiguas a las recién contraídas. Por el contrario, la deuda técnica acumulada por aceptar un alto nivel de complejidad hace nueve meses es muy diferente de la deuda técnica acumulada por duplicar rápidamente algunos bloques de código hace seis meses. cuando se toman varios tipos de deuda técnica en diferentes momentos en el tiempo, el total general en un momento posterior es difícil de evaluar. El equipo de desarrollo aún puede recordar que hace nueve meses tomó prestada una semana de tiempo en complejidad y, más recientemente, un día mediante la duplicación de código. Sin embargo, entre estos dos "préstamos" y la decadencia del software, ¿tardarán 6, 10, 20 o 50 días en devolver la deuda? Esa es la verdadera cuestión.
Para determinar el nivel actual de deuda técnica, hay que partir del estado actual del código y profundizar en él: empezar con el análisis del código, buscar los déficits de calidad, determinar el tiempo necesario para corregir cada déficit, determinar el tiempo necesario para corregir cada déficit, agregar el tiempo necesario para corregir y, por último, agregar el coste necesario para corregir. Una vez que se monetiza la deuda técnica, cualquier parte interesada puede comprender y apreciar sus implicaciones operativas, financieras y empresariales. Un director financiero no tendrá ningún problema en relacionarse con una afirmación como "la deuda técnica del proyecto asciende a $500.000". Del mismo modo, sus colegas de marketing, servicios profesionales o atención al cliente evaluarán fácilmente lo que este nivel de deuda técnica significa para sus departamentos.

Contrapunto: Una metáfora útil del riesgo mal practicada por Christof Ebert
Mi propia definición (de deuda técnica) es bastante sencilla: la deuda técnica es la consecuencia final de una mala ingeniería de un producto de software para obtener beneficios a corto plazo que hacen que el mismo trabajo cueste más de hacer más tarde. Fijémonos en cualquier caso práctico de la industria.
En 1996, Netscape Navigator dominaba el mercado de los buscadores con una cuota del 80%; Internet Explorer, de Microsoft, tenía el 20% restante. Sin embargo, en 2002, la cuota de mercado de Microsoft subió al 96% y la de Netscape a sólo el 2%. ¿Qué ocurrió? Cuando se fundó en 1994, Netscape poseía un producto maravilloso y único para acceder a Internet. Los ingenieros lo hicieron evolucionar rápidamente pero perdieron el control: la velocidad dominó a la ingeniería y la calidad, el código empeoró con cada nueva función y nadie se dio cuenta de que habían acumulado una deuda que no se podía pagar. Esto nos lleva a nuestra primera lección: hacer visible la deuda técnica. El código inicial de Explorer también se descontroló, pero Microsoft tomó otra dirección: optó por rediseñar por completo Explorer, lo que retrasó el producto pero acabó ayudándole a dominar el mercado. Nuestra segunda lección: evaluar las compensaciones. Microsoft decidió que sus principales objetivos eran un equipo central de arquitectura, la gestión del producto y la mantenibilidad y portabilidad. En cambio, Netscape impulsó Java en un nuevo producto, pero sin una arquitectura y un diseño de producto claros. Al final, la empresa desapareció. Tercera lección: controlar sistemáticamente la deuda técnica.