Sobre la arquitectura de eBay

En InfoQ (me encanta este sitio) publicaron hace unos días una entrevista a Dan Pritchett sobre la arquitectura de eBay. Se trata de una entrevista muy intersante, mucho más desde que el año pasado se desvelera que eBay evita las transacciones en dos fases siempre que sea posible tratando de mantener el acceso a datos muy simple y rápido aún a riesgo de perder datos (no importantes). Martin Fowler también escribió en su momento sobre esto.

Recojo aquí las notas que me parecen más importantes sobre la entrevista:

• No todos los datos tienen la misma importancia. Llegado al punto en el que escalar se hace extraordinariamente caro y complejo hay que buscar soluciones que se apartan de los patrones tradicionales. A veces estas soluciones implica asumir riesgos de perder datos y evitar las transacciones distribuidas. No pasa nada mientras estos datos no sean críticos para el negocio.


• Uno puede sentirse incómodo con el punto anterior, pero a medida que investigas en como lo hace otra gente que ha afrontado el mismo problema descubres que todo el mundo llega por diferentes caminos a la misma conclusión.


• Uno llega a plantearse la necesidad de una base de datos en algunos casos. Hoy por hoy se utilizan para todo, pero ¿por qué no usar un sistema de ficheros? Hay muchos datos no críticos que pueden almacenarse en otros lugares que permitan un acceso más simple y rápido.


• La escalabilidad no tan sencilla como aparece en los libros: horizontal y vertical. Hay otros factores. Hay que ser capaz de escalar procesos; de sobrevivir al aumento de branches, de desarrolladores o de builds. Hay que ser capaz de escalar los data centers; de conseguir maximizar el número de transacciones por watio consumido.


• Los patrones y principios son necesarios, pero a veces hay que saltárselos. Los patrones que funcionan para sitios normales no tienen porque funcionar necesariamente para sitios que reciben billones de visitas.


• 30 arquitectos para 1500 desarrolladores (in-house). No todos los problemas reciben la atención de un arquitecto. Se delega mucha responsabilidad sobre los desarrolladores. Sólo se asignan arquitectos a tareas que lo requieran.


• Para gestionar todo el desarrollo existen catálogos bien definidos de principios y patrones a aplicar, junto con un repositorio de reglas que se deben seguir para cada servicio. Los desarrolladores deben ser capaces de aplicar el catálogo de patrones correctamente y de solucionar problemas complejos utilizándolos. En caso de tener que romper algún patrón o regla, un comité decide si es apropiado y da el visto bueno.


• Arquitectos que se manchan las manos. Arquitectos que escriben código y que contribuyen al esfuerzo del grupo. Arquitectos que se ganan la credibilidad del resto de desarrolladores a base de código y hechos; no sólo palabras.


• Involucrar a todo el mundo en las reuniones técnicas. Desarrolladores, arquitectos, operaciones, analistas de negocio. Todo el mundo aporta su punto de vista, y todos estos puntos de vista son necesarios a la hora de afrontar un problema de manera efectiva.

Para mi, la mejor entrevista sobre arquitectura que he leido en lo que va de año.

Operaciones aritméticas y strictfp

Una de las palabras reservadas en Java que seguramente sólo verás cuando te estás leyendo un libro básico sobre Java es strictfp. La lees, y te olvidas. Nadie te va a pedir que la utilices mientras estudias y probablemente nunca te la encuentres en el trabajo.

Sin embargo hay ocasiones en las que te encuentras que dos operaciones aritméticas no dan el mismo resultado de repente en JRockit sobre Sun Solaris que en la VM de Sun sobre Windows. mmm ¿qué diablos pasa?

Básicamente, hasta Java 1.2 las operaciones en coma flotante eran predecibles. Todas se realizaban siguiendo el estándar definido por el IEEE y los resultados eran los mismos bajo cualquier implementación de Java, bajo cualquier plataforma, y compatibles con los resultados de cualquier otro lenguaje que siguiese el estándar definido por el IEEE.

