... and you will be assimilated
-
SAP
Qué es SAP?
Si observamos la definición en la wikipedia: SAP veremos que SAP es el acrónimo de Systeme, Anwendungen und Produkte (Sistemas, Aplicaciones y Productos).
Pero Dani Martínez (gran experto en temas de SAP MM i FI) y yo teníamos otras versiones:
- SAP: Secta de Adictos al Poder
- SAP: Sociedad de Alcohólicos Privados
- SAP: Sociedad del Altruismo y la Prostitución
- SAP: Sois Astutos y Putas (hablando de programadores)
- SAP: Sociedad Aberrante de Puercos …
Escribe la tuya!
-
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:
<blockquote>
¿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
</blockquote> -
Office Space : Trabajo Basura
El trabajo es una mierda (Work Sucks).
Qué gran verdad. Recientemente he cambiado de trabajo. Me pagan mejor, hago menos horas, y dices ah! de puta madre no? pues no. Echo de menos a los compañeros del antiguo trabajo, no me he acabado de adaptar al nuevo y tengo la sensación de que no me tienen confianza. En cambio en el otro trabajo tenían una percepción muy buena de mi (o almenos a mi me lo parecía).
Antes trabajaba para DMR Consulting en la “Agència Catalana de l’Aigua”. Ahora para SERTEC en KNOSOS. He ganado además en que puedo tocar temas más relacionados con lo que he estudiado (por ejemplo me dedico a desarrollar un servidor entre la red TETRA y unos servicios de posicionamiento propios de Knosos).
Hasta ahora,Factores positivos:
- Más sueldo
- Menos horas
- Temas más interesantes
Factores negativos:
- Perdida de confianza
- Sólo programo.
Y es eso, eso es lo que hecho más de menos, no tengo trato con el cliente, no tengo demasiado criterio para decidir, no me tienen como un aliado sino como un picador. Igual me equivoco, pero me parece que es bastante triste, que dada mi experiencia previa, no me hagan hacer otra cosa. Lo achaco al proyecto que es bastante jodido, pero, espero que un futuro la cosa cambie, si no gano en confianza y cotinuo picando más que los mineros, esta empresa no es la mía.
O no?
-
Parecidos Razonables
Hallo leute! Guten Tag! (Buenas gente! Buenos días!)
Pues si, resulta que una vez elegido el título y la plantilla del blog me aparece esto:
- Resistance is futile Por si no lo sabeis, estuve 8 meses en Alemania, haciendo el proyecto fin de carrera en PhilpsForschungsLaboratorien en Aachen, soy teleko, por cierto. Y el dato curioso es que el tipo que aparece en la foto debajo de la bienvenida (Herzlich willkommen) se parece un poco a un alemán que conocí durante mi estancia. Quiera Dios que no sea él, si no me muero del susto.
Coincidencias. Ya haré algunas entradas más sobre las coincidencias, es un tema que me interesa bastante.
Otros blogs menos simpaticos (a mi modo de ver són):
- Resistance is futile - Maybe (verisón canadiense) - Resistance is futile (verisión de oregón, toma pareado) - Resistance is futile (versión ?) un tio un poco cargante la verdad que ni se presenta siquiera y además està discontinuado desde el 2003.
- Resistance is futile (versión gilipollas) o sea que el señor que tiene el nombre tal qual tiene que ser, no publica desde el 2003… muy correcto.
Bis Bald! (Hasta pronto)
-
Deutschland 2006: Rumbo al Mundial
Sí señores, nos vamos con los colegas a ver un partido de cuartos de final a Alemania!!!
Dónde?
Cuándo?
Por qué? Por que Alemania mola. No en serio, es una oportunidad de ver en vivo y en directo un partido de un mundial, además conocemos un poco Alemania por haber hecho el proyecto allí (unos cuantos de nosotros) y hemos visto la oportunidad de volver.
Ya os iré informando de cómo esta todo, de entrada tenemos reunión de crisis este domingo. A ver como nos lo montamos, por ahora las opciones són:
- Frankfurt - Gelsenkirchen Estaréis informados.
subscribe via RSS

