Limpieza de código

Uso de técnicas Agile para pagar la deuda técnica

David Laribee

En todo código base, existen rincones desconocidos y callejones oscuros. Código que es extremadamente frágil, que genera errores de regresión, que si se intenta comprender, puede llegar a enloquecer.

Ward Cunningham creó una excelente metáfora para este código difícil de cambiar y propenso al error al asociarlo con la deuda financiera. La deuda técnica impide progresar, obtener ganancias, cancelar las deudas. Como en el mundo real, existe una deuda barata, una deuda con un interés inferior al que se puede obtener con un instrumento financiero de bajo riesgo. Y también existe una deuda cara; los cargos de tarjetas de crédito con intereses altos que acumulan aún más deudas.

La deuda técnica es realmente tediosa. Puede terminar con la productividad, convirtiendo el mantenimiento en una tarea molesta, difícil y, en algunos casos, imposible. Más allá del problema económico, existe un costo psicológico real en la deuda técnica. A ningún desarrollador le agrada sentarse en su equipo por la mañana sabiendo que se encontrará con código fuente complicado y totalmente frágil. La frustración e incapacidad generadas son normalmente la causa principal de problemas más sistémicos, como la rotación de desarrolladores; uno de los costos económicos reales de la deuda técnica.

Cada código base en el que he trabajado o que he revisado contiene cierto grado de deuda técnica. Una clase de deuda es casi inofensiva: dependencias bizantinas entre tipos extrañamente denominados en recesos del sistema estables y rara vez modificados. Otro es el código desprolijo, que se soluciona fácilmente sobre la marcha, pero que generalmente se omite porque se da prioridad a otros problemas. Hay muchos más ejemplos. 

En este artículo se detalla un flujo de trabajo y diversas tácticas para afrontar la deuda con altos intereses. Los procesos y las prácticas que detallo no son nuevos. Los he tomado directamente de las estrategias Lean/Agile.

¿Se debe pagar la deuda?

En mi libro ni siquiera se cuestiona si la deuda debe pagarse. Por supuesto que se debe. La deuda técnica no juega a su favor, ya que no permite evolucionar a través del tiempo. Existe una reconocida forma de visualización denominada curva de costo de cambio (consulte la Figura 1), que muestra la diferencia entre un enfoque orientado completamente hacia la calidad y el enfoque simplista de “cortar y pegar”.

Figura 1 Curva de costo de cambio

La curva de costo de cambio demuestra que los diseños de alta calidad, simples y fáciles de seguir pueden costar más al principio, pero representarán una deuda técnica inferior más adelante; las modificaciones y las adiciones que deban hacerse posteriormente al código serán menos costosas. En la curva de calidad (azul), podrá observar que el costo inicial es superior, pero con el tiempo se vuelve previsible. La curva rápida (roja) muestra un costo inferior al principio, pero con el tiempo el desarrollo, mantenimiento y costo total de propiedad de un producto y su código se hacen más costosos.

La Ley fundamental de programación de Ward Cunningham (c2.com/cgi-bin/wiki?FirstLawOfProgramming) indica: “reducir la calidad, incrementa el tiempo de desarrollo.”

“Desarrollar un software de calidad toma muy poco tiempo. Si el código es sencillo, las pruebas son completas y el diseño se adapta correctamente, las adiciones y cambios se realizan rápidamente ya que el impacto es mínimo. Por lo tanto, cuanto más se altera el código, menos se avanza, ya que el costo de las adiciones o los cambios crece con cada línea del mismo”.

En otras palabras, la deuda técnica disminuirá el rendimiento del equipo con el tiempo.

Una de las mayores satisfacciones en el desarrollo de software es disfrutar de la producción en sí. El sentimiento de competencia y las discrepancias, al menos para mí, son muy tediosas. Me genera un gran malestar no sentirme productivo, me quita la posibilidad de rendir más, y añoro las "buenas épocas en el trabajo". Existen muchos factores que generan disgustos en el desarrollo de software, pero ninguno tan obvio como un código base rígido y caótico. Este efecto psicológico afecta la moral del equipo y, a su vez, ocasiona una disminución de la producción.

Pensamiento sistemático

