Cálculo de la deuda tecnológica: basado en la velocidad vs. Basado en problemas vs. Explicación de las mediciones basadas en la calidad

¡Las tasas de interés aumentaron un 157%!

No, no estoy hablando de la última decisión de la Fed, sino de la desaceleración que enfrentó Fictional Inc. después de lanzar la versión 3.0 de su plataforma.

Afortunadamente para ellos, el lanzamiento del producto fue increíblemente exitoso y están comenzando a ver un aumento rápido en los ingresos, pero ahora necesitan pensar en cómo van a lidiar con la deuda técnica que introdujeron como parte del lanzamiento.

Se puede pensar que la nueva deuda tecnológica que se introdujo como parte de una nueva versión aumenta la tasa de interés y aumenta la desaceleración que enfrenta el equipo en el futuro.

(Voy a suponer que está bastante familiarizado con el concepto de deuda técnica aquí, pero si necesita un repaso para ponerse al día, aquí tiene una guía rápida). cebador )

Ok, probablemente no escuchará a un gerente de ingeniería hablar así sobre su deuda técnica.

¿Pero por qué no?

Ser capaz de medir y cuantificar el impacto continuo de su la deuda tecnológica es crítica si desea armar un plan de acción para abordarlo.

Cuando pensamos en la deuda técnica, el interés es la cantidad de tiempo perdido en el desarrollo actual y futuro de sus niveles existentes de deuda técnica.

Esto significa que es la pieza crítica de la deuda a considerar cuando se piensa en decisiones futuras para pagar el principal (el costo de reescribir, refactorizar o corregir el código responsable de la deuda), ya que solo lo consideraremos si el interés es lo suficientemente alto.

¿Qué es un nivel saludable de deuda técnica?

La deuda técnica claramente ralentiza el nuevo desarrollo, pero eso por sí solo no significa que debamos arreglar la deuda tecnológica en todas partes. Volver a escribir o refactorizar el código existente puede ser significativamente costoso, por lo que solo queremos pagar el principal de nuestra deuda técnica si nuestro interés (la cantidad que nos está frenando para avanzar) supera nuestro principal.

Un problema obvio surge de inmediato: el principal es una unidad de tiempo fija (horas para arreglar/reescribir) pero el interés es una tasa de horas perdidas por tiempo. Para dar cuenta de esto, debemos introducir la idea de un intervalo de impacto : el tiempo durante el cual nos preocupamos de si las futuras desaceleraciones de la deuda técnica exceden el costo de la reescritura. El intervalo de impacto que le interesa dependerá en gran medida de su empresa, su proceso de planificación típico y su etapa o el ciclo de vida de su base de código, pero personalmente, por lo general, consideraré un intervalo de impacto de 3 meses. En nuestra etapa inicial como empresa, mirar cualquier cosa en escalas de tiempo de más de un año es demasiado amplio, pero algo más corto que 2 o 3 meses subestimará en gran medida el impacto de la deuda técnica, como veremos más adelante.

Esto significa que no vale la pena abordar nuestro nivel de deuda tecnológica si:

Por ejemplo: si tuviéramos un proyecto pequeño que sabíamos que tenía una deuda tecnológica que nos retrasó 2 horas por semana, nos llevaría 4 días refactorizar esa deuda y nos preocuparíamos por un intervalo de impacto de 3 meses, entonces no lo haríamos. pasar el tiempo para pagar esa deuda todavía.

Ahora, esto en realidad no responde al nivel de lo que es un nivel saludable de deuda técnica, porque creo que todos podemos estar de acuerdo en que enfrentar grandes ralentizaciones en el equipo no es saludable. En su lugar, ahora tenemos una forma rápida de determinar cuándo debemos o no centrarnos en la reescritura y la refactorización. Echaremos un vistazo a lo que realmente es un nivel saludable de deuda un poco más adelante en el artículo.

