¿Qué es el Technical Debt?

Tech Debt, Technical Debt o Deuda técnica es un concepto en desarrollo de software que refleja el costo de rehacer las cosas causado por elegir una solución que se cree es más “fácil” o “rápida” en lugar de resolver los problemas usando la mejor solución que podamos implementar en ese momento.

También se llama Deuda porque funciona de la misma forma que una deuda financiera, en el sentido de que puede ser útil para comprar una casa que no puedes comprar con efectivo pero esa compra genera intereses. Muchos intereses pueden arruinar tu economía e incluso hacerte perder la misma casa. Las deudas pueden ser usadas a nuestro favor si pagamos los intereses correctamente.

Algunos consejos siguiendo la analogía:

• No adquieras deudas que no puedas pagar.
• Paga tus deudas temprano y continuamente.
• No te endeudes por cosas innecesarias.

Hay muchas formas de acumular Deuda Técnica, he aquí algunos ejemplos comunes:

• “No hay tiempo” para hacer algo de la manera correcta.
• “No tenemos los recursos” para hacer algo de la manera correcta.
• No tenemos el conocimiento para hacer algo de la manera correcta.
• No queremos hacer algo de la manera correcta.
• No tenemos la autoridad para hacer algo de la manera correcta.
• La deuda técnica anterior hace más difícil el hacer algo de la manera correcta.
• Situaciones fuera de nuestro control.

Veamos los puntos anteriores uno por uno.

• “No hay tiempo” para hacer algo de la manera correcta.
  Esto es falso en el 99% de las veces. Lo que pasa es que no sabemos cuánto tardaríamos en hacer el feature bien hecho y asumimos al azar que debe tardar más que un feature mal hecho. En mi experiencia podría decir que en la mayoría de los casos, un senior developer puede hacer un feature bien hecho en la mitad del tiempo o menos que un junior developer aún cuando el junior developer lo haga mal hecho (y no, no estoy implicando que un developer junior va a escribir mal código necesariamente, es sólo un ejemplo).

• “No tenemos los recursos” para hacer algo de la manera correcta.
  Si los recursos se refieren al tiempo entonces aplica lo del párrafo anterior. Si los recursos se refieren al dinero podría ser una razón entendible. Uno podría no tener los suficientes recursos para contratar personas con experiencia y atenerse a las capacidades de las personas que sí logres contratar. Acá la deuda técnica puede mitigarse de varias formas como capacitar a las personas, motivarlas a que aprendan cosas nuevas, conseguir mentores, contratar a unas pocas personas con experiencia que ayuden a los demás a crecer profesionalmente, etc.
• No tenemos el conocimiento para hacer algo de la manera correcta.
  Esta es entendible en el presente pero de igual forma todos deberíamos buscar cómo capacitarnos para aprender las cosas que no sabemos hoy.
• No queremos hacer algo de la manera correcta.
  Esta es inexcusable, la gente que piensa y trabaja de esta manera no debería ser parte de ninguna empresa de tecnología y mucho menos de Beek.

• No tenemos la autoridad para hacer algo de la manera correcta.
  Debemos tratar de explicar a la gente que sí tiene la autoridad la importancia de reducir y/o no generar deuda técnica. Lo más probable es que si nos sabemos explicar, nos ayudarán a hacer las cosas bien. En caso de que no lo logremos debemos intentar y seguir intentando. Si al final no hay forma de que la gente en el liderazgo entienda que eso es un problema y no tienen una razón válida para no atacar la deuda técnica, quizá sea el momento de buscar otra empresa porque el liderazgo está roto y es parte del problema.
• La deuda técnica anterior hace más difícil el hacer algo de la manera correcta.
  Esto se puede evitar si generamos la menor deuda técnica posible y si pagamos poco a poco la deuda técnica existente.

• Situaciones fuera de nuestro control.
  Hay pocas veces en las que, aún haciendo todo bien, vamos a tener que pagar deuda técnica. Alguna librería que usamos ya no recibe mantenimiento y hay que migrar a otra. Salió una nueva versión del framework que usamos y tiene breaking changes, etc. Lo importante acá es no dejar que se acumule.

¿La deuda técnica significa que tengo un mal producto?

Contrario a lo que podría parecer, estas cosas no están relacionadas y es por esto que nacen todos los problemas como los deadlines apresurados, la aceptación de deuda técnica innecesaria, etc.

Un mal código podría tener la suerte suficiente de generar un buen producto, uno que haga lo que debe de hacer hoy (aunque no escale mañana) y un buen código podría implementar una mala visión de producto y no llegar a ningún lado.

Entonces, ¿para qué preocuparse de la deuda técnica?

Bueno, porque nos hace más lentos y menos productivos con el tiempo. Atacar y prevenir la deuda técnica es la respuesta lógica si te interesa gastar menos y generar más valor más rápido como empresa.

La deuda técnica vs Dinero

La deuda técnica vs Tiempo

Ah y por si no fuera poco ser más lentos y perder dinero, ¿qué tal suena perder talento 1?

Ah y recordemos que hay muchísimas empresas que han quebrado por demasiada deuda técnica y solo algunas cuántas han logrado sobrevivir (con la ayuda de mucho dinero). Twitter y LinkedIn sufrieron muchísimo por deuda técnica acumulada y tuvieron que reescribir parte de su codebase.

¿Les suena la empresa llamada Tio Networks (si no les suena de nada ese es exactamente el punto)? ¿Que luego tuvo algunos problemitas de deuda técnica? ¿Y que suspendieron actividades para nunca volver a reanudarlas?

Ok, ok, pero ¿cómo atacamos la deuda técnica?

Eso lo discutiremos en otro post…

Por último, si te interesa todo este tema probablemente te interesará leer este libro: The Clean Coder.