Cagarse en el chocolate

Serie: Los N Pecados Capitales

En la empresa de Willy Wonka, se fabrica un exquisito chocolate. Al menos, esa es la opinión general. La producción está a cargo de los umpalumpas: una extraña raza de friquis canijos, adictos a la programación en Java, a los que pagan con granos de cacao.

Los umpalumpas tienen la curiosa manía de inventarse canciones sobre la marcha, y luego pretender que se trata de tonadas tradicionales, de las de toda la vida. Por ejemplo, si un niño glotón se cae dentro del río de chocolate, improvisan una canción explicando por qué no se debe uno inclinar demasiado sobre la corriente. Si un proyecto de desarrollo fracasa estrepitosamente, se inventan melodías que hacen referencia a dominios escuálidos, programación ágil e inversión del control. Son pintorescos, estos personajillos.

Pero los umpalumpas tienen también una costumbre muy fea. Alex, un umpalumpa de Pontevedra, revuelve el chocolate fundido cuando siente que algo más se revuelve en su interior:

- Willy… ehm… señor Wonka.
- ¿Sí, Alex?
- Tengo un apretonciño de intestinos…
- Te aguantas. Esta barra de chocolate tenía que estar para ayer.
- ¡Pero es que me lo voy a hacer encima!
- Caga entonces dentro de la tina del chocolate.
- ¡¿Cómo?!
- Joder, Alejandrito, ¿tengo que dibujarte un diagrama de clases?
- Pero, ¿cómo vamos a echar mierda dentro del chocolate?
- A ver, ¿de qué color es el chocolate? Marrón. ¿Y la mierda? Marrón. Un poco de mierda espesa aporta crema al cacao.
- Pero… es que estoy un poco estreñido y estoy cagando boliñas, como las de las cabras…
- Pues mejor aún: chocolate con cacahuetes, y si las bolas son más grandes, con nueces y avellanas.

Por desgracia, la mierda de umpalumpa es sumamente corrosiva. Por su culpa, caen aviones, revientan naves espaciales, fallan sistemas de soporte vital en hospitales y se aplican dosis excesivas de radiación a pacientes de radioterapia. Será mierda, pero hay que tomársela muy en serio.

Hay mil y una maneras de cagarse en el chocolate. Por mencionar unas pocas:

1. Una aplicación para almacenar expedientes médicos, escrita en dBase, generaba claves primarias mediante el sucio mecanismo de contar los registros en el fichero y aumentar el valor en uno. Mientras el hospital tuvo un único ordenador en admisión, el chocolate sabía a ambrosía. Un día instalaron un segundo ordenador, y en algún momento, se crearon dos registros simultáneamente… con la misma clave primaria. Migrando la aplicación a InterBase, en el 2000, alguien tropezó con la historia clínica de un buen señor que había sufrido la extirpación de sus ovarios.
2. En la historia anterior, el error no se detectó porque los índices de aquella versión de dBase no permitían la comprobación de unicidad. Pero conozco un par de sistema implementados sobre Oracle en los que los “diseñadores” (es un decir) han evitado el uso de claves primarias concienzudamente.
3. La mismísima Borland se cagó, en su momento, en el chocolate de la casa. Cuando apareció Delphi 2, se produjo una ola de fallos en aplicaciones de servidor. La causa: en servidores con procesadores Xeon, fallaban determinadas operaciones sobre cadenas de caracteres, porque la implementación del tipo String no era thread-safe.
4. Todos sabemos, o eso espero, que no debemos acceder a los métodos de un objeto de ventana desde un hilo diferente a aquel en el que fue creada. Sin embargo, este tipo de violación no es verificada en ningún caso por .NET Framework v1.1. Muchas aplicaciones, por lo tanto, ignoran total o parcialmente el problema… hasta que migran a una versión más reciente de la plataforma y empiezan a reventar por todas partes. Entonces, improvisan cantando los umpalumpas, la culpa es de Microsoft, evidentemente.

