Deuda técnica

Mi amigo Guillermo me remitió un email hace poco en el que detallaba un concepto que ya conocía hace tiempo, pero que no había visto tan bien explicado hasta el momento (sí, tenía que haber leído antes a Cunningham :-P ), el tema era: La deuda técnica en scrum, en un resumen de cómo lo enunció Ward Cunningham:

Hacer código de mala calidad a toda prisa, es como pedir un crédito: puede que obtengamos un beneficio a corto plazo pero si tenemos que seguir desarrollando ese código, tarde o temprano tendremos que pagar todo el tiempo que nos habíamos ahorrado y los intereses. Refactorizar código mal escrito es siempre más difícil que escribirlo bien desde el principio.

Quien es desarrollador desde hace tiempo esto lo sabe. Lo conoce. Programar rápido no significa hacerlo bien. En la mayoría de los casos suele ser al contrario. El código escrito a la ligera es difícil y muchas veces imposible de hacer crecer. Algo que en principio funcionaba puede dejar de funcionar agregando una nueva característica y sin haber modificado nada referente a esa funcionalidad.

¿Hacerlo bien significa gastar muchas más horas? No realmente. Si llevásemos un cómputo de las horas invertidas en hacer un proyecto de forma rápida, a priori, podría parecer que se han invertido pocas horas y el trabajo está “hecho”. El problema viene después cuando toca corregir los errores.

Normalmente, las horas invertidas en mantenimiento, superan con creces las horas invertidas en un desarrollo basura. La comparación con el haberlo hecho bien es que el tiempo de desarrollo planificado crece siendo el de mantenimiento nulo o muy, muy pequeño. A la larga (o al medio plazo) compensa.