¿Cómo medimos la deuda técnica?

Determinar la tasa de interés de nuestra deuda tecnológica requiere que averigüemos cuánto nos están ralentizando las diferentes decisiones que hemos tomado. Desafortunadamente, no hay una forma obvia o trivial de rastrear cuánto se está ralentizando su desarrollo, pero hay tres enfoques diferentes que puede tomar para obtener buenas aproximaciones.

Medición basada en la velocidad

La forma más directa de vincular las ralentizaciones a diferentes secciones de nuestro código base es observar cómo varía la velocidad con el tiempo, en diferentes secciones de su proyecto. Mirando a través de diferentes áreas de la base de código, puede comenzar a identificar variaciones (por ejemplo, cualquier desarrollo que toque esta sección de análisis tarda 3 veces más que cualquier otra cosa) en las diferentes secciones. Observar la variación de un área a lo largo del tiempo también puede brindarle una indicación de cómo el nuevo desarrollo ha impactado la tasa de desarrollo futuro y le brinda una indicación del nivel de interés con el que está lidiando su equipo.

Por ejemplo: si tenemos un proyecto relativamente simple con 4 áreas diferentes en las que trabajaremos, entonces podemos ver cómo cambia la velocidad con el tiempo (aquí estamos rastreando la velocidad en puntos de la historia/mes del desarrollador).

Medición basada en la velocidad del impacto de la deuda técnica

Desde aquí podemos ver que D siempre ha tardado ~3 veces más en trabajar que cualquiera de las otras áreas para tareas igualmente complejas. Esto implica que tiene el triple de interés que todas las demás secciones del código base. B solía estar relativamente a la par con A & C, pero a partir del mes 4, de repente saltó y tomó el doble de tiempo. Esto sugiere que introdujimos algo de deuda aquí que duplicó nuestra tasa de interés frente a lo que era antes para B.

Una cosa a destacar es que no estamos hablando de la tasa de interés para todo el código base, sino de la tasa de interés para componentes/áreas individuales; afectan todo lo que hacemos, sino que están localizados en una parte del código base.

Hay algunas advertencias importantes en las que pensar cuando se trata de la medición basada en la velocidad.

• La velocidad puede ser volátil y puede depender de factores independientes de la deuda técnica, como errores nuevos (o existentes), estimaciones desalineadas, obstáculos técnicos o retrasos en proyectos externos.

• Las estimaciones tienen un nivel de incertidumbre inherente y, para empezar, pueden ser una medida imprecisa.

• Recopilar y analizar estos datos puede ser complicado y llevar mucho tiempo.

  
  

Un proxy rápido para la medición basada en la velocidad es pedirle a su equipo de ingeniería que estime relativamente cuánto tiempo lleva completar un proyecto/tarea en cada área principal de su base de código. Acuerde una línea de base establecida para un área bien entendida/usada con frecuencia y luego haga que todos calculen el área entre sí como un porcentaje o múltiplo de esa línea de base. Si bien no es tan riguroso como un enfoque de medición basado en la velocidad total, puede dar una idea rápida de su interés de deuda tecnológica relativa en función de la perspicacia y la intuición de su equipo.

Medición basada en problemas

Un enfoque diferente es identificar instancias específicas de deuda técnica dentro de su proyecto y estimar cuánto pueden estar ralentizándolo cada una. Parte de esto se puede hacer mediante el uso de herramientas automatizadas, como herramientas de análisis estático, para encontrar problemas comunes relacionados con la calidad del código que pueden afectar la legibilidad, la capacidad de ampliación o el mantenimiento de un proyecto. Para cada tipo de problema, puede asignarle un costo de interés (por ejemplo, 5 min/semana o 1 %) en función de la experiencia de su equipo en el tratamiento de este tipo de problemas.