¿Se ha dado cuenta ya de cuál es el patrón emergente? Se trata siempre de fallos que se producen al no tener en cuenta la concurrencia. La técnica ingenua de generación de claves primarias funciona mientras hay un solo ordenador. La implementación defectuosa de las operaciones de cadenas funciona incluso cuando hay varios hilos, pero siempre que exista un único núcleo. Los errores de reentrancia de Windows Forms y WPF se producen pero no se notan… hasta que el sistema revienta por causas desconocidas.

Cuando se trabaja con una base de datos relacional, además, en teoría existe una forma muy sencilla de evitar la mayoría de los errores: trabaje con transacciones serializables. ¡Pero la mayoría de los programadores, o desconocen su existencia, o tienen miedo a la pérdida de velocidad! De hecho, la mayoría de las operaciones complejas en las bases de datos habituales pueden implementarse con un nivel de aislamiento más bajo, si se ordenan inteligentemente las instrucciones. Esto es algo, sin embargo, que se encuentra fuera del alcance de la mayoría. Y quien sospecha que hay algo que puede fallar en su implementación, termina cagando dentro del chocolate: ya haremos algo cuando falle.

Otra fuente habitual de tropezones en el cacao: los errores de redondeo. ¿Cuántos programadores, de los que trabajan con aplicaciones financieras, tienen idea sobre los problemas de estabilidad numérica y sus consecuencias en el desarrollo? Es más fácil tener una idea vaga de que existe un problema "teórico", y dejar que sea el desdichado usuario el que hunda sus dientes en la mierda de umpalumpa. Sólo entonces merece la pena hacer algo.

¿Existe alguna solución mágica para evitar sustancias extrañas en nuestros alimentos? Por desgracia, sólo hay una forma, y requiere una cualidad personal muy extraña y poco valorada: la ética profesional. Pero estamos en crisis, y la ética es un bien caro y escaso. Al menos, deberíamos presionar a las autoridades europeas para que los productos de software lleven una etiqueta de advertencia, como las de los sándwiches que venden en las gasolineras:

"Puede contener trazas de cacahuetes, pescado, huevo, gluten
y mierda de umpalumpa."

Perestroika

El funcionario de la calva brillante con la mancha como un mapamundi se levantó y se dirigió hacia los micrófonos. Carraspeó y comenzó a hablar cansinamente, como hablaban los funcionarios de la extinta Unión Soviética:

- Daraguíe tavarischi - es decir, "hola, troncos" - El Soviet Supremo me ha encargado la honrosa tarea de comunicaros dos noticias. Una buena y una mala. La buena es que hoy ya es viernes.

Un murmullo de satisfacción teñida de falsa sorpresa recorrió la sala.

- La mala - titubeó, aunque sólo un momento - la mala es que lo nuestro no funciona.

Los ecos del murmullo cesaron abruptamente.

- ... y no me refiero a lo de enfriar en una nevera las semillas de patata antes de sembrarlas, para aclimatarlas al frío - el anciano hijo de Trofim Lysenko se levantó airado y abandonó la asamblea - sino a este invento del comunismo.

Una mosca atravesó la enorme sala zumbando. Nadie la detuvo.

- Sí, coño, hemos estado haciendo el panoli durante setenta años. Y para nada. Hemos matado de hambre a media Ucrania. Hemos jodido a conciencia a polacos, húngaros y checos, y a buena parte de Alemania. ¿Y todo para qué? Para que nuestros obreros pasen hambre y frío, para fabricar estos horribles coches y esos espantosos sintetizadores alemanes democráticos que se funden antes de terminar la primera estrofa de la Kalinka. Esto, maí vesyolye rebyata, no firula...

Los murmullos se reanudaron. El delegado de Dirkadirkastán alzó tímidamente la mano y preguntó:

- Y ahora, ¿qué?
- Ahora - el calvo hizo una pausa teatral - ahora... ¡perestroika!

---

En Redmond parecen estar también algo revueltos y perestroikos:

• Self-tracking entities in the Entity Framework

Y ya era hora, coño. Ya era hora de que alguien se diese cuenta de que todo este invento del POJO, del POCO y del MOJO POCO no funciona cuando se trata de escribir aplicaciones multicapas. La vanguardia del proletariado, por supuesto, pondrá el grito en el cielo, pero de momento andan callados. Puede que no hayan comprendido lo que hay en juego. En realidad, los fundamentalistas javalinos suelen comprender muy pocas cosas.