La contrapartida a esto era que las operaciones de coma flotante eran muy lentas, ya que se deben forzar una serie de restricciones por ejemplo en cuanto a overflows, y Java no era competitivo. Así que se decidió dejar de forzar la compatibilidad con IEEE para conseguir un aumento de rendimiento, dejando como opcional la compatibilidad. Para forzar que las operaciones sean compatibles con el estándar IEEE se tiene que utilizar la palabra reservada strictfp. En este enlace lo explican muy bien.

Sobre la caida de Skype

Según me han comentado en el trabajo y he podido leer después, parece que una de las cosas que me he perdido mientras estaba de vacaciones ha sido la caida de varios días de Skype (huy que pena). En varios sitios web se hacen eco de las causas y lo complicado que es restablecer el servicio de manera rápida en una red P2P como Skype:

How Skype network handles scalability
Skype Failed the Boot Scalability Test: Is P2P fundamentally flawed?
What happened on August 16 (explicación oficial)
The Microsoft connection clarified (clarificación de la explicación oficial)
Skype Outage Highlights How Skype Is A Bit More Centralized Than Expected

Como plantean los dos primeros enlaces las arquitecturas descentralizadas plantean problemas que no han sido resueltos todavía.

The overview of this is as follows:

Skype introduced a flaw into the network that dealt with "routing" and "fucked" the "decentralized data store aka DHT” this in turn ran clients on a RANDOM search of Supernodes which at this point were well booted off of the network.

In the End:
It is a huge cycle, no matter how many bugs they "fix" in the "central servers" it will take many days for N nodes to become Supernodes so they can route X data from peer A to peer B. This is NOT minor, a fix to the centralized server code base to relay data to N Supernodes there is lack there of, resulting of a very segregate network. Right now there are approximatly 10,000 sub Skype networks instead of 1 Single "in sync" network. When this "data store"(see DHT) is in sync globally then the Skype network will be again STABLE.

Problemas como el del 16 de Agosto sacan a relucir los problemas de este tipo de arquitecturas descentralizadas y la dependencia de miles de nodos que no controlas, pero sin duda también ayudan a mejorarlas ya que seguramente los desarrolladores de Skype están ya trabajando para que no suceda de nuevo algo parecido, ya que una nueva parada podría afectar seriamente a su credibilidad.

Entrevista a Joel Sposky

Tras las vacaciones me he puesto a repasar los blogs y publicaciones que sigo. Una de las cosas más interesantes que me he encontrado ha sido esta entrevista a Joel Sposky publicada en el número de Julio/Agosto de la revista ACM Queue.

La entrevista toca múltiples temas, aunque el hilo central siempre es el famoso blogger. Hablan sobre su historia, sobre los diferentes trabajos por los que ha pasado y lo que opina de ellos, sobre la experiencia de crear su empresa y como ha ido evolucionado, y sobre otras cosas.

Me ha parecido interesante.

De vuelta de vacaciones

Todo lo bueno se acaba.

Dos semanas de vacaciones que me han servido de desintoxicación ya que no me llevé el portátil conmigo. Hoy he vuelto al trabajo y comentado con los compañeros lo malo que ha sido el tiempo en Galicia. La verdad es que las vacaciones ha sido como estar por casa, porque la mayoría de los días ha estado lloviendo, aunque bueno, al menos sí que teníamos unos tres graditos de más.

Entre las cosas que he hecho en vacaciones, pues sobre todo comer. Vengo con tres quilitos de más, que no está mal para un par de semanas. Un amigo mio ha subido un video sobre el Globo de San Roque, que se lanza todos los años en Betanzos, y que me perdí el año pasado pero este año no lo perdoné. Otra que no se perdona es la romería de los Caneiros. Lo mejor de esto de la era digital es que puedes encontrar montones de videos de eventos de los que antes era imposible encontrar algo. Así que aprovecho para difundir los eventos locales :-)

Cerrado por vacaciones

