Imagina que tienes una funcionalidad que necesitas agregar a uno de tus sistemas. Para ello hay inicialmente dos formas de hacerlo, una es rápida de implementar pero algo confusa (es decir, es seguro que esta opción te dará mucho trabajo mejorarlo en un futuro). La otra es hacerlo a partir de un diseño “limpio”, pero esta opción llevará más tiempo y esfuerzo de implementar.
Deuda técnica es una excelente metáfora ideada por Ward Cunningham para ayudarnos a pensar en este problema.
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.”
En esta metáfora, hacerlo de la forma rápida y confusa nos generaría una deuda técnica, con una mecánica similar a la deuda financiera. Al igual que una deuda financiera, la deuda técnica involucra el pago de intereses, que se configuran en forma de esfuerzo extra que tendríamos que realizar en un futuro a causa de haber elegido la opción de un diseño rápido y confuso. Y un principal que representa por el costo de eliminar la deuda técnica de forma definitiva.
Por lo tanto, podríamos optar por continuar pagando intereses u optar por pagar el principal a través de la aplicación de técnicas que nos lleven de un diseño rápido y confuso a uno mejor. A pesar del costo que nos trae el pago del principal, ganaremos a futuro al reducir el pago de intereses.
La idea no es eliminar toda la deuda técnica, sino concentrarse en aquellos casos donde el monto de interés que evitaríamos con la solución justifica el costo que tiene el pago del principal. De acuerdo con esto hay casos donde optar por un enfoque rápido y confuso puede ser razonable. Por ejemplo, al igual que una empresa incurre en deudas para tomar ventaja en una oportunidad de mercado los desarrolladores podrían considerar incurrir en una deuda técnica para alcanzar un hito importante para los objetivos del proyecto.
La metáfora se vuelve interesante porque generalmente las organizaciones productoras de software dejan que sus deudas técnicas se salgan de control y esto hace que pasen la mayor parte del esfuerzo futuro del desarrollo pagando intereses paralizantes. El tema es también que a diferencia de la deuda financiera, la deuda técnica no cuenta con una moneda que nos permita medirla de forma efectiva. Los pagos de interés por ejemplo deberían medirse en términos de la productividad del equipo, pero como medir la productividad es un tema complejo y pese a nuestros esfuerzos tal vez no consigamos medirla con exactitud, no podremos evaluar el efecto real de nuestra deuda técnica.
En resumen esta metáfora si bien es un concepto que no es nuevo, ejemplifica un problema que continua siendo interesante para los investigadores actuales. Distintos autores han tomado esta metáfora y la han extendido a diferentes áreas de la ingeniería de software particularmente a la vertical de calidad imagino que se debe a que es el área más difícil de evaluar cuantitativamente.
No hay comentarios:
Publicar un comentario
Si quieres puedes aportar a este post con tus comentarios, así podemos enriquecer juntos la temática. Gracias!