De monos, melanesios y desarrollo de software

monkeys

En los años 60 un grupo de científicos realizó un experimento utilizando unos monos.

Prepararon una jaula en cuyo interior había una escalera sobre la que colocaron unos plátanos y encerraron en ella varios monos. Cada vez que uno de los monos subía por la escalera para coger los plátanos, lanzaban un chorro de agua fría sobre los que estaban en el suelo. Poco a poco, los monos fueron descubriendo cómo funcionaba aquello, y cuando un mono intentaba subir por la escalera, los otros se lo impedían a golpes. Al cabo de un tiempo, y por mucho que deseara coger los plátanos, ningún mono subía por la escalera por miedo a las represalias.

Entonces los científicos reemplazaron uno de los monos del grupo por otro mono nuevo. Éste, como no tenía ni idea de cómo funcionaban allí las cosas, intentó ir por los plátanos, claro, pero el resto de los monos le convenció amablemente a golpes de que no debía hacerlo, evitándose así la ducha de agua fría. Unas cuantas palizas después, el nuevo mono ya había aprendido que si intentabas subir por la escalera, lo ibas a pasar mal.

Nuevamente, los científicos reemplazaron otro de los monos originales por un mono nuevo. El proceso fue similar, con el anterior mono novato participando alegremente en las palizas a su nuevo compañero para que no pudiera subir por la escalera y evitar el chorro de agua fría.

Tras repetir el proceso varias veces, llegó un momento en que no quedaba ninguno de los monos originales. Ninguno de los monos que estaban en la jaula había llegado nunca a coger plátanos (siempre se lo habían impedido antes), y ninguno había visto nunca el chorro de agua fría, pero todos tenían clara una cosa: si alguien intentaba subir por la escalera, había que pegarle para impedírselo.

En realidad, la historia tiene más de fábula que de experimento real, pero como toda fábula sirve para explicar fácilmente una idea: a veces hacemos las cosas simplemente porque así se han hecho siempre, sin saber realmente por qué se han hecho siempre así.

Los melanesios

cargo-cult

Dejemos tranquilos a los pobres monos y hablemos un poco de melanesios.

En esa aislada región del mundo, cuando los habitantes locales entraron en contacto con sociedades tecnológicamente más avanzadas, se produjeron una serie de fenómenos muy curiosos llamados cargo cults.

El más conocido, y del que procede el término cargo cult, tuvo lugar durante la Segunda Guerra Mundial. En aquella época, las tropas japonesas y estadounidenses desplegadas en la zona recibían la mayoría de suministros por transporte aéreo. Si era posible, se construía una pequeña pista de aterrizaje para que los aviones pudieran dejar su carga, pero si el terreno lo impedía, se lanzaba la carga con paracaídas desde los aviones.

Como os podéis imaginar, esto para los habitantes de la zona debía resultar bastante sorprendente. Gracias al contacto con las tropas pudieron descubrir que lo que caía del cielo en esas cajas o dejaban en el suelo los aparatos voladores eran cosas útiles: herramientas, armas, comida, o incluso vehículos ligeros.

Al terminar la guerra e irse los soldados dejaron de llegar este tipo de suministros a las islas. Los isleños, que no acababan de comprender por qué ya no recibían de cuando en cuando estas maravillas modernas, y por qué se habían ido los que habían sido sus vecinos durante unos años, andaban bastante confundidos. No faltaron visionarios que convirtieron todo en un asunto religioso y así nacieron los cultos a los cargamentos.

Para intentar que volvieran los aviones a dejar su preciada carga, los seguidores de estos cultos se dedicaron a copiar lo que habían visto hacer a los soldados anteriormente. Empezaron a vestirse como soldados y hacer desfiles con armas de madera simulando rifles. Construyeron torres de control y pistas de aterrizaje, y fabricaron cascos como los de los controladores aéreos. Hasta construyeron réplicas de aviones y los pusieron en las pistas de aterrizaje para ver si eso atraía a otros aviones.

La mayoría de estos cultos fueron creados por personajes carismáticos dentro de la cultura melanesia y no está muy claro si realmente creían en ellos o sólo querían aprovecharse de los más crédulos. No todos los cultos están relacionados con la carga aérea de la Segunda Guerra Mundial, y hoy en día todavía quedan algunos activos, como el que considera al Príncipe de Edimburgo como un dios.