Mañana nos marchamos de vacaciones por un par de semanas, así que este chiringuito estará cerrado hasta la vuelta, que será allá por el 28 de Agosto. La verdad es que ya estaban tardando. Muchas cosas que hacer, amigos y familia que visitar; muchos platos ricos que echamos de menos, y mucha comida que traer.



Por si a alguno le intriga, pues entre los planes están el el ir a la playa, disfrutar de las fiestas de Betanzos y Coruña, de el Globo de San Roque (foto arriba) y de los caneiros (foto abajo, recogida del blog local el pasatiempo). Habra alguna boda, churrascada y espero que muchas cosas más.



¡Os leo en dos semanas!

ArcCast.TV y La arquitectura de PlentyOfFish

En la historia de este blog, y de los cuatro años y medio bloggeando creo que el de PlentyOfFish ha sido el más exitoso. Barrapunteado y referenciado en varias webs, incluso indirectamente, trajo realmente un montón de tráfico que no me esperaba.

Chorradas aparte, hoy he descubierto una web de Microsoft que parece merecer bastante la pena (aunque le de bombo a Microsoft :D). Se trata de ArCast.TV, un canal dedicado a la arquitectura de sistemas y que aunque está orientado sobre entornos Microsoft pues da la impresión que se pueden filtrar bastantes cosas neutrales.

Hace una semana entrevistaban a Markus Frind, el creador de PlentyOfFish, y de la entrevista se pueden sacar algunas conclusiones interesantes y que explican como es capaz de competir teniendo un único empleado (él) con compañías que tienen cientos. Quizás la mayor clave que extraigo es que al ser una compañía que ofrece un servicio gratuito, la calidad no tiene por que ser como la que se le exige a otros servicios por los que pagas una subscripción. Por ejemplo, Markus comenta como si su sitio se viene abajo, nadie va a protestar porque esté un día caido, a fin de cuentas es totalmente gratis. Lo mismo pasa con el soporte y funcionalidades, nadie le va a exigir que cambie ciertas cosas, o que añada funcionalidades, o que conteste a las preguntas. Bueno, esto no es cierto, sí se lo van a exigir, pero a fin de cuentas lo que ofrece es gratis así que el que no esté contento con el servicio que recibe siempre puede irse a una alternativa de pago.

Por cierto, parece que se ha cansado de estar el sólo y está buscando por fin tres senior software developers.

Por seguir con el tema, en High Availability han recopilado los diferentes posts de su weblog para ofrecer un resumen de la arquitectura de este sitio. Los números son, como era de esperar, impresionantes: +30 millones de visitas diarias; 1.1 billones al mes, top30 en US/UK y top 10 en Canadá;1 Tb y 171 millones de imágenes servidas por Akamai al día.

Pero la mejor, la mejor, la mejor: 6 millones de dólares al año trabajando dos horas diarias. Bueno, personalmente no me lo creo demasiado ya que es evidente que aunque la arquitectura sea simple, hay muchísimo trabajo detrás de este producto. De otro modo, ¿para qué necesitaría tres senior developers :-)?

En fin, para cerrar esta inspiradora cita que no voy a estropear:

You don't need millions in funding, a sprawling infrastructure, and a building full of employees to create a world class website that handles a torrent of users while making good money. All you need is an idea that appeals to a lot of people, a site that takes off by word of mouth, and the experience and vision to build a site without falling into the typical traps of the trade. That's all you need :-)

Hadoop, su "competencia", y un poco de verguenza ajena

Hace meses, solía echarle un vistazo muy de vez en cuando a un foro sobre CMS que parece que lo seguían bastantes comerciales. Cada vez que una persona hacía una pregunta, todos los comerciales iban poniendo una respuesta en la que en lugar de contestar a lo que el usuario preguntaba pues exponían las maravillas de su producto y dejaban sus datos de contacto.

Hoy, he recordado ese foro leyendo una entrada en InfoQ en la que destacan el momento del que parece disfrutar este producto Open Source y que ya comentaba hace unos días.

