1 00:00:00,000 --> 00:00:02,000 Metáfora 2 00:00:04,000 --> 00:00:09,000 Me comencé a interesar en la forma en que las metáforas influencian cómo pensamos 3 00:00:10,000 --> 00:00:15,000 luego de leer el libro de Goerge Lakoff y Mark Johnson "Metaphores we live by" 4 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 5 00:00:26,000 --> 00:00:28,000 Deuda 6 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 7 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í 8 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 9 00:00:56,000 --> 00:01:06,000 para hacer lo que hubiera podido ser fácil hacer en Smalltalk. 10 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. 11 00:01:13,000 --> 00:01:14,000 La llamé "la metáfora de la deuda" 12 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 13 00:01:22,000 --> 00:01:28,000 que era la manera adecuada de pensar sobre objetos financieros entonces íbamos a estar 14 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". 15 00:01:37,000 --> 00:01:39,000 Velocidad 16 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 17 00:01:45,000 --> 00:01:50,000 a menos que devuelvas ese dinero vas a estar pagando intereses. 18 00:01:52,000 --> 00:01:55,000 Pensé que pedir prestado dinero era una buena idea, 19 00:01:55,000 --> 00:02:00,000 pensé que apurar el software a salir por la puerta para obtener algo de experiencia 20 00:02:00,000 --> 00:02:03,000 era una buena idea, pero que por supuesto 21 00:02:04,000 --> 00:02:10,000 eventualmente volvés atrás y cuando aprendés cosas sobre ese software 22 00:02:11,000 --> 00:02:19,000 vas a pagar esa deuda refactorizando el programa para reflejar la experiencia que adquiriste 23 00:02:19,000 --> 00:02:22,000 Carga 24 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 25 00:02:30,000 --> 00:02:37,000 pero nunca pondrían ese aprendizaje de nuevo en el software, y que por analogía 26 00:02:37,000 --> 00:02:42,000 estaban pidiendo dinero prestado pensando que nunca debería pagar esa deuda. 27 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 28 00:02:48,000 --> 00:02:51,000 va a pagar los intereses y tu poder de compra asciende a cero. 29 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 30 00:02:57,000 --> 00:03:02,000 características y nunca reorganizando tu entendimiento sobre esas características 31 00:03:02,000 --> 00:03:06,000 entonces eventualmente ese programa no contiene ningún entendimiento 32 00:03:06,000 --> 00:03:11,000 y todos los esfuerzos para trabajar sobre él toman más y más tiempo. 33 00:03:11,000 --> 00:03:15,000 En otros palabras el interés es total, y hacés un progreso nulo. 34 00:03:16,000 --> 00:03:18,000 Agilidad 35 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 36 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 37 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, 38 00:03:41,000 --> 00:03:47,000 pero estoy a favor de escribir código que refleja tu actual entendimiento sobre el problema 39 00:03:47,000 --> 00:03:50,000 aún cuando ese entendimiento sea parcial. 40 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 41 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 42 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 43 00:04:10,000 --> 00:04:15,000 hace más simple refactorizar del modo en que estás pensando ahora mismo. 44 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 45 00:04:21,000 --> 00:04:24,000 y hacer que la metáfora de la deuda funcione a tu favor 46 00:04:24,000 --> 00:04:27,000 depende de que escribas código que sea 47 00:04:27,000 --> 00:04:31,000 suficientemente limpio para ser capaz reflejar tu entendimiento actual 48 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. 49 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 50 00:04:41,000 --> 00:04:43,000 Extreme Programming funciona.