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 
), 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.
Creo que se ve claro que, programar rápido no significa hacerlo bien, en la mayoría de los casos, es raro hacerlo rápido y bien. Por otro lado, lo que puede haber funcionado (incluso de milagro) en una ocasión, si necesita mejoras o cambios, puede dejar de funcionar, teniendo que invertir mucho más tiempo del que habría costado hacerlo bien desde el principio.
¿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 de cualquier índole que no se han tenido en cuenta, o simplemente, por la rapidez, se han cometido.
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, pero el de mantenimiento es nulo o muy, muy pequeño. Por lo que, a la larga (o al medio plazo) compensa.
Loading ...