Tinselcity

Hace mucho tiempo escribí esto sobre algunas personas que conocí. No tiene más objetivo que servirme de memoria externa. Queda escrito para que no ocupe espacio en mi cabeza.


Generic Midsized Consulting

A principios de alguna década, me encontraba trabajando en Generic Midsized Consulting, una típica empresa de software española. Tras pasar por varios clientes y proyectos, terminé viviendo el que sería mi último año con ellos en un extraño papel entre el desarrollo, la formación, la investigación y la venta pueblo a pueblo del Mágico Ungüento Milagroso del Dr. Martingala.

Generic Midsized Consulting es una empresa de esas que principalmente alquila cuerpos calientes, pero además tiene un par de operaciones paralelas que le permiten sacar un poco más. Por un lado, una factoría de software, uno de esos centros de excelencia que se ubican en alguna provincia donde los sueldos sean más baratos y que funcionan de una forma entre oficina de proyectos y churrería. Por otro, una oficina técnico-comercial-publicitaria que trata de vender los proyectos que luego hará bien la mencionada factoría o bien aquellos cuerpos alquilados.

Como digo, bastante típico. La mayoría de programadores que trabajan en estas empresas forman parte del 99%. Unos cuantos consiguen encontrar un puesto directamente con un cliente y algunos menos deciden probar fortuna de algún modo “más diferente”. Yo siempre me he considerado parte del 99%, uno más, sin más, aunque mi progreso ha tenido sus propias particularidades.

En GMC conocí -entre otras muchas- a tres personas con “historias interesantes”: Primero, el Chef y el Arquitiesto.

Primero

Primero de su promoción -tal como él mismo gustaba indicar de vez en cuando-, Primero pasó en GMC los once primeros años de su carrera. Al poco de coincidir con él, se iría de la empresa para, después de una temporada confusa intentando establecer su reputación, pasar los siguientes años en alguna empresa tecnológica famosa a nivel mundial y otras un poco menos famosas, pero igualmente coloridas en el ambiente estartapil europeo.

Primero fue la primera persona que me ha producido el pensamiento claro y definido de “Muy bonito lo que cuentas, pero yo he visto tu código y el daño que produce”.

Da charlas y escribe libros. Charlas de esas que son aplaudidas de forma elegante y moderada y que tratan temas variados y genéricos. No quiere decir que no escriba código con funciones como:

    const shorterThan = function(minLength) {
      return function(text) {
         return text && text.length >= minLength;
    } }

Pero todos cometemos ese tipo de errores alguna vez y no es como para escandalizarse. Tampoco cuando es el código que acompaña a una charla y se proyecta en una pantalla de muchos metros cuadrados como ejemplo de buen código. Ver ese código de Primero en grande, sin embargo, me hizo pensar aquello no era solo un ejemplo sintético, sino código real, código que pretendía llegar a producción.

En Generic, Primero pasó pronto de ser un cuerpo caliente más a llamarse Arquitecto En Jefe y dedicarse, en lugar de a mancharse las botas en proyectos reales, a tareas “más elevadas” como crear una serie de librerías y plataformas varias que otros alquilados de la empresa podrían utilizar, quizá, en alguno de los proyectos o clientes.

Este es otro mecanismo relativamente frecuente en el tipo de empresas como GMC. Si tienes una compañía de este estilo, puedes simplemente proporcionar tus cuerpos calientes a los clientes y ganarte así la vida. Alquilas personas que tienen conocimientos razonablemente genéricos y estándar y que usan herramientas, librerías y plataformas estándar. Esto es bueno para el cliente y muchos de ellos ponen ahí las condiciones. Digo que es bueno para ellos porque, dado que la tecnología es genérica y estándar, en cualquier momento pueden encontrar otros programadores que la conozcan y que se ofrezcan a mejor precio.

Obviamente eso, para GMC, es todo lo contrario a bueno. Así que la solución es relativamente simple: Crear unas herramientas, plataformas, tecnologías propias. Pero espera. Eso sería muy caro y tampoco es fácil convencer a la mayoría de los clientes de aceptar tecnologías propias -y también tiene otros problemas, como encontrar cuerpos para alquilar que conozcan esa tecnología-. Y ahora ya la solución ideal aparece como evidente ante nuestra vista: Extender con alguna pieza propia, la tecnología estándar.

