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.
Aprende más sobre:
Arte Arquitectura Biologia Ciencia Ciencia Fisica Ciencias de la Tierra Ciencias Sociales Economia Historia Historia Mundial Historia Moderna Medio Ambiente y Ecologia Literatura Plantas y Animales Religiones del Mundo QuimicaArticulos relacionados
- Efectividad de la publicidad generada por el consumidor: pros y contras
- ¿Cual es la diferencia entre un gerente y un líder?
- La regla de Taylor en economía: definición, fórmula y ejemplo
- Problemas derivados de la presentación electrónica de impuestos
- La inmigración en la América industrial y el surgimiento del nativismo
- ¿Qué es la financiación? – Definición y tipos
- Requisitos de presentación de impuestos federales para empleadores »Wiki Ùtil
- Métodos comunes de selección de personal: definiciones, tipos de entrevistas, ventajas y desventajas
- Cómo llevar a cabo la reunión de cierre de una auditoría
- Licencia médica y familiar: legislación y propósito
- Autoridad estatal y local en la regulación del uso de la tierra
- Estudio de movimiento de Frank y Lillian Gilbreth
- Dedicación de la propiedad: definición y requisitos
- ¿Qué es el modelado ágil? – Definición y objetivo principal
- Cómo evitar las trampas de las entrevistas de trabajo