¿Qué tipo de errores o fallas de diseño deberían considerarse como deuda técnica?
Un desorden en el código no es una deuda técnica, su argumento es que el código desordenado producido por personas que ignoran los patrones y buenas prácticas de diseño no debería considerarse como una deuda.
La deuda técnica debería reservarse para las malas decisiones, aquellas que se tomaron para adoptar una estrategia de diseño que no es sostenible a largo plazo pero que produce un beneficio a corto plazo (como salir rápido a producción). El problema con las malas decisiones es que como todo en la vida no son gratis, puede que den valor en un momento, pero seguro tendrán que pagarse lo antes posible. En mi opinión preguntarse si un error en el diseño es o no una deuda técnica es una pregunta equivocada desde su concepción.
El término deuda técnica es una metáfora, así que la pregunta apropiada debería ser si la metáfora es útil para lidiar con los problemas de diseño. Creo que la metáfora de la deuda técnica funciona bien en cuatro casos; con las deudas prudentes e imprudentes y las deudas deliberadas e inadvertidas
La deuda imprudente es la que se traduce en pago de intereses agobiantes o en periodos largos de amortización de capital (p. ej. cuando el equipo tiene que estar trabajando 24/7 para corregir los “bugs”) y en ese orden de ideas la metáfora nos recuerda que a veces no vale la pena pagar la deuda si el pago a los intereses es lo suficientemente pequeño (p. ej. si se trata de una parte del código que rara vez se modifica). La distinción útil no es preguntarse si la falla en el diseño es una deuda técnica o no, sino, si la deuda es prudente o imprudente.
Hay otra distinción interesante entre las deudas técnicas; las deudas deliberadas y las deudas inadvertidas. El ejemplo de la deuda prudente deliberada es porque el equipo sabe que está asumiendo una deuda y por lo tanto debió reflexionar sobre si la recompensa al despliegue obligado a producción era mayor al costo de liberar código con fallas en su diseño. Por otro lado, en una deuda inadvertida, el equipo ignorante de buenas prácticas de diseño, ni se da cuenta en lo que se están metiendo.
Las deudas deliberadas pueden ser temerarias en situaciones en las que el equipo dev, decide ir rápido y sucio, porque piensa que no puede permitirse el tiempo necesario para escribir código limpio.
Existe una deuda que sea prudente e inadvertida aunque parezca extraño, creo que sí y no solo es común sino inevitable en equipos con excelentes diseñadores. Hace poco hablaba con un colega sobre un proyecto que justo él terminaba, entregaron un software valioso, el cliente estaba contento y el código estaba limpio… pero no estaba satisfecho con el código que había liberado, sentía que el equipo había hecho un excelente trabajo, pero ahora se daba cuenta de lo que debería haber sido el diseño.
Oigo esto todo el tiempo de los mejores desarrolladores de software, hay un problema con la deuda prudente e inadvertida y es que es difícil de explicar en una junta directiva, pero hay algo cierto y es que la deuda técnica es inevitable, incluso en los mejores equipos tendrán una deuda a la que hacer frente a medida que avanza el proyecto, razón de más para no cargar al equipo imprudentemente con código de mala calidad.
