Como acumular deuda tecnica rapidamente

Leyendo el post de Mario Chavez: Lo importante es que funcione, inmediatamente me recordo la metafora inventada por Ward Cunningham "Deuda tecnica", la cual es descrita en su primer parrafo por Martin Fowler como:

Necesitas agregar una pieza de funcionalidad al sistema. Identificas 2 maneras de hacerlo, una es rapida, pero sucia, y sabes que te hara la vida mas dificil en el futuro. La otra resulta en un diseño limpio, pero te tomaria mas implementarla.

Hay muchos factores por los cuales creo que la mayoria de los desarrolladores escogen la primera ruta de sacarlo rapido, y "despues lo arreglo"; por supuesto que ya sabemos que el luego nunca llega, y a eso es precisamente a lo que se le denomina la deuda tecnica; vamos dejando las cosas para despues, y los sistemas se van enredando mas, el codigo se vuelve mas complejo, y al hacer cambios muchas veces se introducen nuevos errores, por la naturaleza misma de un codigo mal estructurado.

Esta deuda, como tal, se tiene que pagar de alguna manera, y mientras no se pague en su totalidad tendremos que pagar intereses; Mario describe algunos puntos como el costo de usar la metodologia de "solo haz que funcione"

• Es muy difícil entender el código, posiblemente únicamente la persona que lo desarrolló, es el "puede" tener un entendimiento aceptable.
• Existe una mayor posibilidad de tener "bugs" extraños y difíciles de duplicar y corregir.
• El realizarle cambios al programa se vuelve cada vez mas complejo, porque no entendemos hasta que punto esos cambios van a afectar otras áreas de nuestro programa.
• No hay forma de reproducir situaciones muy particulares que ocurren con nuestro software y si este inter-actua con otro mas, lo mas común es culpar al otro software.
• Inicialmente quedamos "bien" con el cliente por entregar el software a tiempo, a la larga los errores y fallas de nuestro software nos ponen en una situación no muy buena, y si a esto le agregamos que le cobramos al cliente por arreglar nuestros "errores", pues todavía peor.

Este puntos, entre otros, son referidos en la metafora de la deuda tecnica como el interes que tenemos que pagar haber escogido la ruta facil y hacer que algo funcione sin preocuparnos por tener un codigo limpio.

La metafora se adapta muy apropiadamente al desarrollo de software, estoy completamente seguro que cualquiera que lea esto podra identificar su propia deuda tecnica, yo diria que no es opcional, de una u otra manera todos incurrimos en esta, la diferencia seria simplemente quien se endeuda mas y quien se endeuda menos.

Te resulta dificil hacer cambios al software? Solo hay una persona que puede hacer cambios a "ese" sistema? No entiendes el codigo? Tienes problemas al pasar el codigo a produccion?
Todos esos son sintomas de que estas pagando la deuda tecnica. Pagar los intereses es doloroso porque es trabajo extra que en muchos casos te lleva a endeudarte aun mas.

Una vez que estas en deuda, no hay de otra, hay que pagar, y hay formas de ir pagando, pero mejor aun, hay forma de minimizar la deuda en un principio; ya hablaremos de eso.