Para los que no están al tanto, la deuda técnica es una metáfora de la deuda en la que se incurre al avanzar en el desarrollo de manera quick and dirty, sin prestar la debida atención a la calidad del código. Esta deuda, como la financiera, tiene intereses que se irán acumulando y que finalmente terminaremos pagando de una u otra manera. La deuda se puede ir cancelando, por ejemplo con refactoring que aunque puede costar un esfuerzo extra sirve para recortar el pago de grandes intereses en un futuro.
La semana pasada en un thread de la lista de agile-spain: Quien deberia pagar la deuda ? el usuario Ángel Medinilla escribió una GRAN verdad:
Lo que no es planteable en software es decir "Ups. cometisteis un error. Os toca venir el fin de semana a arreglarlo, ya que yo no os pago por solucionar errores". En software se cometen errores. Punto. Si la tasa de errores es demasiado elevada, o se piden overtimes y se quema al equipo o se va invirtiendo poco a poco en mejorar la tasa, tanto a priori como a posteriori. La vía de Agile es la segunda. Las consultoras no opinan lo mismo :_D
Me gusta tanto que me voy a imprimir en una remera (camiseta) la frase:
En software se cometen errores. Punto.
¿Quién no ha recorrido alguna vez (sino muchas) los interminables caminos de la primera vía?
