¿Por qué todo el mundo odia a los programadores?

Hace no mucho, y de chiripa, me encontré con un post titulado “Porqué la gente odia a los programadores” (sic). En él, el autor se despacha a gusto contra los de mi especie y aunque alguno de sus argumentos pueden ser válidos, hay uno que me llegó al alma, porque es absolutamente falso y nos presenta como causantes de algo, cuando en realidad somos la primera víctima de un problema de gestión. Entonces, ¿por qué todo el mundo odia a los programadores? Duda resuelta abajo.

Los Motivos del Humano

En un poema de Rubén Darío, basado en la leyenda del “Lobo de Gubibo”, y llamado “Los motivos del lobo”, San Francisco de Asís mantiene un diálogo con un lobo, intentando entender el por qué de su rivalidad y agresión a los humanos. El “Hermano Lobo”, le da un repaso de cuidado al santo, explicando claramente sus motivos contra nuestra especie. Veamos ahora cuales son los “motivos del humano” en contra de la especie programadoril, siempre por supuesto de acuerdo al autor del post.

Somos unos horteras

(…) existe ese regustillo marginal en el vestir. Escenificado en llevar camisetas negras de Debian con agujeritos, o algo peor. (…) El programador típico podría trabajar de extra en una peli de Torrente y nadie notaría que no ha pasado por vestuario. Absolutamente cierto. Es una de las características más visibles de nuestra especie, pero no exclusiva de los programadores. Todo profesional creativo profundamente apasionado por su trabajo termina descuidando el aspecto exterior, porque vive realmente en su propio Matrix. Científicos, artistas y por supuesto, programadores, tenemos un aspecto estrafalario, cuando no desaliñado. Es más, la primera descripción de un grupo de programadores, hecha por un psicólogo, lo menciona de inmediato: “Jóvenes brillantes de aspecto desaliñado, con frecuencia con ojos hundidos y brillosos, pueden verse sentados frente a la consola de la computadora, (…) Su ropa arrugada, cara sin lavar ni afeitar y cabellos despeinados, todo refuerza la idea de que son indiferentes a sus cuerpos y al mundo en el que se mueven.” Esto fue escrito en 1969 por el profesor Joseph Weizembaum. Por cierto, ésta es la pinta que gasta el amigo Weizenbaum:

Somos unos arrogantes

A este motivo le dedica varios párrafos, señal de que le llega al alma. El segundo factor por el cual los programadores tienen tan pocos amigos es la arrogancia. La mayoría de los programadores consideran a los usuarios como una especie de subhumanos. Esto es absolutamente cierto. Muchos consideramos a los usuarios como hombres-mono que, al igual que los pitecántropos de la famosa escena de 2001, tratan a palos y golpes nuestra “Obra de Arte”, que por supuesto son incapaces de entender. Más que arrogancia pura y dura, esto es fruto de un excesivo apego a su trabajo y creación, que nos lleva a veces a olvidar los intereses legítimos de los otros implicados: vamos a crear el software perfecto porque sí, y si alguien consigue hacer algo útil con él, pues asunto suyo, pero no es ni remotamente mi prioridad. Yo lo veo más como un exceso de pasión por tu labor y algo que puede y debe ser contenido y reconducido por el project manager. Bien conducido, es una virtud. Es decir, vale, somos arrogantes, pero tampoco es que sea tan grave.

Somos unos tarados sociales

(…) la mayoría de las personas no son precisamente muy hábiles reconociendo y controlando sus emociones, pero en el caso de los programadores se junta el hambre con la gana de comer. Absolutamente cierto, la inmensa mayoría de nosotros tenemos déficits sociales más o menos graves. Sin embargo, no me parece una crítica del todo válida, ya que se trata de una incapacidad a menudo innata, no voluntaria y no deseada. Aquí entramos en el terreno en que la principal víctima de aquello de lo que se nos acusa, somos nosotros mismos. El aislamiento social no es voluntario en muchos casos y tiene consecuencias graves. En resumidas cuentas, es cierto, pero criticar a alguien por una incapacidad involuntaria bordea el mal gusto.

Somos unos chapuceros

(…) en ninguna rama ingenieril existen (sic) probablemente tanta tendencia a la ñapa. Vale, aquí es donde quería llegar yo, porque se trata de una calumnia. Es innegable que muchos proyectos de software terminan siendo una antología de la ñapa y chapuza, se trata de uno de los grandes males de nuestra profesión. No obstante, no es la informática la única rama de la ingeniería donde se dan estas calamidades y la razón de su mayor prevalencia no es una predisposición genética del programador a la ñapa. Para encontrar la verdadera raíz del problema, veamos algunos ejemplos de proyectos que terminaron en fiasco bajo el peso de una montaña de ñapas inmanejables.

