Deuda Técnica - expuesta

El significado y origen de la “deuda técnica”

La metáfora de la deuda técnica (TD) en el contexto del software fue acuñada por Ward Cunningham, quien en ese momento estaba trabajando en la codificación de un sistema financiero. Usó la metáfora para explicar a sus colegas financieros el razonamiento para refactorizar y reescribir partes de códigos a medida que evolucionaba el conocimiento de los requisitos.

“Cuando un equipo de desarrollo toma atajos y entrega código que no es del todo adecuado para la tarea de programación del momento, incurre en TD. Esta deuda disminuye la productividad. Esta pérdida de productividad es el interés del TD”.

La explicación original de Ward era bastante estrecha y específica, pero la metáfora ahora ha cobrado vida propia:

Hoy en día Deuda Técnica significa varias cosas:

• Código que necesita cambios para eliminar atajos problemáticos, que se crearon antes de que evolucionáramos nuestra comprensión de lo que se necesita. (significado original).
• Código que tiene errores.
• Defectos en la arquitectura y los diseños que fueron atajos creados por decisiones tácticas.
• Código que es difícil de mantener.
• Código que depende de bibliotecas, sistemas operativos u otros componentes técnicos desactualizados
• Defectos en los requisitos que se crearon porque se tomaron atajos para comprender los requisitos.

La distinción entre deuda tecnológica, legado y obsolescencia del software:

Sistemas heredados

La TD suele tratarse de atajos técnicos que se han tomado y que están causando problemas. Las aplicaciones y componentes de software obsoletos que se basan en tecnología que uno no elegiría ahora, a menudo se clasifican como sistemas heredados. En el momento en que se construyeron, es posible que no se hubieran tomado atajos, por lo que no habría deuda tecnológica allí. A menudo la gente clasifica erróneamente un sistema heredado como deuda tecnológica, cuando en realidad podría estar acercándose a la obsolescencia. Si un sistema heredado tiene interfaces adecuadas con otros sistemas y desempeña su función central sin problemas, puede ser heredado pero no puede ser ni TD ni obsoleto. Cuando un sistema ya no sirve al negocio, aunque lo haya hecho por un tiempo, consideramos que se trata de una obsoleto sistema, no necesariamente TD.

Obsolescencia del software

El valor de un software para una organización disminuirá con el tiempo. Después de años de uso, es probable que disminuyan los argumentos comerciales para mantener el sistema antiguo. La aplicación tiene una vida útil y eventualmente es más económico retirarla o reemplazarla que mantenerla funcionando. El software se vuelve obsoleto cuando el entorno operativo que necesita ejecutar deja de ser compatible (hardware, sistema operativo, bibliotecas) o cuando el software en sí ya no sirve para el propósito para el que se necesita.

Una vez que se escribe e implementa una nueva pieza de software, es prudente que los ejecutivos planifiquen algunos años de actualizaciones y planifiquen su eventual retiro/reemplazo. La vida útil económica de un software varía. Algunos tipos de software quedan obsoletos después de unos pocos años (muchos software de consumo), mientras que otros pueden quedar obsoletos sólo después de décadas (por ejemplo, los sistemas bancarios COBOL o los sistemas de registro en general). La obsolescencia no es lo mismo que la deuda tecnológica. Un software muy fiable puede quedar obsoleto y aún así no tener TD.

El costo de la deuda técnica

Siguiendo con la metáfora financiera podemos decir que para algunas aplicaciones de software, la tasa de interés de ese TD puede ser muy alta, mientras que para otras puede ser más baja. Si el costo para la empresa de no solucionar el problema es bajo, entonces la tasa de interés del TD es baja. El costo total de TD varía según su impacto en la operación y las direcciones comerciales. Tomemos, por ejemplo, un proyecto en el que se toman atajos con los requisitos de calidad. La consecuencia de esto es que el software TENDRÁ que reescribirse antes de que entre en funcionamiento. Esta es una creación tonta de TD, que probablemente se pueda evitar, y explica en gran medida por qué algunos proyectos de software que descuidan los requisitos llegan tarde o fracasan. Es necesario un enfoque caso por caso para la evaluación de impacto, pero se puede considerar un enfoque más genérico para el tamaño de la deuda.

