Hace unas semanas, intentando aprender de los que más saben, leí este artículo de Kent Beck. No es cuestión de traducirlo, porque ya lo ha hecho la gente de DosIdeas, pero sí que me gustaría comentarlo.
Kent Beck pone el ejemplo de una partida de poker en la que pierde mucho, y sólo piensa en seguir apostando para poder recuperar su dinero. Pero se da cuenta de que ya no era su dinero, había dejado de serlo desde que lo apostó. Tras esta reflexión, vuelve a jugar como si fuera la primera partida.
Luego explica que esta situación pasa también cuando programamos. Cito la traducción hecha por Leonardo De Seta para esta parte, porque este punto es realmente interesante:
Mi experiencia es que lo correcto en esta situación en donde no sabemos lo que hicimos para romper las pruebas es volver inmediatamente a un estado verde conocido, y volver a ejecutar las pruebas. Luego comenzar el refactor otra vez y correr las pruebas a cada paso. Pero, y aquí está la parte irracional, mientras más tiempo llevamos haciendo el refactor, más tentados estamos en seguir. Esta es la Falacia del Costo Irrecuperable en acción.
Mientras más llevo haciendo un refactor, menos recuerdo todos los pasos, más difícil será encontrar el error, mayor el valor de empezar otra vez. Mientras más difícil es comenzar otra vez (emocionalmente), más valioso es comenzar otra vez.
Ya no es mi tiempo. ¿Estuve haciendo un refactor por un minuto? ¿Una hora? ¿Un día? No importa. Ya no es mi tiempo. Se lo di al programa. Se fue. Lo que haga ahora no debería estar influenciado por la magnitud del tiempo que ya invertí. Ya no es mi tiempo.
Esto que explica Kent Beck se basa en la falacia del costo irrecuperable o falacia de la concordia. Esta falacia se produce cuando alguien realiza una inversión que parece ser no rentable y razona de la siguiente manera: «No puedo parar ahora, de otra manera lo que he invertido hasta el momento se perderá». Esto es verdad, por supuesto, pero irrelevante para la decisión de si uno debe continuar invirtiendo en el proyecto. Es decir, los argumentos para seguir invirtiendo en el proyecto no se deben basar en el miedo a la pérdida de lo invertido sino en las expectativas de funcionamiento del proyecto ambas cosas totalmente independientes.
Desde luego, ahora intento tener muy en cuenta esta historia al tomar decisiones, no sólo cuando programo.
Kent Beck pone el ejemplo de una partida de poker en la que pierde mucho, y sólo piensa en seguir apostando para poder recuperar su dinero. Pero se da cuenta de que ya no era su dinero, había dejado de serlo desde que lo apostó. Tras esta reflexión, vuelve a jugar como si fuera la primera partida.
Luego explica que esta situación pasa también cuando programamos. Cito la traducción hecha por Leonardo De Seta para esta parte, porque este punto es realmente interesante:
Mi experiencia es que lo correcto en esta situación en donde no sabemos lo que hicimos para romper las pruebas es volver inmediatamente a un estado verde conocido, y volver a ejecutar las pruebas. Luego comenzar el refactor otra vez y correr las pruebas a cada paso. Pero, y aquí está la parte irracional, mientras más tiempo llevamos haciendo el refactor, más tentados estamos en seguir. Esta es la Falacia del Costo Irrecuperable en acción.
Mientras más llevo haciendo un refactor, menos recuerdo todos los pasos, más difícil será encontrar el error, mayor el valor de empezar otra vez. Mientras más difícil es comenzar otra vez (emocionalmente), más valioso es comenzar otra vez.
Ya no es mi tiempo. ¿Estuve haciendo un refactor por un minuto? ¿Una hora? ¿Un día? No importa. Ya no es mi tiempo. Se lo di al programa. Se fue. Lo que haga ahora no debería estar influenciado por la magnitud del tiempo que ya invertí. Ya no es mi tiempo.
Esto que explica Kent Beck se basa en la falacia del costo irrecuperable o falacia de la concordia. Esta falacia se produce cuando alguien realiza una inversión que parece ser no rentable y razona de la siguiente manera: «No puedo parar ahora, de otra manera lo que he invertido hasta el momento se perderá». Esto es verdad, por supuesto, pero irrelevante para la decisión de si uno debe continuar invirtiendo en el proyecto. Es decir, los argumentos para seguir invirtiendo en el proyecto no se deben basar en el miedo a la pérdida de lo invertido sino en las expectativas de funcionamiento del proyecto ambas cosas totalmente independientes.
Desde luego, ahora intento tener muy en cuenta esta historia al tomar decisiones, no sólo cuando programo.
Algo tan simple y obvio es a su vez difícilmente practicable por un pensamiento que prioriza la perdida actual en vez de pensar el la expectativa de futuro que puede tener. Es una especie de enajenación mental transitoria
ResponderEliminar