Hace poco volvía del trabajo en tren, meditando sobre diferentes aspectos trascendentales de mi existencia (en qué me he equivocado, de dónde sale tanto inútil, a qué huele un recurso humano…) cuando intercepté una conversación mantenida en los asientos contiguos:

-Entonces, ¿cómo os ha ido el año fiscal?

-Nada mal, hemos facturado casi un 15% más que el año anterior.

-Pues nosotros hemos mantenido el nivel de crecimiento.

Las voces venían de detrás de dos ejemplares de revistas de economía. Vaya, -pensé- ahí tenemos a dos grandes directivos. De esos que hablan de millones de euros como el que habla de irse de tapas, de los que deciden hoy las tendencias de los mercados de mañana, de esos que…

-Bueno, hasta luego Javi, yo me bajo aquí que voy a clase de badminton

-Venga, nos vemos Fran…

Eran dos chavales enfundados en trajes que les quedaban grandes. Aún presentaban restos de acné. Sus tarjetas identificativas rezaban: Javier Maneras, Bibiandersen Consulting, Junior Consultant; Francisco Minglanillas, Teddybear Point, Junior Consultant.

Javi salió del tren. En una mano su revista financiera, en la otra una bolsa con un yogur líquido y una pera. Se perdió entre la gente caminando con esa rectitud característica del empleado satisfecho de gran multinacional, tal que si llevara una escoba metida por el culo. Minglanillas volvió la mirada a su panfleto con una media sonrisa tipo “psé.. a ver que pone aquí.. pero vamos que ya me lo se…”

Hemos facturado. Nosotros. La corporación. Ya no hay más yo, ahora sólo hay nosotros. El plural corporativo. “Yo curro, tu curras, él cobra, nosotros facturamos, vosotros facturáis, ellos viven de puta madre”. Y todos tan contentos.

¿Cómo se las apañan estas grandes compañías para tener a la mayoría de sus empleados trabajando sin hora de salida, muchas veces de lunes a domingo, con salarios inicialmente míseros que crecen bastante más despacio que el stress, y aun así autosatisfechos, corporativizados y mineralizados? ¿Drogas, hipnosis? ¿Método Ludovico, Habitación 101?

No. No es necesario. Sólo se necesita aplicar el principio de la corporación americana: tratar al empleado como si fuese un cliente. ¿Y cómo se trata al cliente? Encendamos un momento el televisor: “con tu móvil Cadena hoy ya eres un poco más libre… Hostias padre Benito ¿A ti cuántas te daban?… Mecheros Inmolator, la chispa de la vida…”

Efectivamente. Al cliente se le trata como si fuese gilipollas; al empleado también. Y funciona. Funciona de maravilla…

Viernes, 8:45 AM, Oficinas de Teddybear Point Consulting. Director técnico al teléfono con un cliente.

[director] ¿¡¡MESAS!!? No, no, de mesas nada. Si lo que queréis son mesas las compráis en Ikea. Nosotros lo que os ofrecemos son superficies cuadrúpedas de despliegue y explotación compatibles dot NET y J2EE, con sistema de sincronización de filostros y derivación de forlayos. ¿Que no necesitáis tanta tecnología? Bueno, no es eso lo que piensa vuestra competencia. No sabes la que se avecina en el sector… créeme, nuestros últimos análisis indican que en tres meses todo modelo de negocio que no contemple la derivación de forlayos en sus superficies cuadrúpedas va a quedar obsoleto. No querréis quedaros fuera, no… Sí, sí, exactamente… considéralo una inversión a medio plazo. Invertir en forlayos es posicionarse en el mercado del mañana. ¿Para el lunes? Sí, no te preocupes, te mando a nuestro mejor analista… Okey. Hasta pronto.

Colgó el teléfono y accionó el intercomunicador:

[director] Maika, buenos días, hazme un favor: llámame al despacho a algún Junior con la hora de overtime a menos de 15 euros. Si, ahora mismo. Gracias.

[megafonía] Don Francisco Minglanillas, don Francisco Minglanillas, acuda a dirección…

