Tengo que hacer una confesión: siempre desconfié de la noción de deuda técnica. Siempre me ha parecido un concepto de marketing.

Es como si decides comprar un coche, el vendedor te da las llaves y añade con una sonrisa: «Usted debe ya $ 10 000». Y él no habla del crédito para el auto, no, simplemente quiere decir que el coche que acabas de comprar tiene ciertos defectos que van a volverse cada vez más aparentes con el tiempo, cansarán el motor, la carrocería, incluso probablemente el conductor.

¿Cómo reaccionarías si un vendedor te dijera esto? ¿Comprarías este coche?

De acuerdo, sé que la compra de un coche, de una casa, de todos bienes costosos y complejos se acompaña de gastos de mantenimiento. En este sentido, me gusta el poder explicativo de la analogía de la deuda técnica. Y por otra parte, el desarrollo software a menudo ha sido comparado á la construcción de una vivienda.

Pero todo el mundo conoce la historia: cuando Ward Cunningham inventó este concepto en 1992, pasó relativamente inadvertido, por lo menos fuera de la comunidad de los desarrolladores, hasta estos últimos años cuando, bing bang boom, la deuda técnica se transforma en una verdadera explosión de los medios de comunicación y realmente, da miedo. Según Gartner, alcanzaba 500 mil millones de dólares en 2010 y debería doblar de aquí a 2015. Con tal inflación, será superior a la deuda soberana de Rusia en 2020. ¡Qué angustia!

La deuda técnica es un sueño para los «mercadostécnicos» debido a que:

• Es técnico, pues es probable, y pone en experto al que habla de eso.
• Llama la atención: debes dinero – mucho – y no lo sabías.
• Se presta a todo tipo de ejercicios muy creativos: techo de la deuda, cálculo de los intereses, estimación de punto muerto, reducción del riesgo sistémico, etc. Muy inventiva: la noción de código o de aplicación tóxica. Me pregunto si proporcionan una máscara antigás a los desarrolladores.

Así como lo explica Ward Cunningham (Ward Explains Debt Metaphor), el utilizó la metáfora de la deuda técnica para justificar a su jefe el refactoring realizado sobre el producto financiero que desarrollaban. Pidiendo prestado al principio permite ir más rápidamente, pero debemos luego pagar los intereses. Como la expansión de un negocio: si puedes conseguir un prestado, puedes contratar a más gente, investir en más puntos de venta, disponer de un presupuesto publicitario, etc. Crecerá más rápidamente pero no puedes pedir prestado de forma continua porque los intereses y el reembolso de tu deuda se convertirán en el principal puesto de gasto e impedirán todo crecimiento.

Ward también explica que sus palabras han sido repetidas de manera confusa, para no decir errónea. Él insiste en que un código debe ser escrito correctamente desde el principio para permitir la refactorización más tarde. Un prestamo no significa escribir código de calidad pobre con el fin de sacar la aplicación en el tiempo a pesar de los retrasos del proyecto o de los errores de planificación, sino desarrollar rápidamente versiones frecuentes (Extreme Programming) e introducir el refactoring del código en el ciclo de vida del proyecto.

Ward Cunnigham es un desarrollador que, como él mismo lo explica, utilizó el concepto de deuda técnica como metáfora. Existen 2 tipos de metáforas:

• Las con un poder descriptivo, que permiten comprender un concepto por la ilustración, la comparación con otro concepto.
• Las con un poder de predicción, que permiten predecir un cierto comportamiento y descubrir nuevas leyes.

Por ejemplo, te piden explicar lo que es un átomo. Puedes hacer una analogía con una planeta que gira alrededor de su sol, tal como los electrones alrededor de su núcleo. Sería una analogía del primer tipo.

Ahora, si decides construir una modelización de un sistema solar como un conjunto de objetos (planeta, sol), de atributos (masa) y de relaciones (atracción), y si lo utilizas para deducir una nueva modelización entre los electrones y su núcleo que permita predecir su comportamiento, entonces se tratará de una analogía del segundo tipo.