Para poder pagar una deuda técnica, es necesario que los participantes y compañeros de equipo estén de acuerdo. Para esto, es necesario comenzar a pensar en forma sistemática. El pensamiento sistemático es un pensamiento muy amplio. Es pensar en invertir. Es la idea de pensar que el esfuerzo realizado hoy, permitirá progresar a un ritmo previsible y continuo en el futuro.

Tal vez, sea más sencillo explicar el pensamiento sistemático con una analogía. Yo vivo en el centro de Atlanta, Georgia, en un pintoresco vecindario llamado Inman Park. Realmente, me gusta mucho vivir allí. Sin embargo, me molesta bastante la falta de criterio y la ignorancia con respecto a la planificación urbana. Las calles en Atlanta son bizantinas, laberínticas y desordenadas. Si se pierde en una de ellas, no podrá retroceder. Si lo hace, se encontrará en una ruta en espiral que lo llevará a un lugar incierto. Es casi imposible comprender la organización y planeación de las rutas de esta hermosa ciudad.

Comparemos esto con las ordenadas calles y avenidas de Manhattan, en la ciudad de Nueva York (bueno, la mayoría de ellas). Es como si la ciudad hubiese sido diseñada por el cuerpo de Infantería de Marina. Las avenidas se extienden a lo largo de toda la isla, de norte a sur, y las calles forman marcadores latitudinales, organizados en toda su longitud. Es más, las calles y avenidas están organizadas en secuencias numéricas: Primera Avenida, Segunda Avenida, Calle 42, Calle 43, y así sucesivamente. Sería casi imposible caminar más de una cuadra en la dirección equivocada.

¿Cuáles son las principales causas de las diferencias entre las ciudades de Atlanta y Nueva York en esta comparación de dimensiones?

En Atlanta las calles fueron formadas por los senderos que dejaba marcados el ganado. Sí, así es, rutas formadas por el ganado. Con el tiempo, se incrementó la necesidad de desplazarse entre el centro urbano y el barrio periférico, y fue entonces cuando un vaquero pensó: "¿No sería más fácil convertir estos senderos que formó el ganado en calles?"

La legislatura del estado de Nueva York aplicó su visión y previsión en el diseño de la ciudad más grande del estado y en constante crecimiento. Se eligió el plan en forma de cuadrícula, con calles y avenidas ordenadas y previsibles. Se pensó con visión de futuro.

Esta historia muestra la esencia del pensamiento sistemático. Mientras los procesos legislativos son lentos, la inversión en tiempo y compromiso con una visión de futuro representa la continuidad de un sistema a través del tiempo. Seguramente, se encontrará con policías terribles en las calles de Manhattan, pero encontrará su camino en cuestión de días. En Atlanta, hace un año que me pierdo, y todos los días agradezco a aquellos que pensaron y crearon el Sistema de posicionamiento global (GPS).

Productos y proyectos

La idea de tener un equipo de desarrollo que realiza un proyecto y luego se lo transfiere al equipo de mantenimiento para que se haga cargo, es completamente errónea. No cometa errores, está trabajando en un producto, y si resulta exitoso, existirá durante mucho, mucho tiempo.

Si ha trabajado como desarrollador profesional un par de años, probablemente habrá vivido el efecto cada vez mayor de gravedad. Desarrolla un software que no está destinado a perdurar, a ser complicado o a cambiar. Y seis meses después, ¿qué está haciendo? ¿Modificándolo? ¿Ampliándolo? ¿Corrigiendo errores?

El software útil a veces tiene el mal hábito de quedarse durante mucho tiempo. Depende de usted tomar la metáfora que desee adoptar. Cuidará de un bosque de hermosos robles de California, organismos vivientes que soportan el paso del tiempo y que buscan crecer y crecer, o permitirá que la implacable enredadera kudzú le quite luz al bosque?

Flujo de trabajo básico

En este punto, espero haber sido claro y que haya comprendido que una deuda técnica afectará tanto su salud mental como a los resultados finales del cliente. También espero que reconozca la necesidad de adoptar una visión más amplia en los productos que cree.

Ahora analicemos cómo se puede superar esta situación.

Independientemente de la actividad, creo que el flujo de trabajo básico para enfrentar una deuda técnica, de hecho cualquier tipo de mejora, es el mismo. Fundamentalmente, lo que desea es:

1. Identificar dónde está la deuda. Saber en qué medida cada aspecto de la deuda está afectando los resultados finales de la compañía y la productividad del equipo.
2. Crear un modelo de negocio y crear conciencia sobre las prioridades en aquellos involucrados en la deuda; tanto el equipo como los participantes.
3. Pagar la deuda identificada con tácticas comprobadas.
4. Repetir. Vuelva al paso 1 para identificar si existe una deuda adicional y mantener la línea de las mejoras realizadas.

Vale la pena mencionar, para aquellos entendidos en el proceso de software, que este flujo de trabajo es una adaptación del enfoque de administración de empresas denominado Theory of Constraints (ToC, Teoría de restricciones) creado por Eliyahu Goldratt (goldrattconsulting.com). ToC es un modelo de pensamiento sistemático que ofrece un marco de trabajo para mejorar el rendimiento general del sistema. La idea general que plantea la teoría es que un sistema (por ejemplo, una planta de fabricación) es tan productivo como su mayor cuello de botella. El valor, como una solicitud de característica o un automóvil o cualquier producto comerciable, se concibe, se diseña, se produce y se implementa. Una característica puede ser solicitada por un cliente, interno o externo, y dicha característica fluye a través del negocio (el sistema), transformándose de una idea a resultado tangible. ¿Qué ocurre cuando estas características se acumulan en el equipo de control de calidad? ¿Qué ocurre cuando la demanda de desarrollo es superior a la que el equipo de desarrollo puede cumplir? Se produce un cuello de botella y el sistema se ralentiza.

Probablemente tendrá muchas áreas de deuda, cuellos de botella, en el código base. Hallar la deuda que más ralentiza el sistema permitirá, principalmente, incrementar el rendimiento. Comprender, enfrentar la deuda e implementar mejoras como equipo, como un sistema, será la manera más eficaz de realizar cambios positivos, porque cuantas más personas intervengan en el código, menos riesgos y mejores diseños se lograrán.

Identificar las áreas de deuda

Es importante que pueda identificar las áreas problemáticas. Si no ha realizado un seguimiento de las mismas en un wiki, una lista compartida o en comentarios de código, la primera tarea es hallar la deuda.

Si trabaja en equipo, sugiero organizar una reunión para desarrollar una lista concreta de las principales áreas de deuda en su código. No es primordial una lista exhaustiva. Concéntrese en los aspectos principales. Esta reunión es la primera oportunidad, como líder de equipo, de comenzar a crear consenso. La mayoría de los miembros deben estar de acuerdo en un aspecto y comprenderlo para que sea parte de la lista.

Una vez realizada la lista, deberá perdurar. Cree un tema en wiki, escríbalo en la pizarra (y que diga “NO BORRAR” resaltado en una esquina) o lo que crea conveniente en su situación. El medio que elija debe ser visible, permanente y fácil de usar. Debe estar a la vista habitualmente. Deberá volver a esta lista y pulirla. Los seres humanos tenemos una memoria a corto plazo muy limitada, por lo tanto sugiero conservar una lista que incluya entre cinco y nueve aspectos trascendentales. No se preocupe demasiado por mantener un inventario; los elementos importantes surgirán nuevamente si realmente lo son.

Uso de las métricas para hallar áreas problemáticas

A veces es difícil hallar una deuda, principalmente, si el equipo es nuevo con código base. En los casos en que no hay memoria colectiva o una tradición oral en que basarse, es posible utilizar una herramienta como NDepend (ndepend.com) para comprobar el código de los aspectos más problemáticos.

Las herramientas son asistenciales o incluso una segunda opción. Las herramientas no indicarán lo que se debe hacer. No obstante, brindarán una perspectiva para tomar decisiones. No existe una métrica para la deuda de código, pero aquellas personas que trabajan en un producto día tras día seguramente podrán abordar esas esquinas oscuras que ocasionan los principales problemas. Las herramientas de análisis estático indicarán dónde se encuentra la deuda de implementación. Lamentablemente, no se indicará dónde está la deuda debido a factores como nomenclatura no adecuada, capacidad de detección, rendimiento y otras consideraciones relacionadas con la calidad de diseño y la arquitectura.

