-
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.