La Fragata Baden-Wurttemberg

La armada alemana tenía puestas todas sus esperanzas en esta nueva clase de fragatas, que iba a resolver varios problemas a la vez. Se trata de una fragata compacta, del tamaño de un destructor, con grandes capacidades de ataque a objetivos de tierra. Su menor tamaño y extensiva automatización hacía que se redujese la tripulación necesaria. Por si fuera poco, podría llevar a cabo una gran variedad de misiones mejor y con menor coste que otros buques especializados: transporte de infantes de marina, soporte de artillería a tropas en tierra, caza de buques y submarinos enemigos, además de poder pasar hasta dos años desplegadas a gran distancia de su puerto de origen. De hecho, el cuello de botella era la tripulación y la armada alemana tenía pensado ir rotando las tripulaciones mientras la fragata seguía en sus misiones. Vamos, la hostia en verso y estaba destinada a marcar el resurgir de la armada alemana después de años de decadencia y caos. En vez de eso, el primer buque de lo que iba a ser una nueva clase, tuvo el dudoso honor de ser el primer buque devuelto al fabricante en la historia de la armada alemana. Devuelto por inservible. Ni siquiera era capaz de flotar de forma correcta, ya que se inclinaba peligrosamente para un lado, sin que nada ni nadie lo pudiese corregir.

El F-35 o Joint Strike Fighter

En 2001, el departamento de defensa de EEUU le concedió a Lockheed Martin el contrato del siglo: iban a crear el avión de combate más avanzado y polivalente de la historia. Lo iba a hacer todo, mejor que cualquier otro avión y a menor coste: combate contra otros cazas, ataque a tierra, reconocimiento e incluso despegue y aterrizaje vertical. Cinco años y miles de millones de dólares más tarde, en 2006 cuando debería de estar siendo desplegado por el mundo, un prototipo logró volar por primera vez. El avión que lo iba a hacer todo, estaba teniendo problemas con todo. Otros quince años y 400 mil millones de dólares más tarde, el F-35 tiene un motor que se sobrecalienta, un ordenador logístico que proporciona información falsa y aleatoria al piloto, y un sistema de defensa que no lo protege frente a los rayos. Se han identificado más de 13 defectos que ponen en peligro la vida del piloto, además de otros fallos menores que hacen que tenga dificultades en: mantener el vuelo supersónico, permanecer controlable cuando vuela en un ángulo de más de 20º, mantener presurizada la cabina, volar cuando hace frío o aterrizar cuando hace calor.

¿Qué tienen en común?

Podría dar más ejemplos de proyectos igualmente fracasados. Fiascos tan extremos que resultan cómicos (a no ser que seas piloto de un F-35). ¿Qué tienen todos en común? Es cierto que todos los ejemplos que he dado son proyectos militares, pero eso es circunstancial. La característica determinante, es que todos, absolutamente todos, se basaron en tecnologías no testadas e intentaron hacerlo todo a la vez. Esa es la receta asegurada para el fracaso, ya que maximiza las posibilidades de que todo salga mal en forma de bola de nieve. Ahora bien, ¿en qué rama de la ingeniería es más barato y tentador cometer esos dos errores? Efectivamente, en la programación. El coste real y percibido de hacer cambios para abarcarlo todo y usar “soluciones mágicas” que todo lo arreglan es mucho mayor, al tratar no con objetos físicos sino intangibles. ¿Cómo evitar las ñapas? ¿Qué podemos hacer entonces, para evitar ser partícipes de un festival de ñapas? Es incuestionable que parte de nuestro trabajo es avisar al equipo de gestión y negocio cuando algo es imposible de hacer. También lo era de los ingenieros aeronáuticos y navales de los proyectos mencionados, y no lo lograron. La razón es que como dijo Upton Sinclair, “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” Cuando el equipo de gestión y negocio están bajo una presión titánica para lograr lo imposible, no resulta factible hacerles ver lo que en el fondo ya saben: lo imposible no puede ser y además es imposible. La industria de la informática es tan solo el blanco y víctima más fácil para este tipo de descarrilamientos de gestión, y los programadores somos los primeros en sufrir las consecuencias de estos proyectos catastróficos. Las primeras señales de descarrilamiento son los plazos inasumibles y las constantes horas extras que tiene que enfrentar el equipo de desarrollo. El resultado, además de la desmoralización por un trabajo mal hecho, es el estrés y el “burnout”. Cuando el proyecto se convierte en una marcha fúnebre que avanza a paso de tortuga y dejando un reguero de lágrimas detrás de sí, la primera víctima mortal es el equipo de desarrollo. En esos casos, hay que acudir a los botes salvavidas y mandar currículos. Así que horteras y arrogantes, sí, pero chapuceros no. Un respeto, oigausté.