Fran salió de su cubículo, se apretó el nudo de la corbata y se introdujo su mejor escoba. A los cinco minutos estaba entrando al despacho del director, que le esperaba con los brazos abiertos y una enorme sonrisa de dientes puntiagudos.

[director] ¡Señor Minglanillas! Póngase cómodo… Ha surgido una gran oportunidad e inmediatamente hemos pensado en usted. Se trata de un proyecto de superficies cuadrúpedas.

[Minglanillas] ¿Filostros y forlayos?

[director] Excelente. Sabíamos que era usted el candidato ideal. Le vamos a pedir un pequeño sacrificio, señor Minglanillas. El proyecto tiene que estar listo para el lunes.

[Minglanillas] Cuente con ello.

[director] Excelente. Sabíamos que estaría usted a la altura. Considérelo una inversión a medio plazo: los expertos en filostros de hoy son los analistas de mañana.

[Minglanillas] Una cuestión: todo proyecto de superficies cuadrúpedas requiere de una logística inicial. ¿Está ya preparada?

[director] Ah sí. Las mesas. Cómprelas usted esta misma tarde en Ikea.

Minglanillas salió del despacho repitiéndose mentalmente: Analista, analista, analista… Tenía una erección. Buscó un rato por internet y descargó dos archivos .pdf: “Filostros in a Nutshell” y “A qué huele un forlayo”.

¿Cómo es posible que un individuo absolutamente lego en materia de software sea capaz de dirigir un proyecto sin que se le vea el plumero? ¿No debería hacerse evidente su incompetencia? ¿No debería fracasar el proyecto estrepitosamente? Sin embargo, estos individuos conservan sus puestos durante años (normalmente hasta la quiebra de la empresa).

La clave de este misterio está en el proyecto bicicleta.

Grosso modo, las fases de un proyecto bicicleta son: Análisis de requisitos, diseño, implementación, fase de pruebas, entrega, revisión. En la fase de análisis de requisitos el cliente informa de lo que desea, en la fase de diseño se da forma al producto, en la fase de implementación se codifica, en la fase de pruebas se comprueba que todo haya ido bien. Las cuatro primeras fases pueden parecer las más importantes, pero en un proyecto bicicleta resultan ser del todo prescindibles. Se deja todo a la fase de revisión (que le suele tocar a uno).

En estas primeras fases nuestro amigo manager no trabaja (recordemos que simplemente es incapaz), tan sólo sale del paso. Hasta la fase de entrega no hay nada de que preocuparse, se trata de disimular. Pero claro, algo tangible hay que tener, algo que enseñar a la directiva en las reuniones. ¿De dónde se saca? Simplemente se baja de internet o se compra. Digamos que el cliente necesita un sistema de workflow, accesible por web y que sea escalable. Pues bien, se va uno a un buscador y se introduce “cheap web-based workflow system java source code download”. Se navega un poco, se busca un producto con colorido futurista, se saca la tarjeta de crédito, y voila. El proyecto bicicleta ya tiene forma.

A continuación nuestro amigo manager designa un equipo de desarrollo para las fases dos, tres, y cuatro. La experiencia le ha enseñado que para proyectos bicicleta se deben escoger desarrolladores cuanto más lerdos mejor, para que no se den cuenta del pastel (aquí se sigue el principio del “traje del emperador”).

Podemos empezar a sospechar que en la mesa de al lado se esta cociendo un proyecto bicicleta cuando el equipo de lerdo-desarrollo juega al 69 profesional. Se intercambian comentarios-perla muy pomposos, tales como “los canales de intercambio de información son muy limpios”, “el factor usabilidad es determinante en el diseño de los javabeans”, “ya he incrementado el número de parámetros del constructor, te mando el punto class por mail”, o “este JSP tiene tres mil líneas porque he aplicado un patrón FACADE de acceso concentrado”.

Dos meses después llegamos a la fase de pruebas. Obviamente el producto es una mierda. Pero las pruebas corren a cargo del mismo equipo, y los niños de uno nunca son feos. Así que con la cabeza bien alta, se prepara un zip, un manual de instalación, y entrega tú, Carlitos, que a mí me da la risa. ¿Estado del proyecto? Entregado. Viernes noche. Cena de proyecto. Aplausos, risas, más 69. El lunes llegarán las sorpresas.