Conocer la cobertura de las pruebas (si tiene pruebas) puede ser otra herramienta valiosa para encontrar la deuda oculta. Obviamente, si hay una gran parte del sistema que carece de una cobertura de pruebas sólidas, ¿cómo podrá estar seguro de que no habrá efectos drásticos en la calidad del próximo lanzamiento? Probablemente, aparezcan errores de regresión que crearán cuellos de botella en control de calidad y derivarán en posibles situaciones embarazosas y pérdida de ingresos debido a los defectos hallados por el cliente.

Utilice la característica de registro de tu sistema de control de versión para generar informes de los cambios realizados en los últimos dos meses. Busque las partes del sistema en donde haya mayor actividad, cambios o adiciones, y examínelos para saber si existe deuda técnica. Esto ayudará a encontrar los principales cuellos de botella presentes; no tiene mucho sentido solucionar una deuda en aquellas partes que rara vez cambian.

Cuellos de botella humanos

Probablemente exista un cuello de botella si hay un solo desarrollador capaz de encargarse de un componente, subsistema o de la aplicación completa. La propiedad individual del código y los silos de conocimiento (donde “Dave trabaja en el módulo Cuentas por cobrar”, ahora hay un recuerdo doloroso) pueden bloquear la entrega si esa persona deja el equipo y tiene mucho trabajo acumulado. Hallar partes del proyecto donde existe propiedad individual permitirá considerar los beneficios y el alcance de mejorar el diseño para que otros puedan compartir la tarea. Elimine el cuello de botella.

Existen grandes beneficios que derivan la práctica de propiedad colectiva eXtreme Programming (programación extrema) (extremeprogramming.org/rules/collective.html). Con la propiedad colectiva, cualquier desarrollador del equipo puede cambiar códigos en el código base para “añadir funcionalidad, arreglar errores, refactorizar o mejorar el diseño. No se produce un cuello de botella debido a que hay sólo una persona para realizar los cambios.”

¡Ah! Otra vez esa palabra, “cuello de botella”. Al implementar la propiedad colectiva, se eliminan las partes oscuras del sistema que sólo un programador, que puede dejar el empleo o ausentarse del trabajo, conoce. Existe menos riesgo con un código base de propiedad colectiva.

Según mi experiencia, el diseño también es mucho mejor. Dos, tres o cuatro cabezas seguramente son mucho mejores que una sola. En un código base de propiedad colectiva, surge una cultura de diseño en equipo que reemplaza las idiosincrasias y peculiaridades individuales.

Yo llamo a la propiedad de código colectiva una práctica, pero en realidad es una propiedad emergente de un equipo que funciona bien. Piense en esto ¿cuántos de ustedes aparecen y trabajan en “su código” frente al código compartido por todo un equipo? Lo que generalmente se denominan equipos en el desarrollo de software son en realidad grupos de trabajo con un editor de asignación, donde las tareas de programación se reparten según quién haya trabajado en una característica, subsistema o módulo específico anteriormente.

Dar prioridad al equipo

Como he mencionado antes, es importante hacer participar a todo el equipo en los esfuerzos para mejorar. Como instructor de Agile, creo en el siguiente mantra “Las personas apoyan aquello que ayudan a crear”. Si no cuenta con un gran apoyo y respaldo, será muy difícil poder fomentar una cultura de mejora continua y mucho más poder sostenerla.

La clave es lograr consenso. Desea que la mayoría de los miembros del equipo apoyen la iniciativa de mejora actual que ha seleccionado. He utilizado con éxito el enfoque de Luke Hohmann “Buy a Feature” (Compre una característica) de su libro Innovation Games (Jugando con la innovación) (innovationgames.com). Intentaré explicar brevemente el juego y recomendar que lea el libro si considera que podría funcionar en su entorno.