La metáfora de Ward Cunnigham es una herramienta explicativa muy poderosa, pero no se trata de una modelización de la que se podría extraer nuevas leyes. Su interés principal reside en la idea de incorporar el refactoring de manera continua en el ciclo de vida de una aplicación. Pretender que es posible cifrar la deuda técnica, de calcular su coste a la línea de código, de evaluar los intereses de esta deuda con el fin de considerar hasta qué punto de la curva se vuelve demasiado pesada, es Marketing.

Por otra parte, esto no es inocente si las cifras son generalmente horrorosas y en crecimiento de un año al otro. ¿Por qué crees que tu aplicación de 300 000 líneas de código presenta una deuda técnica de 1 millón de dólares incluso antes de que verla para conocer realmente su nivel de no-calidad? ¿Cuánto estarías dispuesto a gastar para reducir esta deuda? ¿$ 100 000? ¿$ 200 000?

Los desarrolladores lo han bien comprendido. La deuda técnica representa :

• La idea que el código debe regularmente refactorisarse con el fin de limitar la pobre calidad á un nivel aceptable.
• Un indicador interesante que introduce una noción de esfuerzo y de coste de corrección.

Si tienes la elección entre corregir un defecto crítico a un coste muy bajo y corregir un defecto que importa poco a un coste elevado, evidentemente no vas a dudar mucho. Como tal, la deuda técnica puede constituir una ayuda a la decisión, pero sin jamás olvidar que no se trata de un verdadero coste financiero y sabiendo interpretarlo correctamente. Algunos ejemplos.

Puedes utilizar la deuda técnica como un indicador (KPI) dentro de un SLA (Acuerdo de nivel de servicio) para un proveedor, pero de manera diferente según el tipo de desarrollo:

• Nuevo desarrollo: una deuda técnica cero no tendría sentido. Toda nueva aplicación, hasta muy bien escrita, implica necesariamente un mínimo de componentes o muy grande o complejo o con muchos enlaces entre ellos. Simplemente hay que procurar que sus números siguen siendo razonables. Pues definirás con tu proveedor un nivel de deuda técnica que no debe sobrepasar.
• Mantenimiento: tu proveedor no es responsable de la deuda técnica existente en una aplicación desarrollada por alguien que no sea él. Simplemente debes evitar que esta no se vuelva más importante. Aquí, no se trata de fijar un umbral de deuda técnica que no sobrepasar sino evitar que crezca la taza acutal. Hasta puedes incitar con bonificación a tu proveedor a disminuirla.

Alinear la deuda técnica en los objetivos TI, ellos mismos alineados con los objetivos de la empresa. Ya lo hemos visto en el post ‘Best of both worlds’, una política de tolerancia cero para violaciones de rendimiento no tiene sentido cuando más importa no sobrepasar los presupuestos. Por el contrario, si el dinero no es un problema, pero la aplicación debe funcionar correctamente a la fecha planificada, los defectos en materia de rendimiento y de robustez y el time-to-market se vuelven críticos. Construye tus planes de acción con arreglo a los objetivos, y luego solamente con arreglo a la deuda crítica, no lo inverso.

Déjales bastante latitud a los equipos de proyecto para decidir por sí mismos acciones de refactoring, pero define con ellos un objetivo en materia de deuda técnica e inclúyelo en un Quality Gate. En general, los desarrolladores serán eficaces en cuanto a que optimizarán sus acciones de refactoring corrigiendo los defectos más graves pero menos costosos en esfuerzo. Esto supone sin embargo que sean equipados con una herramienta de análisis de código para poder evaluar la deuda técnica. Sobre este punto, ver nuestro post ‘10 to 20 metrics’.

Estos son sólo algunos ejemplos simples, basados ​​en nuestros posts anteriores. Hay muchos, y quizás tendremos la oportunidad de detallarlos en el futuro.

La deuda técnica es una medida interesante que permite objetivar la relación con los proveedores y los equipos de proyecto. Es un indicador de un orden de magnitud en términos de esfuerzo para mantener la no-calidad en un nivel razonable.

En cambio, evita considerar la deuda técnica como un coste financiero real a tomar en cuenta en tus decisiones de proyecto y de inversión. Es un concepto de desarrollador para los desarrolladores, no para los de marketing.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.