¿Sabes cual es mi broma favorita respecto a los consultores?

Un hombre entra en una tienda de animales y ve a un mono en una jaula con una etiqueta ‘Mono C – $ 2.000’. El dueño de la tienda se acerca y el cliente le pregunta: « Es caro su mono. ¿Qué tiene de especial? ». Y el dueño le dice « Es un mono que sabe programar en C. Muy bueno, es rápido, produce un código de calidad sin errores. A ese precio, es un buen negocio ».

El cliente mira una otra jaula con una etiqueta ‘Mono C++ – $3 000’. « Oye, este es aún más caro. ¿Qué sabe hacer? ». « Igual que el primero, pero con C++, un lenguaje Objeto, más complejo, pero también un programador muy bueno. Y conoce un poco Java ».

El cliente descubre una tercera jaula con una etiqueta ‘Mono – $5 000’. « Ah, este es tan caro como los otros dos. Debe ser muy bueno. ¿Qué puede hacer? ».

« Pues, la verdad que no lo sé », responde el dueño. « Pero él dice que es un consultor ». (1)

¿Por qué estoy contando esta broma? Porque veo más y más consultores tratar de actualizar o completar o precisar el concepto de deuda técnica, pero finalmente lo convierten en una especie de teoría general, sin aplicación práctica, por no decir imposible.

Había escrito hace unos meces un post ‘Tecnical debt vs. Marketing guys’ en el que denunció los hombres (o las mujeres) de marketing que, con gran inventiva, amplian el concepto de deuda técnica para todo tipo de variantes financieros más asombrosos uno que el otro. Por ejemplo, la analogía con los activos financieros tóxicos: algunas aplicaciones tóxicas esperan el peor momento para explotar completamente con la intención de causar el mayor daño posible.

Y veo más y más consultores de calidad que hacen lo mismo, como en este vídeo ‘Technical Debt A Finer Edge‘. Los puntos principales son:

• La definición de la deuda técnica introducida por Ward Cunningham en 1992 es arcaica porque se centra demasiado en el código y los programadores.
• Se debe actualizarla para tener en cuenta todos los defectos, deficiencias, errores y negligencias que se producen en el proceso de producción del software y en todas las fases del ciclo de vida del proyecto (diseño, pruebas, etc.).
• También hay que tener en cuenta los errores de gestión del proyecto y los procesos incorrectos o insuficientes: estimación incorrecta de las cargas de trabajo, de planificación, falta de gestión de riesgos, etc.).

Este video retoma una articulo de Capers Jones ‘The Errors and Hazards of Technical Debt’ en lo cual el define la deuda técnica como el coste de corregir los errores cometidos durante el desarrollo de una aplicación.

« The essential idea of technical debt is that mistakes and errors made during development that escape into the real world when the software is released will accumulate downstream costs to rectify. »

Las desventajas según Capers están en la falta de consideración de los defectos de calidad: « In order to evolve from a novelty into an effective metric, technical debt needs to encompass all quality costs and not just post-release code changes ».

El artículo concluye que la deuda técnica es sólo una parte del coste de la calidad, y que esta última medida (Cost Of Quality o COQ) es más apropiado cuando se quiere estudiar la dimensión económica de la calidad.

Deuda intencional y deuda involuntaria

Estoy totalmente de acuerdo con Capers para decir que la deuda técnica es sólo una parte del coste de la no-calidad, pero no estoy de acuerdo para ampliar este concepto y incluir a todos estos costes, como se requiere en el video anterior.

El concepto de deuda técnica es entendida e interpretada de maneras muy diferentes y Ward lo explica en este articulo ‘Ward Explains Debt Metaphor’ que tiene por objeto aclarar la confusión habitual que la deuda técnica es causada por el código de mala calidad.

La analogía utilizada por Ward es que un prestado puede hacer que tu proyecto sea más rápido, pero en algún momento, tendras que pagar tu deuda. Hacer una primera versión prototipo es el equivalente de una inversión que puede ofrecer algo de forma rápida a los usuarios pero se necesitará un esfuerzo adicional para ir desde este prototipo hasta la versión final, y una refactorización de unos componentes ya desarrollados para compensar tu inversión.

El concepto original tiene como objetivo promover la metodología de desarrollo ‘Extreme Programming’, utilizando ciclos iterativos para completar nuestro conocimiento de las especificaciones funcionales, adaptar el diseño de la aplicación y adquirir experiencia (el equipo de Ward decidió programar en Smalltalk, un lenguaje Objeto nuevo para ellos).

