El cuadrante de deuda técnica de Martin Fowler
Sin embargo, podemos tener una visión más empática de la deuda técnica que nos acerca a la realidad. Claro, a veces la deuda técnica surge de un código mal escrito o escrito apresuradamente. También surge de un código perfectamente escrito que simplemente no cumple su función tan bien como antes.
Desde este punto de vista, la deuda tecnológica no es necesariamente culpa de nadie.
«Miramos hacia atrás a la directiva principal de las retrospectivas y no importa lo que pase, todos hicieron lo mejor que pudieron», dice Goulet. «Eso es muy importante porque puede haber mucha vergüenza y culpa cuando se trata de una deuda técnica, y eso es increíblemente tóxico. Se ha convertido en la cultura de la ingeniería».
En cambio, considera que la deuda técnica de sus clientes es un desastre muy exitoso. «Puede que sea un desastre, pero te ha llevado a donde tienes que estar», dice. «Celebremos eso, y podemos mejorarlo y hacerlo más rápido.»
Goulet ha dibujado en otra parte una metáfora diferente para pagar la deuda técnica, es más como una remodelación de su base de código. No importa lo bien que construyas una casa; eventualmente, tendrás que reemplazar el techo. Algunas características pueden no envejecer bien, y decidirás reemplazarlas en el futuro. Eso no significa que el techo original o los electrodomésticos de la cocina sean defectuosos en absoluto. Simplemente estás haciendo el trabajo que tu casa necesita para durar más tiempo. Y lo mismo ocurre con el código base.
«Estamos mejorando todo el tiempo, y reconociendo que eso es asintótico. Nunca alcanzaremos la perfección», dice. «Siempre nos esforzaremos por alcanzar la perfección.»
¿Cómo es la deuda técnica?
Volvamos a la definición anterior de que la deuda técnica es todo lo que crea fricción en el proceso de desarrollo. En ese caso, la deuda técnica puede tomar todo tipo de apariencia en la base de código, incluyendo:
- Donde cortamos esquinas en el pasado para un beneficio más rápido (digamos, para liberar una característica)
- Decisiones que tuvieron sentido en su momento y que ahora deben ser actualizadas
- Áreas de la base de código, dependencias y opciones de operabilidad que resisten el cambio
- Mantenimiento rutinario regular
Automatización y carga cognitiva
Pero la deuda tecnológica también puede tomar otras formas que no están necesariamente ligadas a una línea de código. Por ejemplo, Zuber señala otros puntos de fricción que pueden retrasar a los equipos de desarrollo.
«La ausencia de automatización es una gran cosa», dice. «Cada vez que me despliego y luego tengo que ir a mirarlo en producción para asegurarme de que funcionó, es una pérdida de tiempo, y alguien más que hace un cambio no sabrá que necesitaba mirarlo.»
También señala la carga cognitiva -todo lo que los ingenieros o líderes tienen que llevar en sus cabezas para poder hacer algo de manera efectiva. «La complejidad del código es una gran parte de eso», dice. «Si está demasiado entrelazado, no entiendo los efectos secundarios del cambio que voy a hacer.»
Ausencia de contexto en las prácticas cotidianas
En el mismo sentido, Goulet añade que la ausencia de contexto es una forma de deuda técnica. Ella ramifica esta forma de deuda en dos tipos: migajas de pan y prácticas diarias.
Si un desarrollador necesita sumergirse en una pieza de la base de código, es útil si el código es auto-revelador o si el desarrollador puede hacer referencia a una documentación clara. El código en sí mismo puede ser funcional, pero si carece de comentarios de confirmación u otros rastros del proceso de pensamiento del desarrollador original, entonces un desarrollador posterior no siempre puede comprender fácil y rápidamente el propósito del código. «Es el por qué del sistema», dice Goulet. «Se reduce a las operaciones del desarrollador».
Para las prácticas diarias, hace que sus clientes pregunten: «¿Estoy usando nombres de variables y nombres de funciones claros? ¿Estoy usando el desarrollo dirigido por pruebas de manera que tenga sentido y esté apoyado por la administración? ¿Estoy usando principios de codificación sólidos y sé cuáles son? ¿Sé cómo escribir un código limpio? Todas esas prácticas individuales pueden sumar muy significativamente.»
Factores humanos
Y luego están los factores humanos completamente no técnicos que contribuyen a la deuda técnica. «La mayoría de nosotros trabajamos en equipos multifuncionales bastante pequeños», dice Pasqua. «Y vemos mucha deuda técnica alrededor de nuestros equipos que no pueden actuar de forma autónoma y hacer las cosas bien y rápidamente. Miramos qué cosas se interponen en el camino de nuestros equipos para poder cambiar completamente, poseer, operar y mantener su dominio?»
Por supuesto, es imposible enumerar cada iteración de la deuda técnica. Cada base de código y cada equipo experimentará su propio estilo. Pero si hay que hacer una generalización, Zuber señala que el desafío de la deuda técnica es que sus instancias son a menudo invisibles.
«Probablemente hay cosas que los ingenieros notan primero en sus equipos, pero también hay cosas que son más mortíferas por cada mil cortes de papel», dice. «Para un ingeniero, es este pequeño trozo de gastos generales. Pero si miras desde un nivel ligeramente superior, con suerte tienes el tipo de métrica y datos para poder decir espera un segundo, cada equipo está haciendo esto y lo están haciendo lentamente. Así que como organización, hay una necesidad de invertir».
Cómo priorizar el tratamiento de la deuda técnica
Cualquiera que sea la forma que adopte, la deuda técnica es importante debido a su impacto en el proceso de desarrollo y en la experiencia del usuario. De nuevo, es como un techo envejecido: puede que no lo notes hasta que empiece a gotear. Es importante mantenerse al tanto del mantenimiento de su base de código para que su impacto no comience a costar a su organización de manera significativa (ya sea que se mida en ingresos perdidos, tiempo o compromiso de los empleados).
Impacto de la deuda técnica
Tomando prestado del desarrollador de software y entrenador ágil Declan Whelan, la deuda técnica impacta a los ingenieros, equipos y organizaciones.
Los impactos en los ingenieros individuales incluyen:
- La deuda técnica hace que sea más difícil añadir valor al nuevo software.
- Hace que arreglar los problemas sea más difícil.
- Motivarse para trabajar en el código se convierte en una tarea.
- Otras oportunidades de trabajo empiezan a parecer más atractivas.
- A niveles extremos, los ingenieros pueden contemplar un cambio de carrera.
Los impactos en los equipos incluyen:
- Menor velocidad, y mayor variación de velocidad.
- Más rigidez en la asignación de tareas.
- Menos flujo dentro del equipo.
- Hacer planes fiables se hace más difícil.
- Una vez más, baja la moral y aumenta el volumen de negocios.
Los impactos organizacionales incluyen:
- Reducción del valor de los activos de software.
- Mayor dificultad en la gestión de la cartera de esos activos.
- Reducción del flujo en el flujo de valor del software.
- Una respuesta más lenta y menos fiable a los problemas tanto del cliente como internos.
- Mayor fricción (¡y por lo tanto más deuda técnica!) entre los equipos y grupos.
Por supuesto, no querrás esperar para abordar la deuda técnica hasta que empieces a ver el peor de estos síntomas. Pero no importa qué, ya tienes una deuda técnica. «Teóricamente, en el momento en que envías el código, es una deuda técnica», dice Pasqua, haciéndose eco de un axioma expresado por otros líderes tecnológicos también.
Entonces, ¿cómo puede ser práctico en priorizar la deuda técnica que debe ser abordada mientras que también continuamente se envía nuevo y emocionante valor a los clientes?
Utilizar métricas para cuantificar el impacto empresarial de la deuda técnica
El uso de métricas que indican cuándo y dónde su equipo está siendo frenado por la deuda técnica, y que también le ayudan a reconocer cuando los miembros del equipo están abordando, es una estrategia que tanto Goulet como Pasqua propugnan. Esta información le ayudará a identificar el impacto empresarial de estos problemas y a gestionar las iniciativas de deuda técnica que se están llevando a cabo.
«Mucho de esto se trata de identificar cuál es la deuda tecnológica más útil para nosotros en este momento», dice Pasqua. «Si queremos iterar en una cierta área que creemos que traerá un valor muy alto al negocio y nos ayudará a golpear a nuestra compañía, probablemente sería más impactante para nosotros pagar mucha de la deuda técnica en esa área primero.»
«Nunca tienes tiempo para hacer todas las cosas que quieres hacer», añade, «así que prioriza. No se trata de la peor deuda, sino de cuál es la deuda que sería más impactante abordar primero dado el mapa de ruta y la estrategia de la compañía.»
Hacer de la deuda tecnológica una práctica diaria
Zuber considera el enfoque de un equipo para lo que él llama «trabajo de status quo». La cultura de un equipo en cuanto a las funciones diarias y regulares puede tener un impacto significativo en la deuda técnica de forma continua.
«Pensamos mucho en presupuestar nuestras asignaciones de esfuerzo», explica. «La noción de que el cien por cien del tiempo de mi equipo de ingeniería o del tiempo de cada ingeniero va a ir al desarrollo de características es donde empiezan sus problemas. Ninguno de nosotros es perfecto la primera vez que escribimos algo. Todos sabemos que tan pronto como ponemos algo ahí fuera, va a haber un problema y vamos a tener que ir a arreglarlo. Asignar un presupuesto de manera que un porcentaje de éste se dedique siempre al mantenimiento y a la corrección de errores. Algún porcentaje se dedicará a la deuda y limpieza tecnológica, o a la inversión tecnológica.»
«Deja de pensar en tu software como un proyecto. Empieza a pensar en ello como una casa en la que vivirás durante mucho tiempo.» – Andrea Goulet
Evaluar los ciclos de vida de los productos
Para Goulet, las consideraciones para trabajar en la deuda técnica se reducen al propio ciclo de vida del producto. Esencialmente lleva a cabo un análisis de riesgo tanto para crear como para abordar la deuda técnica
«Si estás iniciando una iniciativa o lanzando algo y no tienes muchos usuarios, el riesgo de probar algo o de acumular la deuda tecnológica es mucho menor», dice. «Pero cuando tienes algo que es un sistema de misión crítica que va a impactar a decenas de miles de usuarios y tu compañía perderá dinero por ello, entonces se vuelve más importante y más crítico. Así que siempre tienes que sopesar los factores de negocio. Eso te ayudará a averiguar si estás invirtiendo o no en una actividad que te va a devolver el dinero, o si vas a prevenir o mitigar los problemas».
En esencia, crear una deuda técnica es inevitable. No puedes evitar encontrarla mientras sigas codificando y creciendo. Pero abordar la deuda técnica no tiene por qué ser a costa de tu progreso futuro. De hecho, si prioriza su deuda por riesgo y recompensa -por qué áreas de la base de código son más críticas o más valiosas para el propósito de su organización- e incorpora ese trabajo de hecho en el procedimiento operativo regular de su equipo, puede comenzar a mejorar la funcionalidad y efectividad de su organización casi inmediatamente.