La metáfora de la deuda técnica puede ser muy útil. De hecho, Don Jones argumenta de forma convincente lo buena que puede ser la metáfora. Sin embargo, como la mayoría de las metáforas, puede romperse y perder su utilidad. Normalmente se incurre en una deuda cuando se compra algo y no se tiene el dinero (o el deseo) de pagarlo por adelantado. Sabes lo que estás comprando, sabes lo que cuesta y sabes cuánta deuda estás asumiendo. A veces incluso sabes si puedes pagarlo.
La deuda técnica de software, por otro lado, puede parecer el resultado final de planear la compra de una habitación de tres dormitorios en los suburbios pero que termina en Downton Abbey. Claro, usted es dueño de un castillo, pero tiene cientos de años de antigüedad con malas cañerías, cableado eléctrico inadecuado y requiere de todo un personal sólo para mantenerlo limpio y mínimamente funcional. No dejas de pensar, «¿Cómo he llegado hasta aquí?»

Aunque en la superficie esto pueda parecer ridículo, no ocurre ni una sola vez en la vida. Tiene una molesta tendencia a ocurrir una vez en la vida de cada proyecto de software. Las soluciones alternativas, las dependencias y los procesos rotos se consideran una parte de la vida del desarrollo, pero ¿cómo sabes cuando es demasiado para tu equipo? ¿Cuáles son los signos de advertencia de una deuda tecnológica excesiva?
El aspecto más importante de la deuda técnica es reconocer cuando usted y su equipo la están comprando. ¿Pero cómo lo haces? Hay varias señales de advertencia. Pero primero, una historia que puede que conozcas muy bien. Como gerente de desarrollo, típicamente eres parte de esta conversación:
Cliente: «Estamos realmente interesados en ver Whizbang. ¿Puedes hacer que funcione en tres semanas?»
Desarrollador: Bueno, como sabes, Whizbang ni siquiera fue planeado para esta versión. Retrasará nuestra entrega inicial, pero déjame ver si puedo meterlo ahí.»
Cliente: «Genial, sabía que podía contar contigo. Gracias».
El cliente escuchó que el horario se va a resbalar (no dijiste por cuánto). Lo que no se entendió fue que «déjame ver si puedo meterlo ahí» tiene un costo de mantenimiento muy real en curso que llamamos deuda técnica. Aunque a menudo reconocemos el deslizamiento del alcance, y si tenemos suerte de que el programa se haya cumplido, es mucho más difícil reconocer la deuda técnica que se acumuló para acomodar esos cambios.
Esto es lo que sucede a continuación: como director de desarrollo de software, puede que te encuentres al volante de un gran (pronto fuera de control, sin frenos) automóvil que está fuera de la hoja de ruta del proyecto, rápido. Detendrás tu bien planeado y predecible proceso de desarrollo de software. Haces que tu equipo trabaje como loco para que Whizbang funcione en tres semanas. A lo largo del camino tienes que hacer algunos compromisos, seguro. Tu equipo probablemente hace que algunas clases sean accesibles globalmente. Mueven otros métodos a clases a las que no pertenecen.
Tu equipo incluso tiene que dar un giro una o dos veces para evitar las mejores prácticas. Usted está haciendo lo necesario para añadir la funcionalidad de la manera más rápida posible sin tener en cuenta cómo afectará al mantenimiento a largo plazo. Es importante reconocer que mientras se toma aisladamente, cada violación parece ser sólo un pecado venial, pero en conjunto es un asunto mucho más serio. Pero oye, has llevado el coche a su destino, pero ahora es el momento de pisar los frenos y volver a la pista, ¿verdad? Tu plan es pasar las próximas tres o seis semanas arreglando esto y pagando la deuda técnica. Sin embargo, ahora mismo, se siente como una victoria… tú y tu equipo acaban de hacer lo imposible y lo han hecho a tiempo.
El cliente llega y queda impresionado. Antes de que se haga el retroceso, el cliente también menciona que si tu producto también tuviera GollyGee, su negocio sería tuyo. También sucede que regresará en un mes y le encantaría tener la oportunidad de obtener un avance de la función de GollyGee. Más alcance se arrastra y no hay suficiente tiempo para incorporar esos cambios correctamente. Sabes que hay más deuda técnica en camino y sólo puedes pensar en ello: «Dios mío, ¿qué he hecho?»
Sin embargo, vuelves a estar al volante de un automóvil más grande, más rápido y más jugoso, y haces que tu equipo haga lo que sea necesario para que GollyGee se haga cargo de la visita del cliente… y la deuda técnica comienza a acumularse. Esto puede sonar fabricado y poco realista, pero te prometo, aparte de los nombres tontos, que me ha pasado a mí y probablemente a ti y a tu equipo. Si no lo ha hecho, lo hará.
El problema es que desde fuera no parece haber nada malo en el proyecto. Las nuevas características realmente funcionan. Claro, tu equipo perdió una semana rastreando un error cuando añadiste GollyGee porque tenían un conflicto en la nueva clase global que fue muy útil para Whizbang. Sin embargo, una vez que se dieron cuenta de cuál era el problema, simplemente violaron la regla de «No te repitas» y codificaron una solución alternativa. Esa semana perdida, por supuesto, fue un micro pago de los intereses de la deuda. Mientras tanto, todos los demás en el proyecto comenzaron a usar esa clase global tan conveniente también… El proyecto es ahora significativamente más difícil de mantener y hasta que no se arreglen todos los fallos y atajos, va a seguir empeorando… y ahí está, dejando pasar los días.
Una razón por la que nos gusta tanto la metáfora de la deuda técnica es que los problemas de mantenimiento se sienten como un interés compuesto. Por supuesto, en la mayoría de los casos, no sólo no se paga el capital, sino que ni siquiera se hace una mella en el interés. Cuidado con estas señales de advertencia de la deuda técnica:
- Tu equipo empieza a hacer cosas por la cantidad (es decir, entregas rápidas) sobre la calidad.
- El desarrollo del producto se hace cada vez más difícil, y mantenerlo ocupa una cantidad cada vez mayor de recursos de desarrollo
- Tu equipo tiene que encontrar nuevas formas de trabajar en torno a las soluciones rápidas que has puesto en marcha.
- No vuelves a arreglar las soluciones que dijiste que harías.
- Te desvías de la hoja de ruta del proyecto a menudo.
- Tu equipo empieza a incumplir los plazos.
- Empiezan a aparecer más bichos, que son difíciles de descubrir y replicar.
- Sus devs muestran signos de frustración y el código base se está volviendo cada vez más inelegante.
Pasa un tiempo con el curso de Mark Heath «Entendiendo y eliminando la deuda técnica» para tener una visión más completa.
Si has oído que la deuda técnica es buena para un equipo de desarrollo, has oído mal. Si eres un desarrollador de software, no te hablaron. Si eres el dueño del negocio, puede que hayan estado hablando contigo. Asumir la deuda no es el problema. No reconocer, o incluso entender que has asumido la deuda, te va a costar caro. Si no se pone un plan de pago, entonces definitivamente no es lo que cualquiera llamaría una buena deuda.
Estoy seguro de que todos hemos usado productos de software que eran muy molestos. Cada nueva versión parecía traer más problemas que características. Probablemente eran víctimas de una deuda técnica impagada. Tan pronto como tuvimos una alternativa, la abandonamos y nunca miramos atrás. Cuando esa compañía sacaba un nuevo producto, las probabilidades son buenas, ni siquiera las consideramos. Como propietario de un negocio o promotor, es una carta de reclamación que no quieres recibir nunca.
Reconozca que no sólo habrá un golpe de agenda para Whizbang, sino que también reconozca que su equipo incurrirá en alguna deuda técnica que deberá ser pagada oportunamente. Pídele a tu equipo la factura. Parte del trato para que Whizbang se haga en tres semanas es que tú y tu equipo simplemente no saben cuál será esa deuda. No saben qué atajos tendrán que tomar o qué desviaciones harán. Si no quieres asumir ese riesgo, entonces tienes que convencer al cliente de que realmente no quiere Whizbang.
Si optas por Whizbang, una vez que esté hecho, deberías tener una idea bastante buena de lo que se necesitará para pagar la deuda. Probablemente será más alta de lo que pensabas, pero no te quedes corto en esto. Haz que tu equipo haga el recuento de la cuenta y te la presente. Y que sepas que si pides que GollyGee esté listo antes de que se pague Whizbang, no sólo GollyGee se sumará a la deuda, sino que probablemente hará que el costo de Whizbang suba. Y cuando GollyGee esté terminado, tu equipo presentará una nueva factura.
Es mejor planear con antelación y no contraer más deudas de las que puedas pagar a tiempo. Pero cada vez que su equipo termine un cambio ad-hoc o implemente algún elemento de alcance, PÍDALE que estime la deuda técnica no pagada después de que se haya hecho. Si no lo hacen, podrían encontrar que tienen demasiado en común con el protagonista de los Talking Heads. Y en lugar de la habitación de tres pisos, puede que te encuentres viviendo en una choza de escopeta, en otra parte del mundo murmurando, «Lo mismo de siempre… lo mismo de siempre».
Aprenda a hacer que su equipo de desarrollo sea más productivo y eficiente con nuestra guía.
Trae la guía: Los desarrolladores y el aprendizaje permanente: los retos y oportunidades que afectan a tu equipo