Office Space: Trabajo Basura (II: oír gilipolleces)

Un amigo me ha enviado un mail con un artículo bueníssimo. Brutal. Aún estoy descojonándome.

Ahí va:

¿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