Actuar con prudencia : Como manejar la deuda técnica dentro de los proyectos informáticos — Parte 1

Contra la incertidumbre, prudencia, pero ¿En que grado y medida?

Como ingenieros de software, siempre tenemos que tomar decisiones en base a las etapas del ciclo del desarrollo de software, las cuales se discuten como se deben llevar a cabo en un cierto contexto que tiene una variable que afecta a todo el proyecto : El tiempo de desarrollo. Es por lo anterior que a la hora de desarrollar una funcionalidad se debe considerar realizarla con la mejor calidad posible(buenas prácticas de código, pruebas unitarias, entre otras), pero como la empresa quiere lograr valor y retorno de la inversiòn lo mas pronto posible se entra en una disyuntiva : ¿Cómo avanzamos sin perder calidad en lo que entregamos a nuestros clientes?. Aquí es donde aparece la llamada Deuda Técnica.

Definamos deuda técnica según nos dice IONOS

Con deuda técnica, se definen los errores, carencias y deficiencias deliberadas o involuntarias en el código que se generan por falta de comunicación, dirección de equipo, cualificación o publicación apresurada de productos y que aumentan constantemente debido a la falta de refactorización.

Dado la definición anterior es que debemos ser conscientes a la hora de recurrir a ella. Si bien nos entrega beneficios a la hora de liberar un producto antes de tiempo que tu competidor directo, se debe tener bien trazada el como a futuro se pagara esa deuda técnica. Te dejo un ejemplo de cómo Seb Rose(https://www.oreilly.com/library/view/97-things-every/9780596809515/ch01.html) explica la deuda técnica con un ejemplo práctica de la vida cotidiana :

La deuda técnica es como un préstamo: te beneficias de él a corto plazo, pero tienes que pagar intereses hasta que esté totalmente pagado. Los accesos directos en el código dificultan agregar funciones o refactorizar su código. Son caldo de cultivo para defectos y casos de prueba frágiles. Cuanto más lo dejas, peor se pone. En el momento en que emprenda la solución original, puede haber una gran cantidad de opciones de diseño no del todo correctas superpuestas al problema original, lo que hace que el código sea mucho más difícil de refactorizar y corregir. De hecho, a menudo es sólo cuando las cosas se han puesto tan mal que debe solucionar el problema original, que realmente regresa para solucionarlo. Y para entonces, a menudo es tan difícil de arreglar que realmente no puede permitirse el tiempo o el riesgo.

En conclusión lo que nos dice Seb es SIEMPRE debes tener seguimiento de esa deuda técnica para que no tengamos problemas a futuro tratando de resolverla sabiendo que será muy tarde.

Aplaza tus deudas y veras las consecuencias

Por eso Ingeniero de Software, siempre actúa con prudencia, se consciente de cómo las decisiones que vas tomando para dar forma a tu aplicación pueden impactar de manera negativa en un futuro. Pero, si tienes la manera de ir manejando la deuda técnica que vas generando y lograr invertir el tiempo en el corto plazo para solucionarla, ten por seguro que podrás cumplir con las expectativas del negocio e ir realizando las mejoras a tus funcionalidades para que tengan el grado de calidad esperada.

En el siguiente post (https://medium.com/@oleon.icci/actuar-con-prudencia-como-manejar-la-deuda-t%C3%A9cnica-dentro-de-los-proyectos-inform%C3%A1ticos-parte-2-4425adbb9e45)esta la siguiente parte del articulo donde se hablara de los siguientes puntos :

• ¿Cómo impacta la deuda técnica en el tiempo?
• Ejemplos y casos donde se expone la deuda técnica
• Estrategias para manejar la deuda técnica