Funciona así: Tomas, por ejemplo, Struts, un framework muy popular a principios de siglo para construir aplicaciones web en Java. Tus alquilados conocen bien Struts, como otros muchos programadores de la época. Pero ahora, sobre Struts, desarrollas una serie de pequeños añadidos suficientemente genéricos como para asegurar que más o menos pueden ser aplicables a cualquier proyecto (o por lo menos que alguno pueden aplicar en un proyecto dado), o desarrollas alguna capa pequeña que envuelve la generalidad de Struts con unos pequeños toques de especificidad. Son pequeñas cosas.

Ahora tienes un producto con un objetivo y una forma de venta muy específica.

Acudes al cliente y le cuentas que tienes todas las ventajas de Struts que espera: que puede sustituir tus alquilados por otros cuando quiera, porque es Struts y los detalles añadidos se aprenden fácilmente. Pero que además, como ya has añadido tú algunas mejoras, ahora mismo le puedes ofrecer hacer el proyecto en menos tiempo porque tus mejoras añaden productividad y facilidad.

Eso en cuanto a pintar bonita tu oferta. Tiene todo lo bueno y nada de lo malo. Realmente el objetivo de “tu” framework es otro ligeramente distinto. No lo quieres para vender, lo quieres como cepo, como cadena para sujetar más fuerte al cliente una vez que ha picado. Es decir, inicialmente es un pie en la puerta, pero después es mucho más: una atadura. Lo usas como “ventaja estratégica” para competir con otros alquiladores de cuerpos calientes. Y lo mejor del truco es que te sale muy barato, ya que apenas has hecho un desarrollo mínimo y escribir una documentación seria y aparente en la que utilizas siempre tu terminología y nomenclatura para referirte a las mismas cosas del framework original. Le añades un nombre vistoso, como OCEAN y todo está hecho.

La única limitación es que cada cinco años aproximadamente, tienes que inventar uno nuevo, porque no controlas cómo evolucionan las tecnologías y Struts cae en desgracia mientras surge Spring. Pero esto es razonable, el coste es asumible. Te inventas otro framework envolviendo ligeramente Spring. Esta estrategia no es exclusiva de este tipo de empresas. También, a veces, la aplica de forma interna un departamento de arquitectura cuando quiere “darse valor” dentro de la empresa. Pero me desvío demasiado…

Primero era, como decía, Arquitecto en Jefe en Generic. Estaba directamente involucrado en crear algunos de estos astutos pseudo-frameworks. Teóricamente era responsable de ellos, pero en la práctica responsabilidad no parece la palabra más apropiada.

Un día, mientras estaba destinado en Seguros Sosos, un cliente con más dinero que criterio que había mordido el anzuelo de varios proveedores de carne, y con particular fuerza el de Generic, me encontré tomando un descanso con Mike, que había venido a Seguros Sosos con una misión muy clara y definida.

Seguros Sosos había comprado un año o dos antes, la realización de un proyecto de un sistema de reglas de negocio para gestionar esto o lo otro. Era difícil saber el motivo o aplicación precisos del proyecto, porque Seguros Sosos es una empresa con un comportamiento particularmente segregador hacia los “externos”. El caso es que casi dos años después el proyecto estaba ahí y no arrancaba.

Había pasado por las manos de varios ingenuos que Generic enviaba para que se hicieran cargo de ello, pero la historia se había repetido por lo menos tres veces, si no recuerdo mal. Era algo así: Llega alguien para hacerse cargo de terminar el proyecto y ponerlo en marcha. Pasa un par de meses intentando desesperadamente encontrar la forma de hacerlo, excavando en el código y descifrándolo. Después pasa otro par de meses más intentando desesperadamente encontrar la forma de huir de allí y de las visiones de violencia y horror que empiezan a poblar su mente. Finalmente, se va.

Mike veía la misma locura pero, más estable que los anteriores, mantenía cierta tranquilidad.

Lo que tendría que pasar es que viniera aquí Primero en persona y que le metiéramos una paliza entre todos. En serio, me lo cargaba.

Cierta tranquilidad, digo.