Como lo explica Uncle Bob en este blog, ‘A mess is not a technical debt’, la deuda técnica es un compromiso voluntario – entregar rapidamente una versión 1.0 incompleta – para hacer frente a las limitaciones del proyecto (requisitos incompletos, calendario corto, etc.). Un código de mala calidad no es una decisión racional, y por lo tanto no se incluye en la deuda técnica: es más bien una pérdida.

En todos los casos, son los desarrolladores que se encargan de la refactorización. Y por lo tanto, no hay forma de identificar los cambios realizados para mejorar la arquitectura del código de los para corregir un defecto. Un programador decide dividir una clase en dos porque una funcionalidad adicional necesita especializar las clases o simplemente para reducir la complejidad y mejorar la legibilidad del código. ¿Deuda técnica o no?

Martin Fowler explica en este articulo ‘TechnicalDebtQuadrant‘ que poco importa. La metáfora es una poderosa herramienta de comunicación que le permite justificar a los stakeholders y el management la necesidad de refactorización del código y de pagar la deuda técnia sea cual sea su origen, intencional o no intencional. Un buen desarrollador conoce las buenas prácticas de programación, pero puede omitir alguna o deliberadamente y de manera temporal en la espera de la próxima versión, o por falta de atención. La perfección no es de este mundo.

Diferentes tipos de deuda

Cualquiera el origen de la deuda técnica, son los programadores que la gestionan. Y es por eso que creo que esta noción no se extiende a otros costes de no-calidad.

Un error, un omisión en una especificación funcional o en la fase de diseño sin duda necesitará que modificar el código, pero el origen de este cambio no es en la programación y las decisiones o fallos con buenas practicas de los desarrolladores.

Un plan de pruebas incompleto o insuficiente puede resultar de la decisión del management de entregar lo antes posible un prototipo que permite a los usuarios especificar sus necesidades sin tener que preocuparse de los errores, o puede resultar de la falta de tiempo, de conocimientos o de experiencia del equipo de QA, o de una documentación incorrecta o de herramientas inadecuadas.

La metáfora de la deuda puede aplicarse a estos ejemplos, pero en este caso, mejor hablar de deuda funcional o de QA, en lugar de tratar de integrar en la deuda técnica todos los costes de no-calidad.

Otra razón por la que creo que la deuda técnica debe aplicarse a los programadores y el código únicamente:

• Los bugs que encuentran su origen en el código son los más numerosos: aproximadamente uno de cada tres.
• Estos defectos de código son los más fáciles de detectar y corregir: alrededor de 85% y esta cifra puede elevarse a 95% mediante una herramienta de análisis de código.

Los defectos en la especificación y el diseño son menos frecuentes (pero no mucho) y más difícil de detectar y eliminar.

La no-calidad de aplicación tiene su origen en defectos muy diferentes con riesgos e impactos muy diferentes. Agrupar a todos en el mismo saco de la deuda técnica crea confusión y hace que este concepto sea poco práctico.

Deuda técnica y programadores

Última razón: los defectos de código son los únicos que se pueden identificar de manera automatizada, a través de una herramienta de análisis de código. Nunca se podrá automatizar la detección de una especificación ausente, un error o falta de pruebas. Son necesariamente tareas manuales.

Puedes analizar 5 000 clases Java y 100 000 líneas de código en pocos minutos y fácilmente identificar todas las violaciónes. Puede incluso crear automáticamente los planes de refactorización que el desarrollador descubrirá en su lista de tareas.

Si queremos integrar otros defectos en la deuda técnica, entonces se llevará a cabo una evaluación manual de riesgos o de pruebas funcionales para cada una de estas 5 000 clases. Imposible.

Los programadores también han comprendido el uso del concepto de deuda técnica a nivel operativo, como se muestra en este artículo ‘Effective Code Review with Sonar’en el blog de Sonar. Un proceso de Inspección Continua permite medir el nivel de la deuda técnica y asegurarse de que no crece.

Por lo tanto, estoy de acuerdo con Capers para decir que la deuda técnica no debe confundirse con el coste de la no-calidad (COQ) o este concepto se vuelve impracticable.

Y mientras nosotros consultores discutimos la definición exacta del concepto, los desarrolladores utilizan diariamente la deuda técnica como métrica que monitoriza el nivel de no-calidad del código, independientemente de la definición exacta.

Actualizar o ampliar el concepto de deuda técnica puede ser intelectualmente interesante, pero no sirve de nada sin una aplicación práctica y operativa. Como en la broma respecto a los consultores, no se sabe muy bien qué es o qué podemos hacer con el.

 

(1) Variante: « Pues, la verdad que no lo sé », responde el dueño. « Pero los otros dos lo llaman ‘Jefe’ ». Mejor evitar esta variante con tu jefe o él va a pensar que estás sugiriendo que no se sabe lo que hace.

Esta entrada está disponible también en Read that post in english.