La deuda técnica se puede definir como la suma de las consecuencias de desarrollar software de baja calidad, sin seguir estándares, ni patrones, ni buenas prácticas. Esta deuda se va acumulando con el tiempo, haciendo difícil mantener el software, ya que cada vez cuesta mas implementar nuevas funcionalidades sobre una base de código de baja calidad. J. Reuben Clark escribió lo siguiente sobre el interés:
“Interest never sleeps nor sickens nor dies; it never goes to the hospital; it works on Sundays and holidays; it never takes a vacation; it never visits nor travels; it takes no pleasure; it is never laid off work nor discharged from employment; it never works on reduced hours. . . . Once in debt, interest is your companion every minute of the day and night; you cannot shun it or slip away from it; you cannot dismiss it; it yields neither to entreaties, demands, or orders; and whenever you get in its way or cross its course or fail to meet its demands, it crushes you.”
Relacionando esta frase con la deuda técnica, cada vez que uno tiene que trabajar sobre código pobremente desarrollado, siente el peso o el interés de la deuda técnica. Esto se da porque que se tarda mucho más en integrar el nuevo código, surgen muchos más errores y realmente es frustrante para el desarrollador construir sobre cimientos de baja calidad. En el siguiente gráfico podemos ver cuán difícil se va tornando agregar nuevas funcionalidades en código con alta deuda técnica y como se va sumando el interés de la deuda a medida que pasa el tiempo:
Las causas principales que favorecen el acumulamiento de deuda técnica son:
- Presión del negocio (fechas)
- Desarrolladores con poca experiencia o falta de educación
- Incompetencia
- Procesos pobres
- Inexistencia de unit tests
- Inexistencia de revision de código
- Falta de colaboración
Muchas veces se nos asigna a proyectos donde tenemos que hacer mantenimiento sobre código que no hicimos nosotros y no tiene un buen nivel de calidad. Para ir disminuyendo la deuda técnica, se debe ir refactorizando el código mientras vamos agregando nuevas funcionalidades o resolviendo bugs, mejorando de a poco el código. Al comienzo vamos a tardar más para entregar estos cambios o arreglos, pero en el futuro esto nos va a hacer ahorrar tiempo, esto es el concepto que hay que vender al negocio.
Los project managers debemos trabajar junto a los desarrolladores, para que nos den herramientas para explicar al negocio este fenómeno y defender el buen desarrollo de software, para hacerles ahorrar tiempo, dinero y frustraciones a todos en el futuro.