El proyecto era uno de los frutos de Primero, claro, y era, según me enseñó luego Mike, casi un truco de espejos y humo. Lo bonito era que, como es natural, Primero no quería tener nada que ver con el tema y además su posición en Generic de algún modo se lo permitía. De vez en cuando, como regalando un poco de oxígeno, Primero daba alguna señal débil por email. En general la respuesta era siempre la misma: Que los problemas ya estaban corregidos, que había una versión más nueva del motor de reglas, y que sería necesario hacer algunos cambios en el proyecto pero que, una vez hechos, ya estaría todo bien.

Esto había conseguido vender algunos meses más de paciencia a Seguros Sosos. Pero todos sabíamos que antes o después, el jefe del departamento, que era conocido por tener arrebatos furiosos, acabaría estallando. Porque nada estaba bien ni lo estaría con la próxima versión, que Primero además seguía sin enviar. Todo era una ilusión que ni siquiera conseguía ejecutarse.

La tranquilidad de Mike surgía en parte de su propia forma de ser -un tipo muy simpático y positivo, la verdad- y en parte de saber que tenía ya cerrada una oferta para un mes después en la empresa en la que sigue desde hace más de 7 años. No puedo asegurarlo, porque no lo recuerdo bien, pero diría que ni se molestó en avisar con 15 días. Después de todo, los Sosos eran conocidos por prescindir de sus alquilados de un día para otro y de regatear hasta los últimos minutos del último día.

Otro de los apetitosos frutos de Primero en GMC era un framework para el desarrollo en JavaScript. Con mucho menos éxito fuera de Generic, gracias al cielo, proponía un modelo de diseño basado en unos espantosos -e imposibles de depurar de ninguna forma- componentes que se definían con unas gigantescas declaraciones en JSON, con incontables niveles de anidamiento y cientos de propiedades. Como es obvio, sin documentación del formato, muy pocos se aventuraban a intentar usarlo para algo salvo el propio Primero. En un momento de emoción, Primero subió su código a Sourceforge y allí sigue desde entonces sin que nadie lo toque.

También Primero se fue, como ya contaba, a vivir la aventura de las grandes empresas famosas, de conferencias y de ser un autor de libros que luego posa en su avatar con gesto de superioridad intelectual y mirada al horizonte. Y cada vez que le he visto dando una de esas charlas sobre temas genéricos y ya triturados por otras docenas de charlas, me he encontrado pensando lo mismo. Que ahí arriba, contando esas cosas tan bonitas, se le ve muy bien, pero que probablemente muchos siguen hoy en día sufriendo el dolor y las consecuencias de su código de verdad.

El Chef

El Chef me cae bien. No es mala persona. Pero es Agile Coach. Agile Coach y experto especialista en liderazgo y en optimización de estrategias, en mejora continua y dinámicas de gamificación del psicoanálisis en la comunicación transaccional para evitar la disonancia en las relaciones grupales del equipo. Y más cosas, seguro.

Que yo entiendo que tiene que haber de todo en el planeta, por supuesto. Chef es un tipo majo en general.

Fue programador en un pasado lejano. Brevemente, pero durante un par de años o así fue programador Java con alguna consultora. Luego pasó a enseñar a otros programadores y así es como entró en Generic y como le vi yo durante el tiempo en que coincidimos.

Me lo encontré algunas veces porque iba a los clientes a dar cursos, aunque ya le conocía un poco de antes por otras cosas que hacía. Lo de los cursos tenía su pequeña gracia… Yo estaba alquilado, por ejemplo, en Mobile Cheaporn And Deceit, una compañía multinacional muy seria de servicios móviles. Como yo habría otros 4 o 5 más de Generic allí. Generic vendía un curso a MCAD y el curso, lógicamente era para los empleados de MCAD, que era quien lo pagaba. La gracia no es que no cobraran por darnos el curso a nosotros también, que sería algo obvio. Es que a nosotros no nos permitían atender al curso. Los empleados de MCAD pasaban 5 días en el curso, sin dar un palo al agua, mientras los alquilados absorbíamos la carga de trabajo. Esto también era una práctica bastante habitual en la época. Ahora, según tengo entendido hay algunas empresas de estas que han aprendido algo y por lo menos dan cursos a sus propios empleados. En Generic los alquilados solo recibían cursos cuando estaban desasignados, como aprendí más adelante.