Ilustremos la fase de revisión con un ejemplo gráfico:

El proyecto porsche

Llega el lunes y uno abre el correo. Subject: “Incidencias en el proyecto Porsche”. Te requieren “un par de días” para “echar una mano” con “unos bugs”. Reunión dentro de quince minutos.
Entras al despacho. Ahí esta nuestro amigo manager. Te explica la historia: el proyecto Porsche es uno de los más punteros de la empresa (uno sospecha que es puntero a null). Se han aplicado novedosas técnicas de diseño e implementación y se ha conseguido entregar un producto perfectamente acorde a los requisitos del cliente: un porsche descapotable, seguro, ligero, veloz, de bajo consumo y de bajo coste. Se ha hecho rápido y bien. Un éxito. En la fase de revisión han surgido unas pequeñas incidencias que hay que revisar.

Bien. Vamos a ver la maravilla. Entramos al hangar del proyecto porsche, y ahí está la criatura: una bicicleta. De paseo. Sin cambio de piñón ni nada. Lleva una pegatina detrás del sillín con el logo de la empresa y la palabra “PORSCHE”. En la cesta va un certificado de AENOR. Aquí uno normalmente monta en cólera y empieza a gritar que quiere ir a hablar con el director, los socios fundadores, los clientes, los accionistas, el papa de Roma. Uno quiere ver a alguien colgado en la plaza pública.

Lo que sucede acto seguido es que a uno le llevan a un despacho en recursos humanos y le aplican de nuevo el método combinado “Ludovico/Habitación 101″. La chavala de RRHH, que se suele llamar Maika o Ivon y va vestida con ese traje de pantalón negro y tacones estilo mujer corporativa con master en dirección de empresas, nos interroga con voz de Valium 500:

[Ivon] Señor Fuckowski, ¿cuáles son sus quejas respecto al proyecto porsche?

[yo] ¿¿¡PERO QUE PORSCHE!??

[Ivon] El proyecto porsche, uno de los mas punteros en…

[yo] ¡¡Que sí, que sí, que me sé la película!! ¡¡Pero es que “eso” es una bicicleta, y se supone que tengo que convertirla en un porsche en dos días, y me han dado un destornillador y un bote de pintura!!

[Ivon] Señor Fuckowski, es cierto que el porsche presenta algunas incidencias, pero..

[yo] ¡¡BICICLETA!! ¡¡BICICLETA!!

[Ivon] Señor Fuckowski, ¿está atravesando una crisis personal? Debe haber una razón para su postura negativa acerca del porsche.

[yo] No. Estoy perfectamente. O lo estaba, hasta que vi la bicicleta.

[Ivon] Habitación 101, señor Fuckowski .

Habitación 101. Silla con correas. Camisa de fuerzas. Logos de la corporación. Certificaciones de calidad. Proyector XGA. Pantalla panorámica que muestra una enorme bicicleta de paseo. Allí nos espera el director de la empresa.

[director] Señor Fuckowski, describa usted este porsche.

Me ahorraré los detalles de la tortura, pero implica disertaciones sobre la actitud positiva, la creencia en la visión de la empresa, la auto motivación, la letra pequeña del contrato. En definitiva, que si no ves el porsche vas a la calle.

Después del almuerzo ya está uno perfectamente motivado, asistiendo a una conference call entre la empresa, representada por el manager, y el cliente, representado por un consultor con traje negro y corbata chillona, contratado ayer, que cobra 100 euros la hora mas dietas, y al que no le interesa decir “meteos la bicicleta por donde os quepa” y cobrar 25 euros por quince minutos.

[consultor] Bien, vamos a clarificar las incidencias respecto al porsche. Lo primero que hemos notado es que le faltan dos ruedas.

[manager] Sí, hemos optado por el diseño minimalista que va con nuestra visión de empresa: “práctico, funcional, óptimo”.

[consultor] Ya veo. Pero un porsche con dos ruedas no casa con nuestro modelo de negocio. Lo necesitamos de cuatro ruedas.

[manager] Creo que podremos refactorizar el porsche y hacer un clone para añadir dos ruedas extras, ¿cierto? -me mira a mí

