Ya no es mi dinero: lecciones de poker por Kent Beck

cartas de pokerY esa es mi primera lección del poker. Retiro lo dicho. Mi primera lección del poker es que cuando dos extraños te piden unirse al juego, pierden un poco toda la noche, ofrecen cortar el mazo por $100 cuando el juego está por terminar, entonces tengo que contar el mazo antes y después de que hacen aparecer el as.

Okay, entonces esta es mi segunda lección del poker: cuando el dinero deja mi mano ya no es mio. La noche después al juego estaba increíblemente frustrado. Había perdido y perdido toda la noche. Seguia apostando y perdiendo, apostando y perdiendo. Todo lo que podía pensar era en el próximo juego para poder recuperar mi dinero.

En el trascurso de la sigueinte semana me obsesioné con esa idea: debeía recuperar mi dinero. Y a la vez, una parte de mi estaba al costado diciendo: "Disculpame, hola, eso no tiene sentido". En algún momento me di cuenta lo que estaba mal con mi razonamiento - no era mi dinero. Había dejado de ser mi dinero ni bien alguien más lo había ganado. De hecho, había dejado de ser mi dinero del momento en que puse la apuesta. Le di mi dinero al juego, y el juego le dio el dinero al ganador, y eso fue todo. No podía recupera mi dinero porque no era mi dinero.

Paz. A veces las obsesiones funcionan así. Te das cuenta lo que estaba mal con tu razonamiento y el ciclo se detiene. Esta fue una de esas veces. No era mi dinero. No lo podía recuperar, porque no era mio. La próxima vez que jugué, tan sólo jugaba. Comencé con $20 y fui desde ahí.

Muchos reconocerán la Falacia del Costo Irrecuperable. El dinero ya había sido apostado, se había ido, era irrecuperable.  No tiene sentido incluir eso en la toma de decisiones. Conocía la Falacia del Costo Irrecuperable, pero no la tenía en cuenta.

Esta misma situación ocurre todo el tiempo en la programación. Venimos de una larga sesión de refactor, cada paso del cual es perfectamente seguro. Y entonces corremos las pruebas. Una prueba se rompe. ¿Qué deberíamos hacer? ¿Qué deberíamos hacer si el error no es obvio? ¿Qué deberíamos hacer si el error no es obvio y llevamos haciendo el refactor por un minuto? ¿Por una hora? ¿Un día? ¿El tiempo invertido influye en cómo proceder? 

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 dificil será encontrar el error, mayor el valor de empezar otra vez. Mientras más dificil 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.

Y mientras escribo esto me doy cuenta que con JUnit soy culpable de una variación de la Falacia del Costo Irrecuperable. Quienes lleven leyendo mi blog por algún tiempo, me habrán escuchado quejarme por no encontrar un modelo de negocios alrededor del éxito de JUnit para tener ganancias. El razonamiento incorrecto es algo así: JUnit creó un montón de valor en el mundo (miles de millones de dólares según mis cálculos), y no recibí nada de eso.

¿Y qué? Si JUnit no hubiera creado nada de valor pero estuviera en la misma posición, ¿qué debería hacer? Exactamente lo mismo que si hubiera creado millones de dólares o miles de millones. Es la Falacia del Beneficio Irrecuperable. Lo pasado ya fue. No es mi beneficio. Todo lo que importa es la situación actual. Toda la energía o pensamientos que ponga en el pasado tan sólo dificultarán mi pensamiento.

Así que acá está mi resolución. Voy a pensar sobre el estado actual de las pruebas de desarrollo, voy a analizar las tendencias, y me voy a adelantar. Así es como voy a vivir de JUnit. Ah, y me voy a asegurar de contar el mazo de cartas, o mejor aún, no apostar con extraños.

Traducido de Not my money anymore: lessons from poker 4, por Kent Beck.
Compartir
  • Sergio Rafael Gianazza

    Me encantó. Totalmente de acuerdo con Kent Beck de que pensar en el pasado te limita a mirar la situación actual y poder sacar beneficio de ella.

Deja tus comentarios

Post comment as a guest

0

El nuevo Dos Ideas.

Nuevo logo, nuevo buscador, nueva portada, podcast mensual... ¡y muchas novedades más!

Más novedades en Dos Ideas

Los Comentarios.

Eso está muy bien cuando todos los trabajadores tienen aspiraciones de progreso y responsabilidad en...
I found this post very exciting. I think you will have any other post on this topic? I am also sendi...
Hay una gran contradicción de lo que es PaaS y el listado de los PaaS actuales que ponen al final, A...
invitado
Todo lo que dice en este post es la verdad, me ha llegado al corazon esos consejos y los aplicare de...
This is very interesting, You're a very skilled blogger. I have joined your feed and look forward to...

Inspiración.

"Si tú tienes una manzana y yo tengo una manzana e intercambiamos las manzanas, entonces tanto tú como yo seguiremos teniendo una manzana cada uno. Pero si tú tienes una idea y yo tengo una idea, e intercambiamos las ideas, entonces ambos tendremos dos ideas"

Bernard Shaw