El Chef iba dando cursos de estos. De todo tipo, una semana podía estar dando un curso de Java, otra uno sobre gestión del código y otra sobre prácticas Agile. Al final, decidiría dejar GMC y ponerse por su cuenta. Era inevitable. Realmente él hacía prácticamente todo el trabajo, así que ¿por qué quedarse con su sueldo fijo en lugar de obtener directamente el beneficio de ese trabajo?

Antes de eso, coincidí algunas veces más con él en un cliente que se encontraba en un momento delicado. Quizá la mejor descripción es decir que habían perdido el camino y tampoco sabían a dónde querían llegar. Como ocurre a veces en estas situaciones, estaban tan perdidos que estaban dispuestos a probar lo que fuera.

Yo iba allí semana sí semana no, y cada vez que pasaba una semana sin ir y luego volvía, habían cambiado algo. Las decisiones firmes duraban muy poco y una buena parte del personal parecía hacer lo mismo. El Chef también iba solo algunos días, pero no iba allí como formador, como había ido a otros sitios. Entre las cosas que estaban intentando, la principal era intentar combatir el desánimo de las personas. En el último año la rotación se había disparado y la gente que entraba tampoco parecía tener muchas más ganas de quedarse que la que salía. Las cosas no iban bien de ninguna forma.

Así que vinieron los gurús.

Literalmente. Se contrató a una serie de personas con diferentes intenciones y títulos. Uno de ellos, responsable de algo como “fomentar el cambio de ánimo” o similar, simplemente tenía el título de “Gurú”. Otros, como el Chef, tenían un papel más modesto, pero a la vez algo más real. Porque, sinceramente, al Gurú creo que llegué a verle por allí como mucho una o dos veces y nadie tenía muy claro su horario.

En ese papel es donde empezó el Chef a ser Agile Coach. Hacíamos dinámicas de grupo con juegos que, generalmente, eran de esos típicos de trabajar en equipo para hacer alguna cosa genérica. El equipo lo veía como una forma de perder el tiempo, pero por lo menos una un poco más entretenida que trabajar.

Luego el Chef se fue y se puso por su cuenta, como decía. Ahora forma parte de varios proyectos, de esos que “acompañan a las empresas”, que es algo que siempre me ha recordado a esa persona que cuando vas a ir a hacer la compra te dice “Ah, te acompaño”. Y está bien, claro, a veces la compañía se agradece. Pero eso es todo lo que hace, acompañarte. No te ayuda a llevar las bolsas. Lo que hace es hablar todo el rato sobre lo que deberías comprar y cómo deberías llevar las bolsas y echar un par de caprichos al carro “para mi” porque en realidad sabe hablar mucho de ello, pero lo que es hacer la compra no lo ha hecho nunca desde hace años.

El Arquitiesto

Conocí al Arquitiesto en un momento tumultuoso. Para mi, para él, para Generic. Terminé una temporada en un cliente y acabé impartiendo algunos cursos en las oficinas que tiene Generic en medio del desierto. El ambiente allí era bastante terrible. Por una parte había un pequeño equipo técnico-comercial más o menos estable que se dedicaba a hacer demos, propuestas, pliegos, para potenciales proyectos. Por otra, compartiendo la misma oficina pero sin lugar ni posición fija, por allí pasaban aquellos que se quedaban desasignados entre un proyecto y otro. El momento para mi era algo turbulento porque yo estaba entre los dos grupos. A veces participaba en alguna demo, otros días estaba desasignado. Para Generic el momento era complicado porque empezaron a acumularse los desasignados, y aunque yo les daba cursos para mantenerles ocupados, terminaron por ser recurrentes los Sorteos de los Viernes, donde cada fin de semana tres o cuatro premiados ganaban la oportunidad de irse a casa a las 15:30 del Viernes y ya no volver nunca.

Para el Arquitiesto el momento era algo diferente. No había tanto preocupación cuanto ambición por aprovechar bien las jugadas. Con Primero ya en el recuerdo, el Arquitiesto llegó a GMC para hacerse cargo de una nueva generación de framework-gancho y casi, pero solo casi, me hizo apreciar el trabajo de Primero.