[yo] ¡¡Sí, jajaja!! ¡¡Chupado!! Dame una hora.

[consultor] Perfecto. Bien, la segunda incidencia. No encontramos la capota.

[manager] Sí. Lo querías descapotable, ¿no?. Pues hemos simplificado mucho la usabilidad retirando la capota.

[consultor] Bien, pero no sólo la queremos quitar, también la queremos poner.

[manager] Ah. Eso no está especificado en los requisitos iniciales, así que lo consideraremos funcionalidad extra y lo cobraremos por separado. ¿Que impacto tiene este nuevo requerimiento en el sistema? -me vuelve a mirar.

[yo] Afortunadamente los interfaces están muy limpios, así que podremos modificar la capa externa sin impacto en el kernel, jajaja.

[consultor] Perfecto. Otra cuestión, ¿dónde están el contacto y la llave? Cualquiera podría robarnos el porsche.

[manager] Hemos optado por el modelo multiusuario para la implementación inicial, pero podemos añadir un módulo de seguridad al sistema, ¿no?

[yo] ¡¡Siiii!! ¡Precisamente tengo aquí un módulo de encriptación SSL para porsche!

[consultor] Brillante. Sólo dos incidencias más. Se requiere demasiado esfuerzo al usuario para completar tareas con el sistema. ¿Podrías cambiar los pedales por un motor?

[manager] En principio queríamos dar la máxima libertad de acción al usuario, por lo que hemos optado por un modelo de cliente pesado.

[consultor] Bien, pero consideramos excesiva la cantidad de trabajo que se deja al usuario.

[manager] Podemos llegar a un compromiso razonable entre la libertad del usuario y la automatización de procesos, ¿no es cierto?

[yo] Indudablemente. Sustituiremos el motor de giro asistido por pedales por uno compatible asisitido por pistones. Quizá requiera añadir un módulo de almacenamiento externo para combustible, pero siempre lo podríamos poner en la cesta, jajaja.

[consultor] Estoy contigo al cien por cien. La última: el sistema no ha superado las pruebas de rendimiento. En los requisitos consta que el sistema debe alcanzar los doscientos por hora.

[manager] El rendimiento siempre puede variar dependiendo de la plataforma. Las especificaciones de este sistema son “carretera de hielo con un 70% de pendiente descendiente”.

[consultor] Bien, verificaré qué plataforma estamos utilizando en explotación. Pero creo que vamos a necesitar más velocidad.

[manager] Siempre podemos afinar el kernel, ¿no es cierto?

[yo] Cierto como que me llamo Fuckowski.

[consultor] Muy bien, caballeros. Ha sido un placer.

Tres de la mañana. Un termo de café. Un cubo de pintura, un destornillador. Y una bicic.. un porsche.

¿Cuál es la parte más difícil del trabajo de un desarrollador de software? ¿La arquitectura, el análisis funcional, el técnico, la programación?

No. La parte dura de verdad es tener que oír gilipolleces.

Uno recibe un mail del IT manager, ese individuo que según currículum ha “colaborado en la conceptualización de proyectos de convergencia” y ha sido “director de expansión de estrategias de cuarta generación”, y cuyo trabajo consiste en reenviar los emails de los clientes a los técnicos y viceversa, y leer cosas en internet para tener algo que decir (con Google y un par de reglas de outlook ya se podía ahorrar la empresa 80.000 euros al año). El mail lleva por subject “Brainstorming”. Ahí ya estás bien jodido.

El “brainstorming” o “tormenta de cerebros” es (o debería ser) la reunión en la que todos aportan su talento y experiencia para encontrar soluciones óptimas a problemas. La realidad es que en la tormenta de cerebros, el manager suele poner la tormenta y tu tienes que poner el cerebro. Y en la tormenta, como en el río revuelto, la ganancia es para los pescadores. Tu piensas, diseñas y solucionas, que para algo querías ser ingeniero. El se apunta el gol, que para algo hizo un master en “strategy business janderklander”.