Es verdad que los de Microsoft se asemejan más a los chinos que a los rusos: cada cierto tiempo se inventan una Revolución Cultural y no son muy ortodoxos en lo tocante al martinismo-fowlerismo. Además, acaban de perder al Gran Timonel. Y tienen una misma palabra para crisis y oportunidad: suena parecido a crisistunidad.

Más extraña que la ficción

Había una vez una empresa imaginaria, habitada por escarabajos peloteros que practicaban el cargocultismo mientras arrastraban sus fragantes bolitas de excrementos y esperaban el regreso de John Frumm. Un buen día, apareció un feo insecto en sus instalaciones, amenazando con devorar los cimientos corporativos. Para exterminarlo, los escarabajos ejecutaron la danza ritual del pollo de Skinner y practicaron un exorcismo.

Demasiado folklore acumulado en un solo punto del espaciotiempo, en mi opinión. Un punto imaginario, quise decir...

---

... y si enmascarar un bug mediante el simple expediente de unir dos instrucciones try/catch no es bailar la danza del pollo de Skinner, que vuelva John Frumm y lo vea.

Por supuesto, el problema real es que el nido del monstruo sigue estando ahí, no tan evidente como el dinosaurio de Monterroso, pero aún amenazante.

Antología del Disparate - III

Advertencia: Cualquier parecido con
la coincidencia, es sólo una sospechosa irrealidad...

uando, meses atrás, se me ocurrió la idea de escribir sobre el cargocultismo estaba pensando, en particular, en el problema artificial, creado por mis amigos imaginarios, que voy a discutir a continuación. Repasemos la definición: el cargocultista es el individuo que practica determinados rituales técnicos porque sabe, o ha oído decir, que a otros les funcionan, pero sin comprender realmente cómo se supone que tienen que funcionar.

En el mundo de la programación, uno de esos rituales misteriosos tiene que ver con la creación de gestores especiales para distintos módulos de la aplicación, sobre todo cuando se trata de proyectos grandes. Una aplicación "decente" tiene que definir, por fuerza, un "gestor" de menúes, un "gestor" de excepciones, un "gestor" de formularios... y así hasta el aburrimiento o la bancarrota. Para ser exactos, una parte importante de esta secta de cargocultistas no utiliza la palabra "gestor" sino manager, que se supone que debe darle un poco más de dignidad al engendro.

Como suele ocurrir en todos los casos de cargocultismo, la propia idea de un gestor de menúes y ventanas no es mala. ¡Todo lo contrario! Estos módulos suelen ahorrar mucho código repetitivo, y tienen la bonita propiedad de dejarse reutilizar fácilmente de un proyecto al siguiente. Incluso cuando se utilizan en un único proyecto, nos ofrecen la libertad de hacer cambios notables en la interfaz de usuario sin necesidad de retocar todo el código. Visual Studio, por ejemplo, nos permite elegir entre una aplicación MDI tradicional o una en la que los documentos aparecen en páginas paralelas accesibles por pestañas. Lo verdaderamente malo, es inventarse uno de estos gestores sin saber por qué, para qué o cómo.

Cuello de botella

A diferencia de disparates anteriores, esta vez el problema no está en una simple instrucción equivocada, sino en el diseño global de un módulo. Los problemas comienzan con la decisión, consciente o inconsciente, de esta gente de ignorar el mecanismo preestablecido para la traducción en .NET y de montar un barroco sistema basado en ficheros XML externos. El vínculo entre cada elemento de la interfaz y su correspondiente cadena se realiza manualmente. Supongamos que usted quiere añadir una etiqueta a un formulario que debe decir "Total". De acuerdo a la metodología de estos señores:

1. Primero debe ocurrírsele un nombre global para identificar la etiqueta. No se les ocurrió generar ese nombre a partir del nombre del control y del formulario donde se encuentra.
2. Luego tiene que ir a cada fichero XML de traducción y crear una entrada que traduzca el identificador al correspondiente idioma.
3. Cada formulario tiene un método Traducir. No crea que se trata de un método virtual heredado: la herencia visual es algo desconocido en esta metodología. Tiene que añadir una instrucción manualmente a Traducir en la que asignará a la propiedad Text de la etiqueta, el resultado de una llamada explícita a un método que busca en un diccionario en memoria la traducción correspondiente.

Usted se dirá que... bueno, es bastante trabajo, claro... pero con un poco de disciplina... etc, etc. ¡Ah, cuán equivocado estaría! ¿No le he dicho aún que esta gente trabajaba con SourceSafe, para el control de versiones? Imagine lo que ocurre cada vez que dos programadores intentan programar dos formularios que nada tienen que ver entre sí: ¡se tienen que pegar por el acceso a los ficheros de idiomas!

De todas maneras, aunque no se produjese este increíble cuello de botella, el sistema es inaceptable:

1. Microsoft ofrece, de serie y sin coste adicional, un mecanismo idéntico en funcionalidad y sin ninguno de estos problemas: ficheros de recursos y ensamblados satélites.
2. El sistema de Microsoft no le obliga a añadir código manualmente en ningún momento.
3. El sistema de Microsoft le permitiría, incluso, ahorrar trabajo suponiendo la existencia de un "idioma neutro", para el cuál no tendría que mantener una tabla de recursos adicional.
4. El sistema de Microsoft es verificable en tiempo de compilación: si compila, funcionará. En cambio, el invento en cuestión utiliza cadenas como claves en el diccionario. Resulta imposible verificar automáticamente la existencia de errores de mecanografía. Por supuesto, si esta gente hubiese usado enumerativos para las claves, el problema se resolvería... pero los dioses ciegan a aquellos a quienes quieren destruir.

Moraleja parcial: no hay que reinventar la rueda, si además, va a rodar más despacio.

Escarnio de la locura

Pues bien, queridos amiguitos, hay también un menú diseñado de acuerdo a esta locura con sistema. Hay claves con formato de cadenas, que tienen que transmitirse desde el código al fichero externo y viceversa, hay versiones del menú para cada idioma soportado y todo lo demás. Pero me voy a centrar en un aspecto muy concreto: en cómo se maneja la ejecución de los comandos del menú.

Cada vez que se ejecuta un comando del menú principal, se invoca un manejador de eventos situado en la ventana principal. No crea que hay un manejador diferente para cada comando, lo cuál habría sido relativamente sencillo de conseguir: todos los comandos van a parar al mismo método. Y ese método, cómo no, contiene una inmensa instrucción switch, que toma la cadena de caracteres designada como clave del comando para ejecutar el código apropiado.

¿Y en qué consiste ese "código apropiado"? Maravíllese: en una llamada a un método global estático de una clase independiente, a la que llamaremos Acciones, que se encuentra en un gigantesco fichero C^#.

• Nuevamente, tenemos un fichero que se convierte en un cuello de botella.

Claro, los conflictos por el acceso al fichero de acciones sólo tendrían que surgir cuando se modificase la estructura del menú... ¿o no? Resulta que no: cuando esta gente tiene que mostrar una ventana que permite una sola instancia, incluye, en el fichero de acciones, un bucle explícito para buscar si existe ya una instancia del tipo de ventanas en una lista global. Si la encuentran, la activan. Y si no, la crean. Y este código se repite tropecientas y tantas veces, una por cada ventana de este tipo, en el fichero de acciones.

• Con un poco de reflexión, el código común se podría haber reducido a una simple llamada.
• Pero mejor aún, el switch original ni siquiera tendría que haber pasado por la clase Acciones, sino que tendría que llamar directamente a métodos estáticos de las clases de ventanas correspondientes. De esa manera, cualquier cambio en la forma de mostrar una ventana, se aislaría dentro del código de la propia ventana.
• Para rematar, esta gente ni siquiera utilizó una metodología uniforme para la creación y activación. A veces llamaban a Show, otras veces combinaban BringToFront, Activate y Focus; a veces cambiaban la forma del cursor, y en otros casos, mostraban una ventana splash con el mensaje "Espere un poco...". Esto complica mucho limpiar el código.