En uno de esos días en que estaba más cerca de la oficina de proyectos que de la oficina de próximos exempleados me tocó ponerme al día de lo que estaba montando el Arquitiesto. Era, igual que los anteriores de GMC, un proyecto de Arquitectura de Powerpoint. También era, como los anteriores, poco más que una amalgama de piezas estándar, de código libre y más o menos establecidas, sobre lo que se añadía alguna herramienta o extensión propia. En este caso, sin embargo, todo era más humo y espejos que en ocasiones anteriores.

Y lo comparé con lo que había hecho Primero años atrás porque en este caso el Arquitiesto, hacer no había hecho mucho. Había una pequeña herramienta en línea de comandos para crear un proyecto sobre la nueva plataforma y, aparentemente, eso era todo. Y luego resultó que ni siquiera eso. La herramienta estaba copiada tal cual de una de código libre. Los nombres cambiados, los copyrights borrados, los comentarios limpiados.

Esto lo sabía yo nada más. Los jefes en la oficina técnica de Generic solo oían las palabras del Arquitiesto cuando llegaba el lunes diciendo que se había dado una panzada de programar todo el fin de semana para hacer la herramienta. Intenté comentar algo de lo que pasaba en realidad, pero sin éxito.

Me tocó trabajar con el Arquitiesto durante un tiempo hasta que conseguí yo también escapar de GMC. En ese tiempo me tocaba a mi programar las demos, arrancar los proyectos y montar los equipos. De vez en cuando me tocaba acompañar al Arquitiesto a algún cliente. Porque, aunque su título era el de arquitecto, su labor era más bien comercial y su arquitectura era, como decía, de Powerpoint. Llegábamos con mi pequeña demo y con su gran presentación. La demostración era más o menos estándar, nada especial. La presentación era todo. Era lo posible y lo imposible, lo improbable y lo absolutamente falso. Vendía todo lo que el cliente quisiera comprar y más, mientras yo miraba horrorizado cómo se apilaban las mentiras con las que después yo, y alguno más, tendríamos que trabajar.

Haciendo esto conseguía sus premios. Cosas como tener la única plaza de aparcamiento que había además de las de los 3 jefes. O el modelo más alto de la gama más alta de SmartTV, que hubo que darle para usar un día en una demo y luego pasó un par de meses en su casa. Pero más que eso, el Arquitiesto conseguía ir moviéndose para su siguiente paso. Tras hacer contactos, publicar PDFs comerciales e ir añadiendo palabrejas por docenas y nuevos títulos cada vez más ambiciosos y rimbombantes a su perfil de LinkedIn, un día -después de que yo me hubiera ido ya- me enteré que se había largado de Generic sin más. Pasó a ser CTO de una startup y luego de otra. Ambas eran de esas que queman dinero hasta que se venden o desaparecen; supongo que se podría decir aquello de tal para cual. No sé qué más ha sido de él, pero tampoco me importa mucho.


La Arquitectura de Powerpoint o de PDF es, lamentablemente, bastante común en la industria. También, claro, los gurús.

En general se aplauden y premian mucho las proclamas grandilocuentes y la excelencia de perogrullo. Las soluciones irreales pero indiscutiblemente ideales, venden. De algún modo, la mayoría de la gente no quiere escuchar los problemas reales o la necesidad de hacer esfuerzos, sacrificios o equilibrios. Lo que quieren es escuchar al que dice tener una solución magnífica e infalible, sencilla de explicar. Llena de palabras muy técnicas que la hacen parecer real e importante pero a la vez hacen que el oyente no se sienta cómodo para discutirla o plantear dudas. Llena también de diagramas con agradables formas y colores que le hacen sentir que sí, que todo eso tiene sentido.

Y esto ocurre a diferentes escalas y con diferentes públicos. Hay Arquitectura de Powerpoint para vender proyectos. La hay para construir y vender currículos. Para ganar luchas internas de poder. Para simular que trabajan mientras hacen que sean los demás los que lo hacen. Para tener siempre una reclamación que hacer a los demás porque no han seguido sus directrices o no han entendido siquiera sus ideas.


Generic Midsized Consulting mientras tanto sigue adelante. Con “sus” frameworks y su alquiler de personas, sobre todo jóvenes, claro. Por lo que sé no les va mal. Y aunque han tenido años mejores y peores, como todos, parece que atrás quedaron aquellos Sorteos de los Viernes.