Así que uno llega a la sala de reuniones con la mosca detrás de la oreja. Ahí está él, con el portátil, la taza de café, y un montón de papeles (normalmente emails de los clientes con sus requisitos, es decir el problema en sí mismo, y ni un solo folio extra que indique que se ha dedicado algo de tiempo a solucionar nada).

Ya sabes a lo que te expones una vez más. Te van a preguntar el consabido “y ahora que hago” pero sin que se note. De soslayo. Como si tu fueras imbécil. Pero no queda ahí la cosa: vas a ser el conejillo de indias con el que poner a prueba los últimos discursitos aprendidos en los foros o “cookbooks”, para que los valides o rechaces, los corrijas, y en definitiva ayudes a perfilar esa superficial sabiduría, ese “arte de aparentar tener razón” (véase Schopenhauer) con la que estos individuos justifican sus desorbitados salarios ante la directiva (que normalmente no suele saber distinguir una churra de una merina).

Así que te lo tomas como algo personal. Se trata de dejar claro que:

A) Una churra es una churra y una merina es una merina, es decir, una idea es una idea y una gilipollez es una gilipollez, y uno sabe distinguirlas.

B) Se puede hacer demagogia hablando del sexo de los ángeles o quizás de pintura abstracta, no de software.

C) no se aprende en un foro en una hora lo que le ha costado a uno varios añitos de carrera, otros cuantos de trabajo, mucho café y muchas horas extras.

D) Un inútil con un libro no es un ingeniero.

E) Un master, una corbata y una PDA hacen juego, pero no proporcionan sentido común al que carece de él.

Total, que empieza el circo. Abróchense los cinturones. Aférrese uno con fuerza a sus principios, porque le van a aplicar el método Ludovico (véase La Naranja Mecánica). Le van a inmovilizar en una silla, a administrar una droga, a colocar unos soportes en los párpados, y le van a obligar a visionar dos horas de Power Point. Le van a someter a uno a espantosas torturas psicológicas con el doble objetivo de sacarle información, y a la vez convencerle de realidades alternativas.

A continuación reproduzco fragmentos reales (palabra de honor) de reuniones con mi actual IT manager acerca de varios proyectos Java y VB en los que “hemos” trabajado.

Perla 1: Hibernate

[manager] ¿Qué utilizamos para la capa de datos?

[yo] Usemos Hibernate

[manager] Es mejor usar Entity Beans

[yo] ¿Por qué?

[manager] Entity Beans son J2EE estándar, y además están en un pool, Hibernate no tiene pool así que va mas lento.

Cuando quise explicarle la burrada que había soltado, eran tantas las ideas que se me vinieron a la cabeza de golpe que sufrí un shock y tuve que ir a por un vaso de agua. Creo que esto es una técnica deliberada de argumentación, que debería denominarse “tan gorda es la burrada que no se puede rebatir”. Si alguien dice que “dos y dos son cinco”, se puede argumentar que son cuatro. Pero si alguien dice que “dos y dos son una constelación cercana a Alfa-Centauri”, sólo se puede rebatir “¿pero de qué estás hablando?”, y te pueden replicar “Cómo se nota que no has hecho un Master Janderklander”.

Perla 2: Easy Upgrade

Aquí estábamos reunidos con unos clientes americanos a los que les habíamos vendido una aplicación (por llamar de alguna manera a ese desastre programado por un “Senior con 10 años de experiencia” y que yo tuve que mantener posteriormente). El proceso de instalación consistía en descomprimir un ZIP en el disco duro y luego ejecutar un Setup.exe (no funcionaba instalando desde CD). El zip incluía los ficheros de la base de datos. Cada vez que les dábamos una nueva versión, si no querían perder los datos anteriores tenían que renombrar la base de datos antigua, instalar la versión nueva completa (la base de datos nueva había que instalarla también forzosamente, porque parte de la lógica y los recursos de la aplicación residían en ella -no me pregunten por qué, pregúntenle al “senior”-), y luego importar algunas tablas mediante scripts (me costó una semana que el técnico de la franquicia japonesa lo realizara correctamente).

[cliente] ¿No podríais simplificar el proceso de instalación?

[manager] Si, vamos a crear un proceso de instalación que al inicio haga un diff como en Source Safe e instale sólo lo que se ha modificado o añadido.