Sin embargo, esto solo capturará un subconjunto de la deuda técnica que causa problemas; otros serán más sutiles o más personalizados para su base de código y solo se observarán mientras su equipo está trabajando activamente en esa área del código. En este caso, querrá registrar el problema específico (vinculado a un área de su base de código) junto con el impacto estimado que tiene en la ralentización del desarrollo. Para rastrear estos problemas, recomendamos usar algún tipo de rastreador de problemas, ya sea en una acumulación de problemas en GitHub, Jira, etc. o usando un rastreador de problemas de deuda tecnológica especialmente diseñado como Numero de pie .

Algunos de los inconvenientes de este enfoque son:

• Las estimaciones de tiempo vinculadas a problemas específicos pueden ser inexactas
• Algunos problemas pueden pasar desapercibidos fácilmente durante un largo período de tiempo

Medición basada en la calidad

Hay una variedad de métricas de calidad de código que puede usar para tener una idea general del estado de su base de código y, a su vez, obtener una estimación de cuánta deuda técnica tiene actualmente que impacta el desarrollo futuro en cada área. En Sourcery, tendemos a mirar Complejidad , memoria de trabajo y Longitud del método como las métricas críticas al mirar dentro de una función o clase, pero también puede mirar cosas como el Índice de mantenibilidad, la Cobertura de documentos y pruebas, la Tasa de duplicación y muchos otros.

De manera similar al enfoque basado en problemas, puede asignar un impacto relativo de diferentes puntajes (o de un puntaje general de calidad o estado) a la desaceleración actual y futura en el desarrollo debido a la deuda técnica. La investigación ha demostrado una fuerte correlación negativa entre cosas como Complejidad y Velocidad, así como con la calidad del código y el riesgo de errores, la carga de mantenimiento y más.

Mirando un ejemplo, revisemos el código base simple de 4 partes que vimos en la sección sobre Medición basada en la velocidad.

Podemos ver fácilmente las secciones problemáticas de este proyecto en la tabla (resaltadas en rojo) y calcular la estimación de interés es relativamente sencillo: simplemente sume los impactos de interés de los diferentes componentes.

Algunos de los inconvenientes de este enfoque son:

• Debe definir estimaciones de impacto de interés en diferentes métricas de calidad (estoy buscando reunir algunas como línea de base, pero dependerá bastante de la base de código). Para hacer esto, probablemente querrá ver alguna medida basada en la velocidad y relacionarla con la calidad.
• Las métricas de calidad en sí mismas son imperfectas y pueden varían significativamente de un idioma a otro .

Este enfoque de medición basado en la calidad es el menos preciso de los tres enfoques que hemos analizado, pero es muy efectivo para brindar una visión holística de las diferentes áreas de su proyecto a lo largo del tiempo. Puede combinar este enfoque con el enfoque basado en problemas que acabamos de discutir para equilibrar el seguimiento de problemas específicos junto con el seguimiento de problemas generales de calidad y salud en cada sección de su proyecto.

Mirando la frecuencia de interacción de Codebase

Para estos tres enfoques necesitamos tener una forma de mapear el impacto en diferentes secciones de nuestra base de código contra la frecuencia con la que realmente tocamos esa sección de la base de código. Si hay una sección de nuestro proyecto con la que lidiar es una pesadilla pero que nadie toca nunca más, entonces en realidad no está afectando mucho nuestra deuda técnica en curso. Por el contrario, una ralentización pequeña pero persistente en una sección de la base de código a la que se contribuye todos los días puede provocar grandes pérdidas de tiempo muy rápidamente.

Para dar cuenta de esto, tendremos que ver con qué frecuencia se contribuye a cada área de nuestro proyecto. Hay algunos enfoques diferentes que podemos tomar aquí: mirar el historial de Git para comprender qué área se toca con más frecuencia, usando herramientas más enfocadas como Código de escena para obtener datos de contribuciones históricas más digeribles, o utilizar un enfoque prospectivo al observar nuestros próximos planes y prioridades para comprender dónde pasará la mayor parte de su tiempo nuestro equipo durante los próximos meses.

