General Motors recibió una insólita queja: El dueño de un Pontiac refirió que el coche no arrancaba cuando compraba helado de vainilla.
Este caso sirve para ilustrar la complejidad subyacente a la depuración de código, trasladada al mundo real.
Resulta que el fabricante de coches General Motors recibió en una ocasión una queja muy inusual. Uno de sus clientes lamentaba que su coche no arrancaba cuando iba a comprar helado de vainilla. En cambio, si el helado era de fresa, chocolate, o cualquier otro sabor, el coche arrancaba sin problemas.
Tras recibir la queja, y a pesar de lo surrealista que era, la compañía encargó a uno de sus ingenieros que investigara el insólito caso.
Cuando el especialista conoció al propietario del coche se encontró con un hombre mentalmente sano, normal. Pero el pobre hombre no comprendía por qué su coche no arrancaba cuando iba a comprar helado de vainilla.
El cliente refirió que, en su familia, tenían la costumbre de tomar helado tras la cena. El sabor del helado se decidía por votación. Tras esta, el hombre se desplazaba hasta el centro comercial para comprar el helado del sabor elegido.
Cuando el helado era de fresa, chocolate o limón, no había problema. Sin embargo, cuando el sabor elegido era el de vainilla, el coche no arrancaba tras comprar el helado.
El ingeniero acompañó al cliente a comprar helado de vainilla y, efectivamente, el coche no arrancaba. En los días siguientes, al ir a comprar helado de chocolate y fresa, el coche arrancaba sin problema. Cuando volvió a ganar la opción del helado de vainilla, tras comprar el helado, al coche le volvió a costar arrancar.
El ingeniero empezó a generar una serie de tablas que contaban con muchas variables. Al fin, dió con el quid de la cuestión.
Resulta que, en el centro comercial, los helados se encontraban al fondo del local, con una excepción: el helado de vainilla. Al ser más popular, se encontraba a la entrada del mismo. Por esa razón, el tiempo necesario para comprar el helado era mayor cuando el sabor no era de vainilla. Y cuando era de vainilla, el cliente tardaba menos en realizar la compra.
Al comprar helado de vainilla, el tiempo transcurrido desde que el comprador detenía el coche hasta que volvía a él, no era suficiente para que el sistema se enfriara. Esto provocaba un fenómeno conocido como bloqueo de vapor o Vapor lock. Este fenómeno impide el arranque a consecuencia de las burbujas producidas en el líquido de freno, a causa del calor. Pero con el rato, al bajar la temperatura, estas burbujas se disipan.
El problema, pues, no era el aparente. No se trataba del sabor del helado, sino del tiempo transcurrido durante su compra.
La solución al problema cayó por su propio peso: Para que el coche arrancara, bastaba con ser amable con el resto de compradores del local. "Ceda su turno en caja, deje que el resto de compradores pasen delante suyo, sea amable y no tenga prisa".
De esta forma, el cliente tardaba más en llegar al coche y, por tanto, daba tiempo a que este se enfriara y pudiera arrancar sin problemas.
En ocasiones, la depuración de código se enfrenta a casos similares. Aparecen problemas cuyas causas son difíciles de encontrar, y cuya solución pasa por un proceso que, en apariencia, no tiene nada que ver.
En este caso, ceder el turno e ir sin prisas, con calma, serenamente, solucionó el problema. Y es que el karma consiste en esto. Indirectamente, si eres amable y cedes el turno, el coche arranca; pero si vas con prisas y estresado, esa misma prisa te pondrá cortapisas.
Encontrar la causa no fue fácil, pero se encontró. Y la solución, fíjatetú, pasó por ir relajado, sin prisas y siendo amable.
Lo cierto es que esta historia es un mito que corre por internet desde hace un par de décadas, pero dista de ser cierta. Sin embargo, "se non è vero, è ben trovato".
En mi experiencia como programador, son varios los casos en los que me he tenido que afrontar con experiencias similares. De hecho, para programación con datos asíncronos, es habitual, si bien no es buena práctica, echar mano de los timeouts. Estos, básicamente, piden que algo no se ejecute hasta pasado un cierto tiempo.
Son muchas las soluciones que se pueden aplicar para solventar problemas aparentemente disparatados. Y para cada una de ellas, es necesario analizar qué sucede, por qué sucede, y cómo evitar que suceda. Y esto es tan solo un ejemplo de los rompecabezas a los que nos enfrentamos los desarrolladores para depurar código. Hace falta observación, ingenio y capacidad para encontrar soluciones prácticas. Y cada caso merece un análisis ad hoc.