He iniciado una nueva etapa en el blog, pensando en aquellas personas que no logran aún manejarse muy bien con el inglés, puesto que se están perdiendo de grandes fuentes de información que algunas veces solo publican en dicho idioma. La nueva etapa consiste en publicar semanalmente algún artículo que me haya parecido interesante y que se encuentre en dicho idioma, así más personas tendrán acceso a esa información. En esta oportunidad he decido traducir una de las entradas en el blog de Martin Fowler, un reconocido autor en el mundo de la ingeniería de software, en esta entrada el tema central es el concepto de Deuda Técnica. La traducción no es completamente textual, ya que, he decidido introducir cierta visión personal para dar claridad en algunos puntos. Sin más preámbulo, les comparto el texto.


Piensa que tienes una nueva funcionalidad que necesitas agregar a tu sistema, ves dos formas hacerlo, la primera es rápida pero desordenada o confusa –estás seguro que hará las cosas más difíciles de modificar en el futuro. La otra forma resulta en un diseño más limpio, pero tomará algo más tiempo para ubicar dentro del sistema.

Deuda Técnica es una gran metáfora propuesta por Ward Cunningham para ayudarnos a reflexionar sobre este problema. En esta metáfora, hacer las cosas de la forma rápida y “sucia” te  encamina hacia una deuda técnica, que es un concepto similar a una deuda financiera. Al igual que una deuda financiera, en la deuda técnica se incurre en el pago de intereses, que se manifiestan en forma de un esfuerzo adicional que debemos realizar en el desarrollo futuro de los sistemas debido a la elección del diseño rápido y no tan limpio. Podemos elegir continuar pagando el interés, o podemos pagar el capital principal por medio de la refactorización de ese diseño rápido y confuso para obtener un mejor diseño. Aunque también hay un costo al pagar el capital principal, en general ganamos al reducir el pago de intereses en el futuro.

La metáfora también explica por qué puede ser sensato o razonable decantarse por el enfoque rápido y no tan claro. Así como una empresa puede incurrir en una deuda para tomar ventaja de una oportunidad de mercado, los programadores pueden incurrir en deuda técnica para cumplir con una fecha límite (deadline) importante. El problema más común es que las organizaciones de desarrollo de software dejan que sus deudas técnicas se salgan de control, y, terminan invirtiendo la mayoría de su esfuerzo pagando intereses que paralizan la productividad en el desarrollo futuro de los sistemas.

Lo complicado de la deuda técnica, por supuesto, es que a diferencia de la deuda financiera, es imposible medirla de forma efectiva. El pago de intereses hiere la productividad del equipo, pero como no podemos medir la productividad, no podemos ver realmente el verdadero impacto de nuestra deuda técnica.

Algo que se puede olvidar fácilmente es que solo ganas dinero cuando pagas tus deudas. El costo más grande de la deuda técnica es el hecho de que disminuye tu habilidad para agregar características futuras, y por lo tanto te abre la puerta a la pérdida de ingresos. Además, siguiendo la Hipótesis de Diseño Resistente (Design Stamina Hypothesis de Martin Fowler), debes entregar el sistema antes de llegar al punto de equilibrio del diseño (a nivel de rentabilidad) para tener la oportunidad de lograr una ganancia sobre tu deuda técnica. Sin embargo, suele ocurrir que asumir una deuda técnica te desacelera tanto, que terminas entregando el sistema bastante tarde.

La deuda técnica puede provenir de varias fuentes, algunas pueden ser buenas y otras malas, Martin Fowler utiliza el Cuadrante de Deuda Técnica para describir dichas fuentes.

 

deuda tecnica fuentes
Fuente: Blog de Martin Fowler

Finalmente, como nota personal, debo resaltar que la deuda técnica es una metáfora, es decir, una analogía a la situación real. Lo que sucede muchas veces con las metáforas es que suelen confundirse con aquella situación real y solo hablamos de la metáfora y no de las causas que provocan la situación problemática, sus consecuencias y las acciones que debemos tomar para mitigar su impacto.


Esto ha sido todo por ahora, espero que esta entrada haya resultado útil para ampliar tu punto de vista sobre la metáfora de deuda técnica.

Author: Julio César Echeverri M.

Fuente: Artículo Original de Martin Fowler

Anuncios