Independientemente de cómo obtengamos los datos, podemos obtener un desglose del porcentaje de nuestro tiempo que pasaremos interactuando con cada sección de nuestra base de código. Combinando esto junto con la contribución de Interés que ya hemos determinado, ahora podemos ver exactamente cuánto esperamos que se ralenticen al tratar con cada sección de nuestra base de código en el futuro.

Continuando con nuestro ejemplo anterior, si tuviéramos una vista orientada hacia el futuro y nuevos todos los proyectos en los que íbamos a trabajar en los próximos 3 meses y pudiéramos estimar con confianza que esta fue la cantidad de tiempo invertido en cada área de la base de código ( recuerda que este es un proyecto muy simple):

Ahora podemos relacionar eso con las estimaciones de interés que teníamos de nuestro enfoque basado en la velocidad y nuestro enfoque basado en la métrica de calidad y tener una buena idea de dónde estamos siendo más lentos.

Aquí estamos usando las desaceleraciones en la velocidad que vimos para el trabajo en las secciones B y C de cuando observamos la medición basada en la velocidad anteriormente y lo estamos usando para calcular cuánto tiempo perdido esperamos debido a la deuda tecnológica en los próximos tres meses. En general, esperamos ver más de 28 meses de esfuerzo adicional por parte del desarrollador para gastar solo en la deuda. Una cosa importante a considerar desde este enfoque es que todo esto está mirando a la velocidad relativa, por lo que los proyectos de referencia se tratan como si no tuvieran deuda, lo que normalmente no es exacto. El otro problema con este enfoque es que no tiene en cuenta las variaciones en los niveles de deuda futuros, que es probable que ocurran. Pero son difíciles de predecir, por lo que es más fácil ignorarlos.

Aquí hemos tomado nuestros retrasos típicos proyectados en función de la calidad del código de cada sección y los proyectamos durante los próximos tres meses. En general, vemos proyecciones de impacto de deuda significativamente más bajas que cuando usamos el método de velocidad. Esto se debe a que las estimaciones de desaceleración basadas en la deuda tecnológica son más bajas de lo que estábamos viendo en el caso de la velocidad; ¡es posible que tengamos que calibrar un poco más en este caso! Al igual que con la métrica basada en la velocidad, esto no tiene en cuenta los cambios futuros en la deuda tecnológica, pero ambas estimaciones pueden ayudarnos a determinar cómo debemos priorizar la reescritura y la refactorización de las diferentes secciones de nuestro proyecto.

Gestión de intereses y deudas

Hemos analizado algunas formas diferentes de dar cuenta de cuánto nos está afectando nuestra deuda técnica de manera continua, pero no hemos respondido completamente la pregunta de cuál es un nivel saludable de deuda técnica.

Desafortunadamente, no hay realmente un número preciso. En el corto plazo, aceptar algo de deuda puede ser pragmático. Pero, a la larga, desearemos intentar mantener nuestra deuda cerca de cero. Porque el interés persistente resultará muy costoso y la deuda tecnológica se sigue acumulando. Pero no queremos gastar todo nuestro tiempo refactorizando y reescribiendo problemas que solo nos dan ganancias marginales.

Como discutimos anteriormente, generalmente no queremos perder tiempo abordando áreas de la base de código donde:

Pero, en el caso extremo de esto, podríamos terminar con un caso en el que nos veamos frenados masivamente por un alto nivel de deuda que es extremadamente costoso de arreglar, lo cual tampoco es una buena situación.

El mejor enfoque es caer en algún lugar en el medio. Reserve tiempo en su planificación continua para abordar los problemas técnicos de la deuda y refactorizar el código existente, priorizando según lo que actualmente le resulte más costoso. Y continúe empujando eso hasta que vea rendimientos decrecientes significativos al reducir su deuda.