1. Genere un lista breve (5 a 9 aspectos) de cosas que desea mejorar. Idealmente, estos aspectos son cambios a corto plazo.
2. Califica los aspectos en términos de dificultad. A mí me gusta utilizar la abstracción del tamaño de una camiseta: pequeña, mediana, grande, muy grande (consulte la barra lateral Cálculo de oportunidades de mejora, para obtener más información sobre esta práctica).
3. Asigna a tus características un precio en base a su tamaño. Por ejemplo, los elementos pequeños pueden costar $50, los medianos $100, y así sucesivamente.
4. Entregue a todos cierta cantidad de dinero. La clave aquí radica en implementar la escasez en el juego. Desea que los participantes inviertan su dinero en un fondo común para adquirir las características que les interesan. Debe poner un precio a las características comunes que los participantes en forma individual no puedan comprar. Es fundamental observar las situaciones en que más de un individuo detecta la prioridad sobre la que se está intentando crear consenso.
5. Organice un juego breve, unos 20 ó 30 minutos, donde los participantes puedan debatir, ponerse de acuerdo y defender su caso. Esto puede ser un poco caótico y a la vez divertido, y verá qué factores influyen en tu equipo.
6. Analice los elementos que fueron comprados y en qué márgenes. Puede clasificar la lista según las características compradas o, mejor aún, utilizar los resultados del juego “Buy a Feature” en combinación con otras técnicas, como el conocimiento del plan del próximo lanzamiento.

Cálculo de oportunidades de mejora

He mencionado cómo calcular los aspectos de una deuda o las oportunidades de mejora en términos de los tamaños de una camiseta. Ésta es una técnica muy común utilizada en metodologías de desarrollo Agile. La idea es que recopile artículos en términos de tamaño relativo. Los pequeños se agrupan al igual que los medianos, los grandes y así sucesivamente.

Aquí, no es esencial ser totalmente preciso. Recuerde: estas son mediciones relativas, no compromisos. Obtendrá una idea aproximada de la dificultad; la teoría indica que luego de calcular determinados aspectos, las cosas comiencen a nivelarse. Aunque un elemento mediano le tome dos semanas a un par de desarrolladores para completarse y a otro un mes, en promedio uno mediano tomará tres semanas.

Con el tiempo, sin embargo, comenzará a reunir ejemplos que servirán para saber bien cuál es un elemento grande y cuál es uno pequeño, lo que ayudará en cálculos futuros ya que contará con una base de comparación. En el pasado, he utilizado diversos ejemplos de los diferentes tamaños como recurso para calcular un lote nuevo de trabajo.

Esta puede ser una excelente solución para la administración. Inicialmente, desearán saber con exactitud cuánto tiempo tomará algo y, para ser sincero, es posible que necesite invertir más tiempo en un cálculo preciso según el tiempo.

Vender el plan

Ahora que tiene un plan, es hora de comunicar el valor de eliminar la deuda a los patrocinadores del proyecto. En los hechos, este paso puede darse en paralelo con la identificación. Haga participar al cliente desde el comienzo. Después de todo, el desarrollo del plan requerirá tiempo, esfuerzo y (finalmente) dinero. Desea evitar, a toda costa, preguntas sobre cómo y cuánto invirtió en desarrollar un plan coherente.

Cualquier esfuerzo satisfactorio y sostenido para eliminar una gran parte de deuda requiere el apoyo absoluto de los patrocinadores y expertos financieros del proyecto. La persona que firma un cheque debe comprender la inversión que está realizando. Este puede ser todo un desafío; le pide a las personas que piensen a largo plazo, en el futuro, y que dejen atrás la mentalidad de compre ahora, pague mañana. La explicación de “porque sí” simplemente no sirve.

El problema es que los ejecutivos inevitablemente preguntarán: “¿Pero no son profesionales?” Y tal vez se sienta entre la espada y la pared. Después de todo ¿no les están pagando a ustedes, los profesionales, para entregar un producto de calidad en tiempo y forma?

Este es un argumento muy contundente como para oponerse. Pero no se preocupe. Tenga el coraje y la valentía de presentar los hechos tal cual son. Este enfoque aparentemente riesgoso se resume en problemas comunes sobre responsabilidad y confianza.

Defienda su argumento de la siguiente forma: ha producido un software exitoso en el tiempo solicitado por cierta cantidad de dinero. Para poder lograrlo tuvo que buscar un punto de acuerdo durante todo el proceso para responder a las presiones del negocio. Ahora, para avanzar de manera previsible y estable, debe afrontar los efectos de este acuerdo. Toda la organización lo ha comprado, y ahora es momento de devolverlo.

