Deuda técnica: definición y ejemplo

¿Qué es la deuda técnica?

Imagine que desea reemplazar su vieja y lenta computadora portátil por una nueva que cuesta $ 1200. A menos que ya tenga el dinero ahorrado, se enfrenta a una elección entre dos escenarios: puede comenzar a ahorrar $ 100 mensuales hasta que tenga suficiente dinero para comprar la computadora portátil en un año, o puede pedir prestado dinero y comprar la computadora portátil hoy. Si bien la segunda solución es más rápida, también le costará más, ya que tendrá que pagar el interés mensual además de pagar la deuda en sí; con un pago mensual de $ 100 y un interés del 10%, sus costos totales sumarán aproximadamente $ 1415. de $ 1200. Si la segunda solución vale los $ 215 adicionales generalmente depende de la urgencia con la que necesite una nueva computadora portátil. A menudo,

La deuda técnica es una metáfora inventada por Ward Cunningham, uno de los autores del Manifiesto Ágil, para describir lo que ocurre cuando el equipo de desarrollo utiliza una solución rápida a corto plazo que requerirá trabajo de desarrollo adicional más adelante en lugar de elegir la mejor solución posible que requiere más tiempo de desarrollo ahora. Al hacerlo, el equipo está tomando tiempo prestado del futuro para lanzar el producto más rápidamente ahora.

La implementación de una solución rápida a corto plazo plantea la necesidad de refactorizar en el futuro. La refactorización se refiere al proceso de mejorar el código de software existente. El tiempo futuro que se dedicará a la refactorización se considera el pago de intereses de la deuda existente, que se cancela en su totalidad solo una vez que el software se actualiza a la mejor solución posible.

Cuando se usa con moderación, la deuda técnica puede ayudar a la organización a dar vida a sus proyectos más rápidamente. A veces, esto vale la pena: cumplir con los plazos, aprovechar el momento adecuado en el mercado o mantenerse al tanto de la competencia. Sin embargo, el equipo de desarrollo debe evitar depender de la deuda técnica con demasiada frecuencia, ya que creará más obligaciones futuras de refactorización de las que el equipo puede manejar, al igual que uno no debe pedir prestado más dinero del que puede pagar mensualmente. El equipo también debe asegurarse de asignar el tiempo suficiente para pagar la deuda técnica en el futuro.

Ejemplo

Para ayudarlo a visualizar una situación en la que la organización puede utilizar la deuda técnica, imagine que está en TI en Tall Oak Toys y está trabajando para hacer un mejor uso de las métricas de desempeño de su marca. Su equipo necesita escribir una función que pueda crear informes de desempeño mensuales para el equipo de ventas, utilizando la información de las dos bases de datos existentes.

La primera solución es introducir una función de informes que se alimenta de bases de datos independientes. Esto es rápido y económico de desarrollar. Sin embargo, no es la solución de codificación más elegante, ya que el programa necesitará realizar consultas en múltiples bases de datos. Esto ralentiza la ejecución del código y la generación de un informe tarda un poco más.

La segunda solución es primero consolidar las dos bases de datos en una y luego desarrollar una función de informes que se alimenta de una nueva base de datos consolidada. Si bien esta solución dará como resultado una generación de informes más rápida, llevará más tiempo desarrollarla y será más costosa. Sin embargo, también facilitará la introducción de nuevos indicadores de rendimiento en el futuro.

La decisión final de Tall Oak dependerá de la urgencia del proyecto y de la calidad de las herramientas de informes disponibles actualmente para el equipo de ventas. En el caso de que no exista una fuente alternativa de datos de rendimiento de fácil acceso, se preferirá la solución rápida, ya que permitirá al departamento tomar decisiones más informadas antes. En el escenario donde ya existen algunos informes y la organización planea introducir nuevos indicadores de desempeño, la segunda opción será más atractiva.

Resumen de la lección

La deuda técnica se acumula cuando el equipo de desarrollo utiliza una solución rápida a corto plazo que requerirá trabajo de desarrollo adicional más adelante en lugar de elegir la mejor solución posible que requiere un tiempo de desarrollo más largo ahora. La implementación de una solución rápida a corto plazo plantea la necesidad de refactorizar o mejorar el código de software existente en el futuro. La deuda técnica no siempre es mala, pero debe tenerse en cuenta al planificar nuevos proyectos, y debe pagarse regularmente para que no se vuelva abrumadora.