Con todo, lo peor es que a estar alturas todavía les cuesta creer que este sistema sea un error: el cargocultismo susurró en sus oídos que necesitaban un "gestor de menúes" para su aplicación "seria", y ahora tiemblan cada vez que mis tijeras podan porciones cada vez mayores de este cadáver exquisito. Mientras limpio los fluídos putrefactos de mis instrumentos de corte, veo ojos asustados y oigo el coro de plañideras a mi alrededor. Sonrío tranquilizadoramente, pero compruebo que mi sonrisa parece cada día más siniestra.

Y es que uno termina hartándose, ¿sabe?

El escarabajo pelotero

Serie: Los N Pecados Capitales

Algunos sostienen que fue Aldous Huxley; la mayoría cree que fue J.B.S. Haldane, pero es también posible que se trate de una anécdota apócrifa. Cuentan que un teólogo victoriano preguntó a Haldane, biólogo de profesión, si podía deducir algo sobre Dios a partir de su huella en el Universo. La respuesta fue: "no sé, quizás una desmedida afición por los escarabajos".

Puede que Dios ame a los escarabajos, pero lo que es seguro es que algunos escarabajos han sido adorados como dioses. El escarabajo pelotero (Scarabaeus sacer) es una especie de cucaracha acorazada que se pasa el día entero recogiendo mierda y amasándola en forma de pelotitas. Es un verdadero comemierdas, porque se alimenta de esa misma materia prima, e incluso deposita sus huevos dentro de las bolas de estiércol para su incubación.

Los egipcios, que para algunas cosas había que darles de comer aparte, observaron a los pequeños escarabajillos saliendo de su incubadora de mierda y dedujeron, los muy listos, que el bicho se autoenterraba en porquería para luego renacer, como ave fénix... aunque algo más pringada. Compararon la faena cotidiana del escarabajo, arrastrando bolitas de caca, con la sagrada misión de Ra, el dios encargado del disco solar. Y añadieron este bicho de mierda a su interminable lista de dioses, diosecillos y otros seres espirituales.

Más tarde, cuando el cristianismo llegó a Egipto, los coptos, que no andaban muy finos con esto de las metáforas, vieron en el escarabajo un símil anticipatorio del sacrificio de Cristo. En algunos libros de la época, se llega a llamar a Cristo el "bonus scarabaeus": el buen escarabajo. Esto es lo que yo llamo una metáfora de mierda...

---

En Informática, un escarabajo pelotero es el desgraciado que cree que las aplicaciones se escriben acumulando minúsculas pelotitas de mierda, una sobre la otra, de manera progresiva, a la vez que se canta una alegre canción. Hay escarabajos, no obstante, que creen que lo de la canción es opcional. Les va más el chasquido del látigo.

Un buen escarabajo pelotero es un individuo "constructivo", en el peor de los sentidos. ¿Hay que ordenar una lista? Fácil, se dice el insecto. Planta sus pezuñas sobre el primer elemento, y busca el menor de los restantes elementos. Si es diferente del primero, intercambia ambos. Luego pasa al siguiente elemento y repite el algoritmo. ¿Funciona? ¡Pues claro que funciona! Y es que he elegido al ejemplar más inteligente de la especie a la vez que el algoritmo más sencillo. El problema es que nuestro insecto ignora que existe una técnica llamada quicksort, y que a partir de cierto tamaño, su uso se convierte en una necesidad. De manera que ya podemos identificar uno de los síntomas del trastorno:

• Pobre pensamiento algorítmico

Ahí está el verdadero problema: no se trata de desconocer la existencia de un algoritmo dado, sino de la arrogancia que a veces, por desgracia, viene aparejada con el desconocimiento. Y si un escarabajo se permite ignorar la Algorítmica, no se le ocurra hablarle de estructuras de datos.