Me quedé pensando si este hombre sabría que el código fuente se compila.

Perla 3: Interfaces mágicos

En esta reunión me estaba pidiendo que diseñase un portal (una especie de carrito de la compra con los servicios de la empresa), y que para ahorrar tiempo nos atuviésemos sólo a las necesidades y especificaciones del primer cliente al que le habíamos vendido la moto.

[yo] Pero, si creo el portal específicamente para un cliente, no vamos a poder reutilizar el código. ¿Quieres que diseñe la lógica de negocio de forma genérica, aunque me lleve mas tiempo?

[manager] No, no tenemos tiempo.

[yo] Pues cuando tengamos un segundo cliente, vamos a tener que hacerle otro portal diferente

[manager] No, reutilizamos lo que hagamos ahora

[yo] Entonces, lo hago genérico, ¿no? Mas tiempo…

[manager] No, hazlo específico, pero teniendo en cuenta que lo vamos a reutilizar

[yo] A ver, explícame con qué técnica creo algo rápido y especifico pero reutilizable

[manager] Simplemente, mantén tus interfaces limpios

Me pregunté si no existiría un “Mr.Proper design pattern”. Luego intenté que me aclarase cómo se hace una lógica específica que implemente un interfaz válido para todo el mundo, y que si conseguíamos el milagro (algo así como definir un estándar tipo JDBC y crear diferentes drivers), al final íbamos a reutilizar nada más que el interfaz (¿media hora de trabajo?) así que estábamos en las mismas. Su discurso de respuesta es irreproducible.

Perla 4: Override autoincremental keys

Ésta vez se trataba de diseñar una lógica de negocio transaccional que operaba sobre dos sistemas diferentes, un workflow y un software de presupuestos (ambos con su API). Había que relacionar ambos de forma que cuando un cliente solicitase un presupuesto, se crease una tarea nueva en el workflow y un presupuesto nuevo asociado a ella.

[yo] Pues tenemos que crear un método que empiece una transacción, añada una tarea al workflow, se quede con el ID, luego añada un presupuesto, se quede con el ID, guarde la relación entre ambos en una BD, y haga “commit”

[manager] Para ahorrar tiempo vamos a hacer que el ID de la tarea y el ID del presupuesto sean siempre iguales, así no tenemos que relacionarlos
(esta sola podría ser la perla 4, pero no, aún hay mas)

[yo] Primero que aunque pudiéramos especificar nosotros las claves, necesitaríamos saber que Ids’s hemos usado ya para generar los nuevos, lo que es más costoso que el relacionar dos Id’s. Pero además resulta que las claves no podemos especificarlas nosotros, en el sistema de workflow y en el de presupuestos, las claves son campos autoincrementales

[manager] Pero hay un mecanismo en los Entity Beans que permite especificar las claves de los registros que se insertan.

Después del shock empecé a imaginarme el mecanismo:

EntityBean: InsertTaskWithKey(55)
DataBase:SQLException:KeyViolation
EntityBean:QueTeHeDichoQueInsertTaskWithKey(55)
DataBase: Bueno Vale.

Perla 5 - Java Word Parser

En ocasiones los usuarios del mencionado portal de servicios suben ficheros en formato Word para que la empresa (que principalmente se dedica a la localización de contenidos) los traduzca a diferentes idiomas. Se necesita estimar el coste de la traducción automáticamente, para entregar un presupuesto al cliente de forma inmediata. Simplemente hay que contar el número de palabras en el documento y multiplicarlas por el precio por palabra establecido.

[manager] ¿Cómo podemos automatizar los presupuestos?

[yo] Tengo que buscar alguna librería java de parseo de archivos doc, integrarla convenientemente en el portal, y crear una función que me devuelva el número de palabras.

[manager] Vamos a hacer algo más rápido. Podemos reutilizar las macros de Word que tienen en el departamento de Evaluación.

Fácil. Sólo necesitamos un “Enterprise Word Server” que pueda correr sobre Solaris, que se pueda instalar en cluster, y al que se pueda acceder por RMI.

Espero que el mundo comprenda mi sufrimiento. Hasta la próxima entrega.