Su próximo desafío es demostrar a aquellos no entendidos en el tema dónde está causando el principal daño la deuda técnica. Según mi experiencia, los ejecutivos del negocio responden a argumentos cuantitativos basados en datos respaldados por “números” y “hechos”. Y coloco números y hechos entre comillas porque todos sabemos que vivimos en un mundo relativo y que un simple número (complejidad ciclomática, acoplamiento eferente, líneas de código, cobertura de pruebas y otros por el estilo) no puede vender un cambio. Sintetizando esta dificultad, deberá comunicar las áreas de mayor complejidad en términos económicos: ¿por qué es más lento de lo que le gustaría? ¿por qué esta característica cuesta tanto?

Evidence DEFEATS Doubt (Las pruebas VENCEN a la duda)

Para fortalecer su caso, existe una herramienta muy útil del sistema de aprendizaje en administración de Dale Carnegie que se resume en una frase: “las pruebas vencen a la duda”. Como es común en tales sistemas de administración (y en nuestra disciplina en general), la parte de DEFEATS (vence) es un acrónimo. Detallaré algunas de las formas en las cuales esto se aplica al desarrollo de software. Sin embargo, tenga en cuenta que he omitido la segunda E (de la palabra DEFEAT del inglés) que representa Exhibit (exhibir) porque repite la primera E, que representa Example (ejemplo).

La D es para Demonstration (demostración). No existe nada mejor que mostrar y contar; de esto se trata la demostración. Si realiza un seguimiento de la velocidad, esto será fácil. Muestre un descenso a través del tiempo (consulte la Figura 2) y asócielo al código difícil de cambiar y cada vez más inflexible. Una vez que venda, debe continuar haciéndolo.

Figura 2 Seguimiento de la velocidad de desarrollo

Si utiliza un proceso Agile como Scrum o eXtreme Programming, los comentarios del cliente son una práctica esencial. Al final de una iteración, demuestre las características nuevas al cliente. Si bien la calidad y cantidad de las características disminuirán cuando el marcado de informes de tiempo de actividad y ausencia de la deuda técnica descienda y se incrementen sus esfuerzos de mejora, deberá ser capaz de demostrar las ganancias a través del tiempo. Menor deuda significa mayores resultados y mayores resultados significan más para demostrar.

Como dice el refrán: “Antes de criticar a alguien, camine una milla en sus zapatos”. Si tiene un gerente más técnico, sugiérale que trabaje con desarrolladores en algunas de las secciones más complicadas del código base para que pueda acostumbrarse a la dificultad del cambio. Pídale que observe códigos. ¿Puede seguirlo? ¿Es legible? Es la manera más rápida de llegar a la meta.

La E es para Example (ejemplo). No hay nada como un ejemplo concreto. Busque proyectos o requisitos que sean imposibles de concretar debido a la deuda técnica o porque generaran una regresión significativa. Tome una sección del código que sea ilegible, bizantina, y que esté plagada de efectos secundarios. Explique cómo estos atributos del código generaron un defecto hallado por el cliente o la necesidad de incrementar los controles de calidad.

Otra herramienta eficaz que brindan los procesos Agile es la retrospectiva. Busque un proyecto que haya empeorado en las últimas iteraciones y pregunte ¿por qué? Busque la causa principal por la cual este proyecto en especial no se pudo concretar, tomó el doble de tiempo o abarcó más de una iteración. Por lo general, la causa es el software inflexible o tal vez deba revertir los cambios porque los errores de regresión eran insuperables. Si el último "por qué" termina siendo un aspecto relacionado con una deuda técnica, tome el análisis de manera breve y directa. Será otro punto más a su favor en el argumento.

La F es para Fact (hechos). Los hechos son muy fáciles de demostrar. ¿Entregó un proyecto a tiempo? ¿Cuál fue el índice de defectos posterior al lanzamiento? ¿Cuál es la velocidad promedio del equipo? ¿El cliente quedó satisfecho con el software entregado? Estos son los hechos que deseará demostrar, y creo que son estos hechos los que hablan por sí solos.

La colaboración es un elemento clave en este punto. Como desarrollador, está preparado para proporcionar hechos técnicos. Solicite ayuda de las personas que se encargaron de los presupuestos. Seguramente, ellos tendrán una visión mucho más clara y podrán obtener acceso con mayor facilidad a los hechos del negocio que demuestran el daño que la deuda técnica está ocasionando.