El daño que puede causar este angelito depende de lo alto que se encuentre en la jerarquía de una empresa. Imaginémoslo jefe de un proyecto que comienza. ¿Cómo lo haría? La necesidad de resultados inmediatos podría con él... y se lanzaría a rodar bolitas de mierdas, sin importar que el montón de bolitas se parezca más a una pirámide que al castillo que tiene que construir. Ya se encargarán los de marketing de colgar un gran cartel a la entrada de la pirámide que diga: "CASTILLO".

Pero lo peor es que nuestro sujeto es ahora un jefecillo, y ya no tiene que ensuciarse las manos en mierda, porque para eso tiene su equipo. Este es el resultado:

• Un ciego, para dirigir a videntes, les obligará a vendarse los ojos

Mientras menos información suministre a su equipo, el buen señor se sentirá más seguro. Nadie podrá darse cuenta a tiempo de su ineptitud. Y si la pirámide de bolitas de mierda se derrumba, la culpa siempre será los esclavos.

¿Tiene arreglo un escarabajo pelotero? Todo depende de cuán alto haya logrado reptar. Si el individuo está bajo su mando, hay una sencilla solución: cree un ambiente laboral intelectualmente estimulante. Organice seminarios internos, y haga rotar al ponente. Traiga revistas técnicas y libros a la oficina. El amor propio obra milagros.

Por el contrario, si el escarabajo está o estará por encima de usted en la jerarquía de mando, sobre todo si tiene potestad para interferir en su trabajo... huya. A esas alturas, el buen señor estará convencido de que ha llegado a su posición gracias, precisamente, a lo que él considera sus virtudes (ver el Principio de Peter), y cualquiera que contradiga su estilo, será visto como un enemigo peligroso. Váyase. Déje que su pirámide de estiércol se derrumbe sobre su cabeza. Ya se las apañará para renacer de entre la caca.

Cargocultismo

Serie: Los N Pecados Capitales

Durante la Segunda Guerra Mundial, las tropas americanas desembarcaron en muchas islas cuyos habitantes habían tenido poco o ningún contacto con la civilización occidental. Ante los ojos de estos nativos, se desarrollaba un drama sacado de la ciencia ficción: unos seres curiosos, venidos de muy lejos, que realizaban ceremonias incomprensibles, a través de las cuales obtenían un nivel de bienestar material antes desconocido en la zona.

Uno de aquellos seres, por ejemplo, pasaba horas hablando con una extraña caja de la que sobresalían cuerdas de metal. Al parecer, aquellas conversaciones con la misteriosa caja conseguían que en la isla se posaran gigantescos pájaros de hierro, procedentes de la tierra de los antepasados, de cuyos vientres se extraían toneladas de comida, armas y otros objetos deslumbrantes y probablemente útiles. No, no se trataba de dioses, pero era evidente que aquella tribu había descubierto cómo contactar con sus antepasados y recibir la correspondiente bendición material.

Llamaba también la atención el que buena parte de estos marines fuesen de piel oscura... como la mayoría de los nativos, pues he olvidado aclarar que mi historia tuvo lugar en la Melanesia. Esto hacía que la idea de contactar con los antepasados para recibir un cargamento resultase más creíble: los negros de aquella tribu lo habían logrado, ¿no? En la mente de estos melanesios comenzó a forjarse la image de un tal John Frumm (¿John from America, quizás?) un marine negro que prometía volver para ayudar a los nativos tras la guerra.

Naturalmente, terminó la guerra y John Frumm no regresó. O si regresó, no lo reconocieron. Ante la ausencia, ¿por qué no intentar seguir el camino de Frumm? Tallaron radios de madera de cocotero, y pintaron líneas con hollín sobre zonas despejadas. Nativos con hojas de palmeras en sus manos imitaban el código de banderas de los norteamericanos, con la esperanza que aquel baile que habían visto ejecutar a John Frumm atrajese el cargamento de los antepasados a las islas.

Aún hoy, "tropas" de melanesios desharrapados desfilan en algunas islas con rifles de madera al hombro. El fenómeno se conoce como cargo cult y, como puede sospechar, ha sufrido algunos cambios en su necesaria evolución. Por ejemplo, para algunas sectas, los blancos se oponen a revelar el secreto del "cargo", y periódicamente estalla la violencia contra los pocos occidentales que tienen a mano. Ha surgido también algún mesías nativo que ha reclamado ser un avatar de John Frumm, y ha propiciado el correspondiente cisma entre los cultocarguistas.