A mi, personalmente, me resulta bastante desagradable el que propongan un tópico para debatir en torno a Hadoop y que inmediatamente salten los banderas de otros productos comerciales a hablar de sus productos, sin siquiera ceñirse a lo que el editor ha propuesto en la entrada. Me parece una actitud un poco de mal gusto y propia de productos de segunda clase.

Sin embargo resulta bastante curioso que los productos que se anuncian en este caso sean tres de los más importantes en su sector: Terracotta, Oracle Coherence y GigaSpaces. y es que además la relación entre Hadoop y estos tres productos tampoco es clara. Mucho me temo que la competencia entre ellos ahora mismo es tran grande, que uno de ellos escribe algo e inmediatamente han saltado los otros dos a promocionar sus productos.

En fin, que a mi personalmente me hubiera gustado que alguien hablase sobre Hadoop y no tener que leer esa publicidad barata, por muy bueno que sea lo que se publicita.

Tus vecinos, los del Open Source

No es novedad, porque es algo que ya pusieron hace mucho pero quizás alguno no conozca todavía que ohloh la web social de proyectos Open Source se integra con Google Maps, así que puedes averiguar si tus vecinos participan o no en esto del Open Source.



Por lo de pronto la imagen de Irlanda es algo decepcionante, aunque está claro que mucha gente o no se ha dado de alta o no ha actualizdo su perfil con su geo-localización.

He añadido a mi ya de por sí sobrecargada columna derecha mi calificación, que aunque no es de las más altas (1000 y pico) estoy muy orgulloso de mi ocho -evitar los chistes :-)

Un servidor poco habitual: PS3

Leyendo la noticia en DataCenterKnowledge no puedo más que referenciarla, porque es de lo más curiosa y eso que no quiero convertir esto en un blog de data centers.

Resulta que en el blog de Playstation han desvelado como es el data center de su juego online Warhawk y sorpresa, sorpresa, resulta que está formado de unos servidores poco habituales: PlayStations 3.

La idea es que habrá numerosos clusters en diferentes ciudades para hacer que los jugadores tengan la latencia más baja posible, e incluso abren la posibilidad de utilizar la playstation de cada jugador como servidor creando gigantescos clusteres distribuidos. Como comentan en DataCenterKnowledge, el que esté al día en cuestión de chips (que no es mi caso) no se extrañará de esto ya que el chip de la PlayStation 3 ya se está utilizando en los blades de IBM y en mainframes sus System Z.

Me imagino que lo mejor de estos data center es que siempre te puedes pasar a echar una partida :-)

Dentro de los datacenters de eBay y Amazon

En CRN han publicado un resumen de las keynotes de eBay y Amazon en la Next Generation DataCenter Conference.

Las conclusiones son más o menos las de siempre, ambas compañias apuestan por la virtualización, amazon hace publicidad de sus servicios (además presentó en sociedad su nuevo payment service), eBay recalca la importancia que tiene para ellos sus datacenters con los billones de SQLs por día que ejecutan, etc.

Siempre es interesante leer sobre estos gigantes así que aquí queda por si a alguien le interesa.

Hadoop toma protagonismo

Parece que uno de los proyectos que han tenido bastante éxito en la OSCON 2007 ha sido Hadoop, un subproyecto de Apache Lucene que implementa el conocido algoritmo de MapReduce utilizando su propio sistema de ficheros distribuido.

Tim O'Reilly ha publicado un extenso artículo sobre esta librería y la importancia de que Yahoo esté detrás de ella. En particular destaca la importancia de que Yahoo escoja el camino de contribuir al Open Source y respaldar proyectos exitosos como Lucene como base para las herramientas que utiliza, en lugar de seguir el camino de hacer desarrollos internos, que es el aparente camino que sigue Google (no quita que haya liberado interesantes frameworks).

Aún así el creador de Lucene y Hadoop, y ahora empleado de Yahoo, Doug Cutting, destaca que Hadoop no está limitado a la búsqueda ni tiene porque ser ese el escenario en el que rinde mejor:


"Where Hadoop really shines, is in data exploration." Many problems, including tuning ad systems, personalization, learning what users need -- and for that matter, corporate or government data mining -- involve finding signal in a lot of noise.

Y el artículo termina con un ejemplo de como utilizar MapReduce para afrontar la explotación de ficheros de log gigantescos.

El caso es que en la Yahoo Developer Network han publicado las charlas, powerpoints, video y audio de la presentación realizada en la OSCON y una entrada antes también hablan sobre la evolución del proyecto.

High Availability ofrecía un análisis hace poco sobre este producto. Y bueno, en casi todas estas fuentes referencian al artículo de Julio sobre como integrar Hadoop con Amazon Web Services.

Desde luego, parece que suena bastante. Por cierto, ¿a alguien le interesa jugar con Hadoop y Amazon? Un proyecto realmente interesante sería integrarlo con Apache Jackrabbit de forma que pudieses almacenar contenido de cualquier repositorio en un sistema de ficheros distribuido, como por ejemplo el de Hadoop, y que a su vez se volcase en un servicio como Amazon S3. Y además sería una contribución espectacular para jLibrary :D

Microsoft planea un datacenter de 500 millones de dolares en Dublin

Mientras hoy me levantaba con la prensa sensacionalista afirmando que parece que este año se perdian cientos de trabajo por semana y la pasada semana se conocía que Xerox terminaría 900 trabajos lo cierto es que el panorama no parecía optimista.

Sin embargo parece que Microsoft no opina así y sigue viendo a Irlanda como una gran zona para invertir. El domingo aparecía en el Sunday Business Post que Microsoft está ultimando la obtención del permiso para construir un datacenter gigantesco en Dublin inviertiendo más de 500 millones de dólares. El datacenter sería más grande que que la mitad del Dundrum Town Centre, que es el centro comercial de al lado de mi casa y os puedo asegurar que es realmente enorme (se supone que el más gran de Europa si alguna vez lo terminan).

Parece que el datacenter estaría en el suroeste de Dublin, en Grange Castle, Clondalkin. Microsoft tiene 1200 personas en plantilla y 700 freelancers en sus cuatro centros en Dublin.

Se ve que la gente todavía cree que Dublin es una de las mejores ciudades de Europa para trabajar.

El arquitecto "porque lo he leido"

Frank Kelly tiene una entrada muy buena en su blog donde explica como descubrir a los arquitectos "de pega", es decir, aquellos arquitectos de pequeños equipos técnicos que deberían ser muy técnicos para ser capaz de apoyar a su equipo y que por el contrario no serían capaces de ponerse a programar diez líneas de código seguidas.

Sería lo que Frank llama NCAs (Non-Coding Architects) y que otros han ido denominando Ivory Tower Architects, Astrounaut Architects y PowerPoint architects.

Leyendo esta divertida entrada me he acordado de algo que me pasó hace unos meses con un senior architect. En su momento me dejó marcado, lo dejé pasar, y ahora lo he vuelto a recordar. La conversación podría haber sido perfectamente así:

- Arquitectos en conversación normal: Tenemos que actualizar este EJB de sesión para que envie un mensaje al topic de eventos de sistema. Hay que controlar las transacciones.

... la conversación continua durante minutos exponiendo problemas, soluciones, etc. ...

- Arquitecto NCA: Al final estamos con lo mismo, esto es muy complicado. Deberíamos estar utilizando Spring y migrar a un servidor de aplicaciones Open Source. Y utilizar AOP. Oh, Spring es increible. Si utilizásemos Spring nos iría todo muchísimo mejor. Nuestra arquitectura es muy pesada. Sin Spring vamos a fracar, lo dice todo el mundo. Es lo mejor que ha ocurrido en el mundo desde el pan de molde.

¿Cuál es el problema? Aparentemente ninguno, ¿verdad? Tecnologías novedosas a la vez que asentadas, recomendaciones razonables. El problema es cuando semanas después en una conversación te sale:

-Yo: La verdad es que el otro día leyendo las novedades de Spring 2.0 pues resulta que ahora las transacciones son mucho más fáciles de definir y utilizar.
-Arquitecto NCA: ¿De verdad?
-Yo: Muchísimo, no sabes cuando en Spring 1.x tenías que definir que utilizabas el TransactionProxyFactoryBean, ¿te das cuenta?
-Arquitecto NCA: mmmmm ... no.
-Yo: Que sí hombre, cuando defines el bean.
-Arquitecto NCA: Bueno, no me hables de cosas tan concretas que es que yo nunca he utilizado Spring..
-Yo: huh

La verdad es que fue algo que en su momento me chocó muchísimo, porque esta persona tenía la capacidad de defender algo de una manera muy vehemente, tanto que prácticamente no te atreverías nunca a afirmar que esta persona no conocía realmente de lo que hablaba.

Supongo que esta sería una nueva clase de arquitectos peligrosos a unir a la lista. En este caso las recomendaciones suelen ser seguras (Spring, me pasó otro tanto con Hibernate) porque estas personas es mantienen muy al día de las tendencias. Pero en mi opinión es necesario tener algún conocimiento técnico de lo que se habla. Ya no voy a decir tener que haber programado en todo lo habido y por haber porque esto hoy por hoy es casi imposible; pero al menos leer algún libro, conocer su estructura técnica y crear alguna pequeña prueba de concepto me parecen tareas básicas antes de mojarte con algo. Si no tenemos tiempo para hacerlo, entonces otra persona del equipo lo debería hacer.

En mi opinión, no se debería promover vehementemente tecnologías que no se han probado o no se conocen profundamente, sólo porque todo el mundo hable de ellas y salgan en muchos artículos, aunque sea Spring :-)

Los usuarios reconocen el valor de las comunidades online

No recuerdo muy bien como pero ayer llegué a este estudio realizado por King Research en el que encuestaron a 203 profesionales del mundo de las TI este pasado mes de Junio.

Los resultados parecen avalar lo que todos los que participamos en comunidades técnicas intuiamos, que las comunidades técnicas online nos ayudan en nuestro trabajo. Algunos datos:

• El 93% de los encuestados afirman las comunidades les ayudan a hacer mejor su labor.
• El 100% afirma beneficiarse laboralmente y el 85% personalmente.
• El 98% afirma que la información disponible en las comunidades online es bastante fiable, pero muchos recalcan la importancia de contrastarla.
• El 70% de los encuestados participaba en comunidades relacionadas con su trabajo.
• La mayoría utilizan las comunidades para buscar soluciones a los problemas que se encuentran en el trabajo.

Bueno y todo esto viene a cuento de que estos días, tanto Jordi, como Dani hablaban en sus blogs sobre JavaConGanas, la última iniciativa de Alberto, que además probablemente es una de las personas con más experiencia en crear comunidades técnicas online en España.

A disfrutar de la web que vale la pena.

Categorías en IT dentro de Irlanda (y otros países)

Hoy un amigo me mandaba un curriculum para que opinase de como estaba traducido. Esto me recordó la entrada de hace unos días en la que preguntaba por dónde andaban las empresas de software, ya que se originó un debate por toda la blogosfera en donde todo el mundo hablaba de su categoría, de los años que había estado trabajando, etc. En esta entrada decía que tenía hablar sobre las categorías laborales en Irlanda, pues allá va.

Esta persona, en una parte de su curriculum ponía algo que creo que todos hemos puesto alguna vez:

2003..2005, Acme S.A., Analyst

¿Cuál es el problema? Básicamente que todas estas categorías tan curiosas que tenemos en España y a las que todos estamos acostumbrados, pues como que sales a fuera y no se llevan; bueno, como tantas otras cosas que sólo se nos ocurren a nosotros, como el pensar que con colegios se solucionan todos nuestros problemas o el querer pasar por encima de todo el que no haya estudiado una carrera, etc. etc.