Los desarrolladores

Si has aguantado hasta aquí, tal vez estés pensando con condescencia en los pobres monos que no se enteran de nada o en los inocentes melanesios que pensaban que por ponerse unos cocos en las orejas podrán comunicarse con los aviones. En realidad en nuestro día a día tendemos a actuar como ellos mucho más de lo que sería recomendable.

En el caso de los monos, tenemos el típico ejemplo de “esto se hace así porque siempre se ha hecho así”. Probablemente en más de una ocasión te has encontrado con un escenario en el que acabas siguiendo un proceso (voluntariamente o no) porque es como se hace. Y seguro que, en algún momento, tuvo sentido hacerlo así. Es posible que las nuevas generaciones de monos, si intentaran subir por la escalera, no recibieran el manguerazo de agua fría, pero da igual. Saben hacer las cosas de una forma determinada, les ha funcionado hasta ahora, y aunque arriesgarse y probar otras técnicas podría mejorar su situación, ni siquiera se lo plantean.

Pasando al desarrollo de software es frecuente ver esto en muchos niveles.

Cuesta encontrar ventajas al utilizar un editor de texto y herramientas de línea de comandos si siempre has usado un IDE, porque esa es “la forma seria de programar”. Si habías descartado los lenguajes estáticos porque “aquí siempre hemos usado lenguajes dinámicos”, es normal que te sorprendas al ver lo que te pueden ofrecer. Es habitual seguir fiel a tu base de datos relacional de siempre sin considerar otras alternativas. O mantener la misma arquitectura de 47 capas que llevas usando desde 2001. Es díficil dejar de usar esas “buenas prácticas” que tan interiorizadas tienes pero que, ¿realmmente lo siguen siendo?

Todos estos casos son habituales, y es muy fácil dejarse llevar por la inercia y seguir haciendo lo que se ha hecho siempre porque, de una forma u otra, funciona y nos ha llevado hasta aquí, así que, ¿para qué cambiar? No se trata del cambio por el cambio, pero sí de estar abierto a replantearse continuamente lo que estamos haciendo, nuestros enfoques, nuestras herramientas y nuestros procesos, y analizar para qué las usamos, por qué las usamos y si realmente tiene sentido seguir haciéndolo.

Cuando llegamos a estas situaciones y nos hacemos conscientes de lo que no sabemos, es natural querer mejorar. Y ahí corremos el riesgo de que nos pase como a nuestros amigos los melanesios. No es tanto que nos podamos encontrar con líderes carismáticos que nos quieran convencer de nada, sino que nuestro propio desconocimiento nos lleva a hacer cosas de dudosa utilidad.

Nos puede parecer muy gracioso pensar en un señor en mitad de la jungla, subido a un avión de madera con cocos en las orejas para atraer a otros aviones, pero muchas veces hacemos cosas parecidas. Tendemos a aplicar prácticas para conseguir un efecto determinado sin comprender realmente la relación entre unas y otros.

Eso nos lleva a crear un culto alrededor de determinados temas que convertimos en dogmas y aplicamos constantemente, sin que nos aporten el beneficio esperado. Como buen culto, tienen su componente religioso que hace que nos cueste ver que no funcionan (o que no funcionan tanto como esperamos), y seguimos haciéndolo sólo para ver si conseguimos los resultados que, aparentemente, otros están consiguiendo haciendo cosas parecidas.

Nuevamente, es algo que ocurre en muchos aspectos del desarrollo de software.

No es una cuestión de hacer daily meetings, planning poker o poner post-its en tableros, es buscar una forma apropiada de gestionar un proyecto. Lo importante no es utilizar un contenedor de inversión de control, es desacoplar componentes o poder cambiar su configuración dinámicamente. Puedes montar arquitecturas de moda de esas que usan otros que nos parecen más listos y tienen millones de usuarios, pero eso no hará que tu aplicación sea un éxito y consigas los millones de usuarios. Da igual que escribas un montón de tests con la esperanza de que eso mejore la calidad de nuestro producto, si no tienes en cuenta cuáles son los motivos para escribir o no esos tests. Aunque montes un precioso sistema para calcular métricas sobre el código, si no has pensado que vas a hacer con esas métricas tu código no se va a volver mejor.