---

La Informática está llena de cargocultistas: personas que han visto a otras usar con éxito determinada técnica, y que luego se lanzan a repetir la ceremonia sin entender realmente de qué se trata. Por ejemplo, todo el mundo ha leído sobre la maravillosa revolución que se produjo cuando Santa Programación Orientada a Objetos se encarnó entre los mortales, allá por los tiempos de gloria de C++. Por lo tanto, cuando es necesario escribir una aplicación para bases de datos, intentan utilizar eso de los "objetos". Y establecen principios como: "sólo es profesional aquel que define una clase Cliente". O: "tenemos que usar UML, o Java, o servicios Web... aunque no tengamos ni puñetera idea de por qué, pues es lo que hacen los programadores serios". Amén, hermano.

Observe que el cargocultismo es un mal diferente del síndrome del pollo de Skinner. En este último, se cree en la existencia de una relación causa/efecto inexistente, mientras que el cargocultismo se basa en una conexión real, que verdaderamente funciona... excepto que el cargocultista no comprende por qué. ¿Otra diferencia? Nadie confesaría voluntariamente que actúa como un pollo de Skinner, mientras que el cargocultismo tiene cierta aura de respetabilidad a su alrededor. Cuestione a un cargocultista, y parecerá que está cuestionando los principios más básicos de la profesión.

Además, tengo mejor opinión de un pollo de Skinner que de un cultocarguista. En cierto modo, todos hemos sido pollos de Skinner: el aprendizaje y la experiencia son la medicina contra ese estado. Por el contrario, es difícil curar a un cargocultista.

Y es que, en este mundo, mucha gente sigue esperando el regreso de John Frumm.

El Pollo de Skinner

Serie: Los N Pecados Capitales

Burrhus F. Skinner fue un famoso psicólogo estadounidense, mundialmente conocido por sus trabajos en la escuela conductista; aparte de lo anterior, y sin menoscabo de lo dicho, fue también un redomado cabrón (y que me perdonen sus descendientes y herederos). No es éste el momento de explicar el adjetivo, sin embargo. Sólo quiero contar uno de sus muchos experimentos.

Skinner puso un pollo frente a una caja que, de manera totalmente aleatoria, recompensaba al animalito, de cuando en cuando, con una golosina. El minúsculo cerebro del ave, no obstante, intentaba establecer una relación causa/efecto entre sus acciones y las recompensas. Si los pollos hablasen, ésta sería una posible transcripción de sus pensamientos:

¡Vaya, se ha abierto la caja! ¡Y qué gusano más sabroso había dentro! Veamos, ¿qué estaba haciendo cuando se abrió la caja? Entonces movía el cuello, de arriba a abajo. Repitámoslo. Arriba. Abajo... Nada, recórcholis... ¡espera, se vuelve a abrir! Gulp... Parece que si levanto una pata en el segundo movimiento, funciona. Ahí vamos... Espera, debo haberlo hecho mal. Corrijamos el movimiento de la cola... ¡Abrete, maldita seas!

Los pollos de Skinner terminaban elaborando complicadas danzas con el propósito de influir en la apertura de la caja de las golosinas. A pesar de todo, la caja se abría por motivos completamente distintos...

---

Muchos programadores y analistas se comportan como los pollos de Skinner. Se enfrentan a sistemas complicados, cuyo funcionamiento no conocen a fondo. Tras mil peripecias, logran que la aplicación funcione, pero atribuyen la causa del correcto funcionamiento a factores equivocados. Y el toque de brujería termina transformándose en un Principio, con mayúsculas, que todo recién llegado debe acatar, so pena de terribles torturas.

¿A santo de qué cuento esta historia? No sea mal pensado: estaba recordando algunos casos pintorescos que he conocido como consultor, y se me ocurrió recopilar algunos de los patrones, o más bien antipatrones, que son frecuentes en este mundillo. El primer antipatrón que me ha venido a la mente es el del Pollo de Skinner. Pero habrá más...