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