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.