La A es para Analogy (analogía). Creo que esto es primordial. Los empleados empresariales a veces ven el desarrollo de software muy confuso, incluso esotérico. Si habla con sus patrocinadores de acoplamiento, cohesión y sobre el Principio de responsabilidad única, tendrá muchas posibilidades de perderlos. Pero estos son conceptos importantes en el desarrollo de software profesional y, en última instancia, cómo se genera un caso basado en datos para enfrentar una deuda. Yo sugiero evitar los tecnicismos y explicarlo con una analogía.

Podría describir el acoplamiento como una casa de cartas por ejemplo. Explique a sus patrocinadores que la razón por la cual la velocidad ha descendido es porque hacer cambios en el código es como agregar una pared, el techo o una planta a una casa de cartas establecida y muy elaborada: una operación quirúrgica que requiere una mano absolutamente firme, mucho tiempo y paciencia y que es, en última instancia, un hecho incierto que genera gran ansiedad. A veces la casa de cartas colapsa.

Al emplear metáforas y similitudes, es buena idea aclarar que lo está haciendo. Justifique la analogía con una breve descripción del concepto más técnico que intenta transmitir. Al usar el ejemplo de la casa de cartas, puede explicar que “este es el efecto que tiene el acoplamiento sobre nuestra capacidad para responder al cambio y agregar nuevas características”.

La T es para Testimonial (testimonios). A veces, escuchar el mismo mensaje de un tercero tiene un mayor efecto. Un tercero puede ser un líder de la industria o un consultor. La razón por la que su palabra tiene más efecto que la suya es que son considerados expertos objetivos.

Si no dispone del dinero necesario para contratar a un consultor externo, recopile anécdotas y comentarios disponibles de manera gratuita de líderes de la industria. Mientras que es muy poco probable que los testimonios genéricos sobre las mejores prácticas cierren el trato, agregarán más a la Gestalt del argumento general.

La S es para Statistics (estadísticas). Los números importan. Existe una frase muy común en administración: “si no se puede medir, no se puede administrar”. No estoy seguro de si esto se aplica por completo, pero ciertamente podrá presentar pruebas. Acoplamiento y complejidad son dos métricas que pueden utilizarse para demostrar la relación principal entre una disminución del rendimiento (la cantidad de trabajo realizado) y un código base cada vez más colmado de deuda.

Creo que las estadísticas compuestas son la mejor opción en este caso; es mucho más sencillo comprender la importancia de la cobertura de código si se superpone una métrica de cobertura de código a través del tiempo con una disminución en la velocidad, lo cual implicaría, o en todo caso demostraría, una relación.

Asignar un líder

Los esfuerzos para reparar la deuda técnica llegarán más lejos con un líder eficaz, alguien que pueda comunicarse en términos comerciales y que tenga influencia en aquellas personas que toman las decisiones en la organización. Generalmente, será un gerente, director, el CTO, el vicepresidente de ingeniería o alguien con un cargo similar de autoridad.

Esto plantea el problema del huevo o la gallina. ¿Cómo convence a esta persona? El proceso de “gerencia ascendente” también es responsabilidad del desarrollador. Su primer desafío es convencer al vendedor. ¿Cómo se hace exactamente? ¡Las pruebas VENCEN a la duda!

Pasos siguientes

Hasta ahora he indicado cómo identificar la deuda como equipo y generar un caso para repararla. Reiteraré: el consenso en el equipo y un acuerdo con los clientes son factores clave en estos pasos.

Comience a trabajar gradualmente y no invierta mucho tiempo. La primera vez que identifique una deuda, tomará más tiempo que cuando realice una iteración sobre nuevas oportunidades de mejora, pero cuando genere el caso de administración, sólo incluya aquellos aspectos sobre los que planea trabajar. Prestar atención a la productividad en forma constante puede ahorrar muchas energías.

En el próximo artículo abordaré el resto del flujo de trabajo, incluyendo tácticas para eliminar la deuda, y cómo se puede hacer el proceso iterativo, tomando los conocimientos aprendidos de esfuerzos para eliminar deudas.

Dave Laribee es instructor del equipo de desarrollo de productos en VersionOne. Participa con frecuencia en eventos locales y nacionales para desarrolladores y fue galardonado MVP de arquitectura de Microsoft en 2007 y 2008. Escribe en el blog CodeBetter en thebeelog.com.

Gracias a los siguientes expertos técnicos por su ayuda en la revisión de este artículo: Donald Belcham