Deuda Técnica: El Precio de nuestras desiciones

En estos tiempos de crisis con una economía acelerada, la mayoría de los productos buscan destacar en el mercado antes que sus competidores, inevitablemente ya sea conscientes o inconscientes toman decisiones apresuradas que impactan el futuro del proyecto y de quienes trabajan en él, la famosa deuda técnica, el precio inherente en el código y su arquitectura.

En mi opinion Deuda técnica (Technical debt) solo es una forma de referirnos al tiempo que nos ahorramos en el presente que pagaremos en el futuro, son aspecto en el desarrollo realizado de forma no óptima, que requiere pequeños ajustes a lo largo del proyecto haciendo más difícil seguir con su implementación ya sea por decisiones individuales o del equipo donde anteponemos la velocidad respecto a la flexibilidad y/o calidad, eventualmente nos irán retrasando poco a poco hasta el punto de que peligre el producto o incluso la estabilidad de la empresa donde trabajamos.

Pero no solo se trata de decisiones en el código, existen varias formas de endeudarnos las cuales yo las agruparía en 3 categorías:

1. En el código

Todos hemos experimentado con código que nos tomó más tiempo entenderlo que la solución misma, métodos con multitud de condicionales, comentarios desactualizados, patrones de diseño mal implementados, y un sin fin de cosas que hacen más difícil leer la solución, esto sin lugar a duda nos retrasada en tiempo y es un tipo de deuda técnica, las más visible. Se dice por cada línea de código que escribamos nos tomará al menos 10 veces ese tiempo entenderla, así que invertir tiempo en la claridad de nuestro código nos ayudará cuando tengamos que modificarlo. Ten en mente que el dejar tu solución lo más simple posible y con una clara intención es siempre mejor a utilizar hacks que tarde o temprano se interpondrán en nuestro camino.

También código sin pruebas es otro tipo de deuda técnica, sin importar la razón ya sea por tiempo, por desconocimiento o por la complejidad del código, el hecho de que no esté probado te obligará a invertir tiempo en asegurarte que tus cambios no rompan lo anterior, si no podemos saber rápidamente cuando nuestro código afecta funcionalidad existente perderemos tiempo, y sin el contexto de la solución anterior también existe la posibilidad de introducir más bugs, volviéndonos temerosos a realizar cambios, dejando de refactorizar y olvidando que tenemos una deuda. Sin embargo esto es fácil de solucionar, y muchas veces nos ayuda a confirmar lo bien diseñado que está nuestra solución ya que si es fácil de probar será fácil de entender, invierte tiempo en asegurarte que tu código funciona hoy y lo seguirá haciendo mañana.

2. De conocimiento

No todas las arquitecturas funcionan para los mismos propósitos, en algunos casos una arquitectura incorrecta o mal implementada nos trae dolores de cabeza, complicando el desarrollo incluso terminando con algo híbrido que pierde todas las ventajas de haberla usado desde el inicio. Cosas como utilizar el nuevo patrón de diseño de moda sin entenderlo, implementar una arquitectura sin conocer lo requerimientos e incluso forzarla a que encaje, son algunos ejemplos que encontrarás en esta categoría, siempre cuestionate si lo que vas hacer es necesario o simple capricho, si puedes postergar su implementación a un punto donde tengas un mejor contexto y conocimiento de las necesidades, posiblemente te darás cuenta que no era tan necesaria o cambiaras de opinion sobre que solución utilizar.

De igual forma hay ocasiones donde no conoces completamente la aplicación, y agregar funcionalidad que ya existe, haciendo que dos diferentes soluciones funcionen al mismo tiempo complicando la lógica, esto sucede por la dificultad de leer el código, una documentación desactualizada, o a veces simplemente porque el autor de la otra funcionalidad no está disponible, haciendo que dupliquen esfuerzos, perdiendo el tiempo al desarrollarlo y tiempo después cuando sea necesario modificarlo. Si esa persona hubiera programado de una forma más sencilla y con una clara intención, seria una mejor forma de conocer el código y evitar este tipo de problema.

3. Con la Tecnología

Por último, la industria se mueve muy rápido y hace cambios abruptos, un día Adobe Flash era el futuro al siguiente dejó de existir, volteando al pasado al primer proyecto en el que participaste, como crees que le fue con el paso del tiempo?, probablemente cualquier intento para hacerlo resistente al tiempo se volvió en contra de la aplicación, esto a menudo sucede porque lo que pensábamos sería el futuro muy probablemente no lo fue y ahora estamos atrapados en una solución obsoleta o una arquitectura que no puede crecer. Siempre es mejor ser flexible a intentar adivinar el futuro, cuando tengas que tomar una decisión sobre qué tecnología usar hazlo de forma modular donde puedas cambiarla de ser necesario por algo diferente y donde la aplicación no se vea afectada.

En conclusión

No hay forma de salvarnos de introducir deuda técnica, ya sea por una buena razón o no, consciente o inconscientemente eventualmente pagaremos un precio. Pero no la malinterpretes, como su analogía financiera la deuda técnica es una forma de obtener algo a cambio de algo más, puedes hacer un uso de ella como una herramienta para alcanzar tu objetivo de forma más rápida, y la mejor defensa es el saber su existencia, entenderla para usarla a nuestro favor, tratar de medirla e identificarla antes de que sea muy tarde y sobre todo como developer saber comunicarla. La deuda técnica no es propia de una sola persona, y no solo afecta a los desarrolladores, no debemos menospreciarla y tratemos de trabajar en equipo para disminuir sus efectos y maximizar los beneficios a corto plazo que nos da.



Adrian Castillo

Adrian Castillo


comments powered by Disqus

Siguenos

Boletí de noticias