Metáfora
Me comencé a interesar en la forma en que las metáforas influencian cómo pensamos
luego de leer el libro de Goerge Lakoff y Mark Johnson "Metaphores we live by"
Y la idea importante es que nosotros razonamos por analogía con metáforas que existen en nuestro lenguaje
Deuda
Acuñé el término la "metáfora de la deuda" para explicar la refactorización que estábmos haciendo
en el producto WyCash. Esto fue un producto temprano en Digitalk Smalltalk y era importante para mí
que acumulábamos las alertas que nos daba la aplicación a lo largo del tiempo modificando el programa
para hacer lo que hubiera podido ser fácil hacer en Smalltalk.
La explicación que le dí a mi jefe, dado que era un software financiero, fue una analogía financiera.
La llamé "la metáfora de la deuda"
Y dije que "si fallamos en hacer que nuestro software se alinee con lo que entonces entendíamos
que era la manera adecuada de pensar sobre objetos financieros entonces íbamos a estar
contínuamente encontrándonos con ese deseacuerdo y eso se podía ver como pagar el interés de una deuda".
Velocidad
Con dinero prestado podés hacer algo más rápido de lo que lo harías de otra manera, pero
a menos que devuelvas ese dinero vas a estar pagando intereses.
Pensé que pedir prestado dinero era una buena idea,
pensé que apurar el software a salir por la puerta para obtener algo de experiencia
era una buena idea, pero que por supuesto
eventualmente volvés atrás y cuando aprendés cosas sobre ese software
vas a pagar esa deuda refactorizando el programa para reflejar la experiencia que adquiriste
Carga
Creo que hubo muchos casos donde la gente apuraría la salida del software y aprendería cosas
pero nunca pondrían ese aprendizaje de nuevo en el software, y que por analogía
estaban pidiendo dinero prestado pensando que nunca debería pagar esa deuda.
Por supuesto que si hacés eso, por ejemplo con tu tarjeta de crédito, eventualmente todo tu ingreso
va a pagar los intereses y tu poder de compra asciende a cero.
Por el mismo motivo si desarrollás un programa por un largo período de tiempo sólo agregando
características y nunca reorganizando tu entendimiento sobre esas características
entonces eventualmente ese programa no contiene ningún entendimiento
y todos los esfuerzos para trabajar sobre él toman más y más tiempo.
En otros palabras el interés es total, y hacés un progreso nulo.
Agilidad
Por lo menos un montón de bloggers explican la "metáfora de la deuda" y que confunden
lo que pienso en la idea de que podrías escribir código póbremente con la intención de hacer un buen trabajo
luego y creo que eso fue la principal fuente de deuda. Nunca estaré a favor de escribir código póbremente,
pero estoy a favor de escribir código que refleja tu actual entendimiento sobre el problema
aún cuando ese entendimiento sea parcial.
Si querés ser capaz de entrar en deuda de esa manera, desarrollando software que no entendés completamente
eres sabio por hacer que tu software refleje tu entendimiento de la mejor forma en que puedas
entonce cuando viene el momento de refactorizar es claramente el momento en el que repensás lo que escribiste
hace más simple refactorizar del modo en que estás pensando ahora mismo.
En otras palabras, la analogía de la deuda completa, digamos la habilidad de pagar esa deuda
y hacer que la metáfora de la deuda funcione a tu favor
depende de que escribas código que sea
suficientemente limpio para ser capaz reflejar tu entendimiento actual
tu problema, y creo que es una metodología buena en el corazón del Extreme Programming.
La "metáfora de la deuda" es una explicación, una de muchas explicaciones de por qué el
Extreme Programming funciona.