Son sólo unos cuantos ejemplos de cosas que pueden ser muy útiles, pero necesitas saber para qué se hace cada cosa.

Es vital comprender el contexto en que estas cosas son soluciones a problemas y, sobre todo, qué problemas resuelven. Quizá sean soluciones perfectamente válidas, pero para problemas que tú no tienes. Hace falta hacer el esfuerzo de dar un paso más y comprender mejor lo que estás haciendo. Si no, puedes acabar construyendo una pista de aterrizaje en mitad de la selva para ver si se posa en ella algún avión.

Imagen de monos de dominio público e imagen de Cargo Cult Military History Now


4 comentarios en “De monos, melanesios y desarrollo de software

  1. Jose Alberto dijo:

    Buen artículo, señalando un mal común: Inmovilismo tecnológico.

    Pero, por otro lado, hoy en día veo muchos lenguajes, librerías, frameworks, metodologías, y, sobre todo, muchos hype, demasiados quizás. Veo que se cambia de tal a cual lenguaje o librería solo por ser “lo último” sin evaluar si realmente aporta o no a tu proyecto, solo por “no perder el tren”. Tan mala es una posición como la contraria. Ay! ese equilibrio que siempre anhelamos.

  2. Acabo de marcar un check para demostrar que no soy un robot. Y quizá sea exagerado pero ahí, justo ahí, está la clave: En no ser un robot.

    Yo sé porqué tengo que marcar ese check. Quiero decir, sé por qué eso está ahí y lo que implica y el problema que resuelve y por qué me pides que lo marque.

    Cuando hacemos cualquier cosa, sea la tarea que sea, es ese conocimiento de por qué hacemos eso de un cierto modo y no de otro, el que marca la diferencia. No es realmente el enfrentamiento de inmovilismo contra moda. Es el enfrentamiento del desconocimiento contra la comprensión.

    Me recuerda la clásica historieta de la máquina estropeada de Tom Knight…

    A novice was trying to fix a broken Lisp machine by turning the power off and on.

    Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”

    Knight turned the machine off and on.

    The machine worked.

    Lo hacemos tantas veces, ¿verdad? “Bah, reinicia el servidor”. Y sí, hay veces que se arregla, pero si no sabemos qué está pasando o por qué hacemos las cosas, todo lo que hagamos será rito y superstición.

  3. Como siempre genial Juanma , me gusta leer este tipo de artículos ya nos haces otra vez más pensar y recordarnos que NO debemos dejarnos llevar por las modas .

    Está claro que debemos ser más autocriticos , comprender el contexto de las cosas y dar un paso más allá. Pero creo que muchas veces es dificil producir el cambio y evitar ser apaleado por esos monos , por tanto al final la solucion suele ser marcharse a otro sitio ya que es imposilbe producir un cambio.

    Por cierto muy buena la forma en la enlazas tus otros artículos ;-) well done.

  4. Creo que este post hace que me den ganas de dejar todo como estaba por que así funcionaba, así esta en todos lados y me quiero evitar las palizas.

    Desgraciadamente me ha tocado entrevistar a muchas personas que dicen saber X tecnologia y solo me doy cuenta que han trabajado con ella, es raro encontrar a alguien que medianamente sepa para que se creo X cosa, simplemente asi han trabajado y no se cuestionan nada, si existe algo mas o una mejor forma de hacerlo, que problema resuelve, en que principio se basa, etc.

    Por ejemplo, ¿para que usar una interfaz?, R= no se asi me lo enseñaron.

    Pero existen muchos argumentos validos para usarla, como para evitar que los desarrolladores usen nombres diferentes en cada service para el metodo que guarda un registro, pero si el proyecto solo es para testear la nueva versión de Spring, como que no veo la razón de utilizarla, pero cambiando el contexto, si ese proyecto lo usaran de ejemplo y tu sabes que asi como pongas el ejemplo, exactamente, haran lo mismo las personas que lo leen, supongo que crear la interfaz vuelve a tener sentido, maldito contexto.

    Muy buen articulo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

*

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>