Dimensionamiento COSMIC de la Deuda Técnica

El código TDin se puede medir en CFP.

La forma en que surge el TD puede deberse a requisitos deficientes, decisiones y atajos de arquitectura y diseño. Esto luego se traduce en un código que hace algo incorrecto o lo hace de una manera que provocará una funcionalidad inapropiada.

Cuantificación de la deuda técnica

Estas son las preguntas que deberían hacerse los ejecutivos prudentes:

• ¿Qué tamaño tiene el TD?
• ¿Cuál es el costo si no lo arreglamos?
• ¿Cuál es el costo si lo hacemos?

Para las organizaciones que ejecutan cientos de aplicaciones con datos operativos y estratégicos, es útil normalizar la respuesta a estas preguntas para que se puedan priorizar las inversiones para abordar la TD.

Tamaño y costo de reparación.

El dimensionamiento funcional es un enfoque excelente para estandarizar el dimensionamiento de TD. La unidad de medida es el Punto de Función COSMIC o Punto de Función. Por ejemplo, una aplicación tiene un tamaño total de 1000 CFP, de los cuales 100 CFP son interfaces que necesitan reescritura (TD). El costo por CFP o costo por FP para reemplazar o reescribir el atajo generalmente se puede determinar fácilmente utilizando datos de referencia. El costo de reparación puede ser $800 – $1500 por CFP. El uso de un enfoque de tamaño universal significa que se puede aplicar en TD en código, diseños, arquitectura e incluso requisitos. Es muy importante considerar también el costo de migrar desde el estado anterior y posterior, así como cualquier impacto no técnico, como cambios de personas y procesos.

Impacto en los negocios

Al determinar el costo total del TD, debe considerar tanto la cantidad que está afectando su negocio como el costo de repararlo. El enfoque caso por caso para la evaluación de impacto es apropiado. Y esto normalmente sólo puede ser determinado por personas técnicas y empresariales que colaboran para responder "¿en qué medida los atajos técnicos impiden que la empresa alcance sus objetivos?"

Exponiendo la deuda técnica

Exponer TD es útil ya que puede ayudar a proporcionar información temprana para decisiones estratégicas sobre sistemas de software. Por ejemplo, un sistema cargado de TD puede ser candidato para un reemplazo temprano. Mientras que otra pieza de software que tiene TD limitada puede ser más adecuada para extender su vida útil.

Detectar deuda técnica en su organización

Si una aplicación de software se describe constantemente como inflexible debido a la forma en que almacena, maneja o estructura los datos, entonces es posible que sea TD el que lo esté frenando. En otras palabras, atajos técnicos o malas decisiones de diseño que nunca han cambiado para satisfacer las necesidades de las empresas.

Si un proyecto para implementar algunos cambios o novedades en el software experimenta períodos prolongados de corrección de errores o refactorización, esto puede deberse a Pobres requisitos de obra que generaron deuda técnica..

Evitar la deuda técnica

Este es el enfoque más prudente. Es la idea de que es más barato desarrollar bien el software la primera vez. Sin embargo, respetando la definición original del término dada por Ward Cunningham, esto no será posible. Si la necesidad (estratégica) y el uso del software no se conocían cuando se escribió el código por primera vez, entonces era inevitable algo de TD. Sin embargo, se deben hacer todos los esfuerzos posibles para mantener esta revisión al mínimo. El enfoque para hacerlo es permitir suficiente tiempo y recursos para cumplir con los requisitos, la arquitectura y el diseño de manera adecuada antes de comenzar la codificación. Esto debería exponer las incógnitas conocibles para evitar la creación y eliminación de TD.

Reducir la deuda técnica

Hay dos enfoques generales para reducir la TD:

1. Realice la reescritura detallada para eliminar los atajos o defectos problemáticos.

2. Saltar la deuda. Realice un reemplazo total de TD con un código reutilizable adecuado. (“Leapfrog the Legacy”, la idea de saltarse el legado no es nueva, aunque acuñé esta frase porque creo que ayuda a las personas sin conocimientos técnicos a comprender los argumentos de algunas decisiones técnicas complicadas).