No fear, mercilessly…

Deuda técnica

Todos los proyectos de software en los que he estado, tienen deuda técnica. Si nunca has escuchado de ella, Martin Fowler la describe más o menos así:

Tienes una funcionalidad que necesita ser agregada a tu sistema. Y puedes ver dos formas de hacerlo, una es rápida pero sucia — sabes que en el futuro tendrás que hacer cambios más difíciles para limpiarla. La otra resulta de un buen diseño pero tardará más tiempo implementarla.
La deuda técnica es una bella metáfora desarrollada por Ward Cunningham para ayudarnos a pensar acerca de este problema. En la metáfora hacer cosas de la forma rápida y sucia crea deuda técnica, que es similar a una deuda financiera. Como en una deuda financiera, la deuda técnica crea intereses, que son los esfuerzos adicionales que tendremos que hacer en el futuro por el rápido y sucio diseño que se escogió, podemos escoger pagar solo los intereses, o podemos pagar la deuda principal haciendo un rediseño.

La deuda técnica es como pedir un crédito con intereses en el código.

Aunque es más costoso pagar la deuda principal, se gana al tener menos intereses en el futuro. La metáfora también explica por qué puede ser más sensato el enfoque rápido y sucio. Del mismo modo que una empresa incurre en alguna deuda para aprovechar una oportunidad de mercado, los desarrolladores pueden incurrir deuda técnica para golpear una fecha límite importante.

Ganas terminar rápido para cumplir con una fecha de entrega pero con el costo de volver difíciles los cambios en el futuro (también está el desorden total que es un despilfarro donde no ganas nada).

La deuda técnica surge cuando tienes proyectos o requerimientos que eran “para ayer”.

Un problema muy común es que las organizaciones permiten que su deuda técnica salga de control y gasten la mayor parte del tiempo y esfuerzo de sus desarrolladores solo para pagar los intereses paralizantes.

En mi equipo actual, después de profundo análisis, hemos dicho que no podemos cumplir la fecha de entrega en algunos requerimientos, en estos casos los nuevos requerimientos involucran cambios en componentes usados en muchas partes de la aplicación, esto es deuda técnica y también pasa en otros proyectos:

Deuda técnica retrasando solicitudes http://goo.gl/RK7Qa5

La deuda técnica es ausencia de calidad. Cuando acumulas deuda técnica, haces que los cambios futuros sean complicados, y por lo tanto tardados; afecta en tus estimaciones y en tu ánimo al modificar código existente. Los intereses paralizantes reducen tu velocidad, te hacen miserable, rompen con el flujo de trabajo y quebrantan tu voluntad de vivir.

La deuda técnica genera miedo.

El miedo es el camino hacia el lado oscuro. El miedo lleva a la ira, la ira lleva al odio, el odio lleva al sufrimiento. — Yoda

Y hay proyectos que nadie quiere, que todos temen, proyectos donde solo hay sufrimiento.

Soluciones a la deuda técnica

El tío Bob sugiere, tener un capataz (como en las construcciones) o un coach (como en equipos deportivos), alguien que se encargue de que las cosas se hacen, se hacen bien, en tiempo.

¿Pero qué pasa si el número de desarrolladores que mantienen un código crece de veinte a cien? Una sola persona no podría revisar el trabajo de todos y la deuda técnica tomada por unos veinte desarrolladores se irá acumulando y afectará a todos cuando sean cien.

Peter Siebel, actualmente dirige el grupo "Engineering Effectiveness" en Twitter menciona:

Mi sueño para EE en Twitter es establecer un ejercito asesino de código sucio. Tendrá que estar conformado por personas con experiencia con las habilidades y herramientas para tomar una sección del código y adentrarse en ella, y hacer tanto el código como las personas trabajando en él mejores.

Ambas soluciones requieren personas que enfrenten la deuda técnica sin miedo, sin piedad.

Una base para poder hacer cambios con la confianza de no afectar nada más de la aplicación, son las pruebas.

No solo las pruebas unitarias son útiles, para probar flujos de usuario las pruebas automatizadas son de mucha ayuda.

Aunque ande en valle de sombra de muerte, no temeré mal alguno . — Salmos 23:4

Así que si programas, toma la confianza, escribe prueba unitarias, pierde el miedo y haz refactors sin piedad.

No debo temer. El miedo es el asesino de la mente. El miedo es la pequeña muerte que conduce a la destrucción total. Me enfrentaré a mi miedo. Voy a permitir que pase sobre mí y a través de mí. Y cuando se ha ido más allá voy a girar la vista para ver su paso. Donde el miedo se ha ido no habrá nada. Sólo yo me quedaré. ― Frank Herbert, Dune

Raúl Vázquez, Java Developer @Nearsoft