Aquí no hay nada de Analista, Analista/Programador, Analista Funcional, Analista Orgánico, etc. De hecho, si dices que has sido Analyst, lo que se pensarán es que has estado trabajando de Business Analyst, lo que básicamente quiere decir que en tu trabajo no tiraste ni una línea de código, ni hiciste ningún diagrama UML ni cosas así. Simplemente que estuviste hablando con los clientes, manejando el email y escribiendo words, excels, y powerpoints, algo probablemente bastante diferente a lo que en realidad hiciste en España.

Si buscáis en cualquier web de trabajo de Irlanda, UK, o cualquier otro país importante de Europa, veréis que todos manejan más o menos las mismas categorías:

• Graduate: Recién salido de la universidad. Son los sueldos más bajos. Personas sin experiencia previa.
• Junior Programmer/Software Engineer: Algo más de experiencia que un Graduate, pero todavía con poca experiencia. Uno o dos años.
• Programmer/Software Engineer: Un poco más. Tres, cuatro años.
• Senior Programmer / Senior Software Engineer: Programador con bastante experiencia. Ya hablamos de +5 años, al menos. Estos pueden hacer también la labor de arquitectos si no existe tal rol en la empresa. También podrán crear diseños, dirigir técnicamente proyectos o tutelar a los programadores anteriores. Todo depende de como funcione la empresa y de la experiencia que éstos tengan. Un trabajo de Senior Programmer puede estar muy, pero que muy bien pagado. Eso sí, tienes que tener experiencia.
• Senior Architect: Aquí hay variaciones, porque aunque Senior Architect sea el rol más normal, también te puedes encontrar Technical Architect que designaría a personas que pueden tener menos experiencia pero que son muy, muy técnicas. Sea como sea, siempre empiezas a hablar a partir de 7 años de experiencia.
• Chief/Lead Architect: El máximo responsable técnico. Normalmente, al menos 10 años de experiencia.

Después ya pasas a los roles más de management o de negocio:

• Business Analyst (tb hay junior): Analizar requisitos, hablar con los clientes, recoger funcionalidades, y mucho excel, powerpoint, word y outlook. Normalmente es gente que tiene experiencia en el campo para el que se programa, ej. traders
• Project Manager: Dirigir el proyecto. Puede o no ser alguien técnico, dependiendo del resto de roles y estructura de la empresa.
• Software Development Manager: Estaría por encima del anterior, gestionaría varios grupos de trabajo.

Bueno, y ya después nos iríamos más arriba. Me tenéis que perdonar que me he concentrado en los roles de desarrollo dejando un poco a un lado los de bases de datos, sistemas, pruebas y calidad, operativo, etc. Es simplemente porque es de lo que más trata este blog.

En fin, ¿qué os parece? Es una estructura bastante clara, ¿no? Nada de roles raros ni cosas parecidas. Claro, ahora cuando uno busca en alguna web de empleo española y de pronto se encuentra cosas como Technical Architect, 1 año de experencia, conocimientos:todo y más, pues te da un poco la risa.

Por cierto, que se me olvidaba, otra diferencia fundamental es que aquí un Senior Programmer como ya he comentado un poco antes, puede tener los años que sea. Aquí puedes tener 45 años, ser senior programmer, tener 25 años de experiencia a tus espaldas, y cobrar un sueldazo espectacular, mucho más en ocasiones que gente en puestos superiores, business analysts y demás. En nuestro país, como digas que eres senior programmer a los 30 y tantos, ya sabes lo que tienes: pobrecito, no ha sido capaz de llegar a nada más en la vida. Lo puedo decir aún más claro: en Europa ser programador es tener un trabajo digno.

Pero bueno, todo esto desemboca en todos los problemas ya hablados de un mercado anticuado, de una empresas con jerarquías obsoletas, roles confusos, ofertas ridículas, etc. Una buena forma probablemente para empezar a sanear esto sería adaptarse un poquito más a Europa y dejarse de demás historias.