Historias
Slashboxes
Comentarios
 

La raíz de la precariedad en la informática

Entrada escrita por ejimenez y editada por Candyman el 28 de Septiembre 2010, 11:00h   Printer-friendly   Email story
Últimamente se están sucediendo varias noticias relacionadas con el problema de la precariedad laboral en el sector de la informática. El tema lleva sobre la mesa desde siempre, pero las dificultades actuales en el mercado laboral lo están acentuando. Los debates sobre la cuestión casi siempre degeneran en guerras incendiarias ente los propios perjudicados. Sobre todo, cuando se tocan aspectos como el intrusismo, los colegios, o la utilidad de los planes de estudio. Un ejemplo es la famosa discusión entre ingenierosdeprimera.com y Ricardo Galli, creador de Meneame.com. Otras veces el foro se convierte en una colección de insultos contra las cárnicas, como pasaba con www.trabajobasura.com, y otros sitios parecidos. Esto suele ser poco productivo, porque no logra cambiar nada.

Para mi, la raíz del problema de la precariedad laboral no está en las cárnicas, ni en la ausencia de colegios o sindicatos. La raíz está en la contratación de perfiles poco cualificados, y su consideración como peones albañiles.

Cuando digo perfiles poco cualificados no me refiero a titulados o no titulados. Me refiero a personas sin ninguna vocación, y sin ningún interés por aprender, empezando por aquellos, tanto informáticos como otros titulados, que afirman que "no han estudiado una ingeniería para acabar picándo código", o que "la labor de un ingeniero no es poner los ladrillos".

Precisamente las cárnicas, el bodyshopping, la deslocalización a otros a países, y gran parte de los males del mundo de los servicios de software, no son más que consecuencias de esta consideración del programador como un peón albañil.

A veces son éstas mismas personas, los que desprecian la programación, quienes más se quejan del intrusismo. Pero estaréis de acuerdo en lo incoherente que resultaría revindicar la programación como una competencia exclusiva de los ingenieros informáticos, y mantener al mismo tiempo que la programación es impropia de un ingeniero. Tan incoherente como protestar por la contratación de licenciados en informática como "picadores", al mismo tiempo que se protesta por la contratación como programadores de profesionales de otras titulaciones. No tiene sentido tampoco que sean los menos cualificados para la programación, que son aquellos que la desprecian, quienes etiqueten a todos los demás como perfiles no cualificados para el desarrollo de software.

Más de uno estará pensando que no es la programación lo que les preocupa, sino la dirección o gestión de proyectos de software. Piensan que la verdadera labor de un ingeniero no es programar o poner ladrillos, sino dirigir proyectos o diseñar los sistemas.

Las personas que piensan así generalmente no están cualificadas para programar, ni para gestionar proyectos. Para lo primero es evidente: quien piense que programar es como poner ladrillos, es que no ha programado en su vida. Pero la programación no es una actividad de construcción, sino de diseño. No quiero extenderme demasiado, la mejor explicación al respecto es el artículo de Jack Reeves: el código es el diseño.

En cuanto a lo segundo, quienes piensan que lo propio de un ingeniero es ser jefe de proyecto, lo que reflejan es una concepción taylorista del proceso de desarrollo de software, y con esa mentalidad es difícil gestionar proyectos en la actualidad.

Permitidme un paréntesis sobre la gestión de proyectos. Creo que conocéis cual es la concepción taylorista y creacionista del proceso de desarrollo de software. Aquella basada en la división de las actividades de análisis, diseño , construcción y pruebas, entre distintos grupos de personas, con distintos niveles jerárquicos de responsabilidad, mediante un proceso secuencial, dentro de sistemas formales documentalmente pesados. Éste es el enfoque ortodoxo y académico que promueven las prestigiosas consultoras. Nada que ver, por supuesto, con el verdadero desarrollo profesional de software.

He visto alguna vez por Barrapunto chistes sobre el tema. Efectivamente, si a un consultor le encargasen auditar el desarrollo del kernel de Linux, se llevaría las manos a la cabeza: ¿dónde están los diagramas UML?, ¿dónde está el diagrama de Gantt?, ¿y los documentos de diseño?, ¿qué hacen todos estos ingenieros picando código?. Si un consultor soltara estas preguntas en las listas de correo del kernel, todos los hackers se reirían de él, aunque no creo que perdieran mucho tiempo con la guasa, tienen cosas más importantes que hacer. Pero cuando este mismo discurso se mantiene dentro de una empresa, ante un foro de gerentes, directivos, y otros consultores, todos acaban congratulándose de que alguien por fin les entienda, y de que se proponga empezar a hacer las cosas bien, de forma "industrializada", como una "ingeniería".

El taylorismo es obsoleto en todas las demás ingenierías desde los años 70, cuando se desarrolló el toyotismo. No se si os sonarán términos como "Lean", "Kanban", "Jidoka", o "Kaizen", propias del ámbito industrial, pero seguro que sí os suenan las metodologías ágiles de desarrollo como Scrum o Programación Extrema, donde no hay ni jefes, ni analistas, ni testers, sino simplemente equipos de desarrolladores auto-organizados, donde todos prueban, codifican, analizan y documentan. La ingeniería de software es, curiosamente, una de las disciplinas más reaccionarias ante estos enfoques. Habría que tirar a la basura, o mejor, quemar en la hoguera, toda la bibliografía taylorista sobre ingeniería de software, que parte de la visión de la programación como una actividad de construcción, y del programador como un peón albañil.

Las grandes consultoras han apoyado el taylorismo, o el desarrollo de software mediante mano de obra barata y poco cualificada, porque durante muchos años ha sido un modelo muy rentable. Cuanto más improductivo es el modelo, más personal requieren sus clientes, y durante más tiempo, lo que implica mayores ingresos y beneficios. Si además se establecen procesos formales lentos y pesados, basados en la elaboración de montañas de documentación, los proyectos requerirán cada vez más recursos y más tiempo. Esta dinámica no es realmente intencionada, ni es exclusiva de la ingeniería de software. La tendencia de toda organización a multiplicar la burocracia para maximizar el esfuerzo fue descrita por primera vez por Cyril Northcote Parkinson en 1955, y es conocida como la Ley de Parkinson.

Es difícil hablar de calidad, talento, experiencia o cualificación dentro de un mundo como el del sector de las IT y los servicios de software, que es exactamente como el que describió Parkinson, aunque él se refiriese a la administración colonial británica. La productividad no importa, y las personas no son más que material fungible.

El resultado inicial de este modelo ha sido el prestamismo laboral o el bodyshopping, que tan rentable fue para las cárnicas y las presuntas consultoras, transformadas en ETTs encubiertas. En poco tiempo lograron colocar a tanta gente que la demanda de informáticos se disparó, y muchos treparon de forma vertiginosa. El primer varapalo llegó en el 2000 con la crisis de la puntocom, y la puntilla llegó con el inicio de los procesos de externalización y deslocalización a otros países durante la década siguiente, en busca de mano de obra barata.

El efecto del offshoring o la deslocalización para las consultoras españolas ha sido devastador. Se han ido quedando progresivamente sin proyectos, a medida que sus clientes trasladaban sus desarrollos a países como la India. Quisiera poner como ejemplo Movistar, que hace un par de años trasladó los desarrollos de sus sistemas de información a las software factories de Accenture en Argentina. Estos procesos de externalización y deslocalización en Telefónica siguen su curso aún. Hace unas semanas, por ejemplo, se comentó la concentración de unos 300 trabajadores en protesta por la externalización de Telefónica I+D a Ericcson e Indra.

Los cientos de Trabajadores de I+D que han sido "invitados" a cambiar de empresa, son pocos comparados con los cerca de 2000 que Telefónica segregará a Telefónica Global Technology, la nueva empresa del grupo.

La presidenta de TGT es la argentina María Fernanda Torquati, anterior directora de sistemas de información de Telefónica. Podéis encontrarla en la foto junto a Cristina Fernández de Kirchner, y otros directivos de Telefónica y Accenture.

Mientras en España esta deslocalización implica la destrucción de cientos de puestos de trabajo, en Argentina supone la creación de miles de ellos, aunque posiblemente no muy estables. El modelo que se está exportando allí es el modelo de las cárnicas, que tanto daño ha causado en España.

La moda de la deslocalización proviene de otro tipo de industrias, como la del sector textil o el sector del automóvil, donde existen actividades de fabricación intensivas en mano de obra. Lo que se trasladan son las actividades de construcción o fabricación, mientras el diseño se mantiene en Europa. No tendría sentido deslocalizar el diseño, ya que no suele ser una actividad acometible por fuerza bruta, sino por personal altamente experto y cualificado, y su deslocalización a países en vías de desarrollo no implicaría ninguna reducción de costes. De hecho, el offshoring de las actividades de diseño multiplica los costes, ya que merma la productividad y la calidad, entre muchas ochas.

Gran parte de las empresas que promovieron durante los 90 un offshoring de las actividades de I+D a países como la India, se encuentran ahora en un proceso inverso de retorno a sus países de origen. Una muestra sintomática de esta marcha atrás es la obra "Decline and Fall of The American Programmer" de Edward Yourdon (1992), vaticinando la desaparición de los programadores en EEUU como consecuencia de la deslocalización. La mejor muestra de que estaba equivocado es "Rise & Resurrection of the American Programmer", el libro que escribió después para explicar por qué había fallado en todos sus vaticinios. Si visitáis estas obras en Amazon, echad un vistazo a los comentarios de Peter Norving, director de desarrollo de Google. Podéis comprobar por las fechas que en España acarreamos un desfase respecto a estas tendencias.

La precariedad laboral en el sector de las consultoras y los servicios de software es simplemente consecuencia de un prejuicio: la consideración de los informáticos como peones albañiles. La subcontratación, la contratación de perfiles poco cualificados, el fenómeno de las cárnicas, y la deslocalización a países en vías de desarrollo, no son más que consecuencias directas de esta visión de los informáticos como albañiles, y de su labor como una actividad que puede hacer cualquiera, acometible por fuerza bruta.

Mientras, las consultoras en España han sido víctimas de sus propios errores, ya que aquello en lo que han fallado miserablemente es en explicar que lo que los proyectos requieren no es fuerza bruta, ni mano de obra barata, sino personal experto y cualificado. Este personal cualificado también es más barato, ya que es más productivo, y no sólo produce más, sino que produce mejor o con mayor calidad. Al fin y al cabo eso es lo que realmente la gente espera de un consultor: alguien cualificado y experto.

Cuando las consultoras decidieron dejar de ser consultoras, para convertirse simple y llanamente en ETTs de mierda, operando al borde de la legalidad, firmaron sus sentencias de muerte. Creo que muchas empresas deberían estar planteándose hoy si quieren ser realmente ETTs encubiertas, y dedicarse a competir en mano de obra barata (lo que se me antoja harto difícil), o volver a ser consultoras, y empezar a combatir desde ya los procesos de deslocalización en sus clientes. Claro, es poco creíble que los mismos que han defendido las bondades del offshoring y de las software factories, defiendan ahora un modelo completamente contrario.

Hoy las consultoras deberían ser las primeras interesadas en defender un modelo basado en la productividad, en la experiencia, la cualificación y el talento. Y los informáticos también. En vez de combatir la precariedad laboral mediante colegios, sindicatos y privilegios, creo que deberíamos unir esfuerzos en erradicar el prejuicio inicial, que es la consideración de los programadores como peones albañiles, y la programación como una actividad de construcción. Hace falta para ello reescribir los libros sobre ingeniería de software desde el principio, y eso es lo que yo he pretendido hacer con Ingeniería de Software Ágil.

Historias relacionadas

[+] ¿Un nuevo Sintel en Telefonica I+D? 64 comentarios
Augusto Ada nos cuenta «El martes 13 se concentraron mas de 300 trabajadores de Telefónica I+D frente al Edifico de Telefónica en la Gran Vía de Madrid y en protesta por la pretensión de la empresa de segregar la actividad de Investigación y Desarrollo a Ericsson e Indra que afectará a más de 440 empleados de Madrid y Valladolid. Aunque la dirección de la compañía ha asegurado que las condiciones laborales se van a mantener, los empleados afectados temen que a corto o medio plazo se repita la historia de Sintel y pierdan sus puestos de trabajo». En Facebook hay creado el grupo Afectados Segregación Telefónica I+D.
[+] Ciencia: El recorte en los presupuestos de I+D ahoga el desarrollo científico 50 comentarios
El País cuenta la tragedia de la investigación en España: los investigadores se forman con gran esfuerzo personal y gran inversión social (los estudios están altamente subvencionados), y cuando llega la hora de ponerse a trabajar, no hay salidas: «La comunidad científica llama la atención sobre el recorte de la oferta de trabajo para los científicos, porque supone una seria amenaza de perder a muchos jóvenes bien preparados en una nueva oleada de fuga de cerebros. El Consejo Superior de Investigaciones Científicas (CSIC) , por ejemplo, reducirá el año que viene la contratación en un 20% y ya está convocando plazas de científico funcionario con una tasa de tres nuevos puestos por 10 jubilados.» Bueno, sí que hay salidas: por mar, por tierra y por aire. En el artículo cuentan que en Alemania, Suiza y Estados Unidos, por ejemplo, siguen contratando.
[+] Formación: La Asamblea de Madrid crea los Colegios de Ingenieros e Ing. Tec. en Inf. de Madrid 38 comentarios
Un pobrecito hablador nos cuenta sobre la aprobación de las Leyes de Creación de los Colegios Profesionales de Ingenieros e Ingenieros Técnicos en Informática de la Comunidad de Madrid. Un triunfo para las asociaciones relacionadas en el tema (ALI, AI2 y AAIC) que repetidamente han solicitado a la Comunidad de Madrid la creación de estos recién creados colegios. Se completa el mapa de colegios de España, tras los de Andalucía, Baleares, Canarias, Galicia y seguro que se me escapan otros. Triunfo para las asociaciones gremiales, pero no necesariamente para la calidad ni la fiabilidad del software. Y sobre el largo y dificil camino de la profesión de informático, que tanto se ha discutido en Barrapunto, tengo una pregunta muy concreta: esto de los colegios, ¿crees que favorecerá o que limitará el modelo empresarial de las cárnicas y el bodyshopping? Porque, a mi juicio, ese y no el intrusismo es el primer problema con el que se enfrentan los informáticos en España.
[+] Un sector "inmune a la crisis" pero con deslocalizaciones y despidos constantes 29 comentarios
Augusto Ada nos cuenta: «Recientemente discutíamos en BP si las factorías de software españolas son "inmunes a la crisis". La realidad desde el punto de vista de los sindicatos activos en el sector parece otra: movilizaciones por ERE encubierto en Coritel (Grupo Accenture), lucha contra un ERTE en Atos Origin que busca "felxibilizar la plantilla", delegados sindicales de HP protestan por el despido de trabajadores en Zaragoza por una deslocalización y ya hay movilizaciones convocadas por el ERE en Thales. ¿Conoces mas casos en el sector? ¿van a poder los sindicatos parar el golpe en un sector fragmentado y cada vez mas precario, de trabajadores en general muy individualistas y donde la negociación colectiva es casi la excepción y no la norma?» Los "obreros" de la programación que trabajan en esas "factorías" de software hacen bien en reclamar mejores condiciones laborales, pero eso sólo es un parche temporal que, a mi juicio, resuelve el problema equivocado. El verdadero problema es que la profesión esté proletarizada (el viejo "programar es como poner ladrillos"), y la solución a largo plazo pasa por desproletarizarla, no por ponerle cortinas al modelo de programador-obrero.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Ojo con el análisis

    (Puntos:3, Interesante)
    por pobrecito hablador el Sábado, 25 Septiembre de 2010, 08:06h (#1240909)

    Para mi, la raíz del problema de la precariedad laboral no está en las cárnicas, ni en la ausencia de colegios o sindicatos. La raíz está en la contratación de perfiles poco cualificados, y su consideración como peones albañiles.
    Hay mucho "informático" que no se gana el sueldo que cobra, y también mucho que cobra menos porque el reparto con los incapaces. Esto se solucionaría con procesos de selección mucho más exigentes, cosa difícil, cuando a menudo quien contrata tampoco es lo suficientemente bueno, y el talento extraordinario tampoco es común (el ego sí, pero del ego al talento hay un buen trecho). Hay programadores que rinden tranquilamente 10 y 20 veces más que la media, no sólo por acabar la implementación antes, sino porque sus desarrollos conllevan mucho menos mantenimiento. Pues bien, esos programadores, en España, si bien cobran más que la media (quizá un 20-30% más), su remuneración es una vergüenza en proporción a su productividad. La cosa tiene difícil solución, salvo que los que tengan más talento se monten algo por su cuenta, o emigrar.

    Precisamente las cárnicas, el bodyshopping, la deslocalización a otros a países, y gran parte de los males del mundo de los servicios de software, no son más que consecuencias de ésta consideración del programador como un peón albañil.
    Lo achacaría más bien a la oferta y la demanda. En el periodo 1999-2001 los salarios eran mejor que ahora, como también lo fueron en el 2006-2007. Ahora están cayendo en picado, y quien pierda el empleo, salvo que se dedique a algo muy concreto, va a ver reducido mucho su salario.

    He visto alguna vez [barrapunto.com] por Barrapunto chistes sobre el tema. Efectivamente, si a un consultor le encargasen auditar el desarrollo del kernel de Linux, se llevaría las manos a la cabeza: ¿dónde están los diagramas UML?, ¿dónde está el diagrama de Gantt?, ¿y los documentos de diseño?, ¿qué hacen todos estos ingenieros picando código?. Si un consultor soltara estas preguntas en las listas de correo del kernel, todos los hackers se reirían de él, aunque no creo que perdieran mucho tiempo con la guasa, tienen cosas más importantes que hacer. Pero cuando este mismo discurso se mantiene dentro de una empresa, ante un foro de gerentes, directivos, y otros consultores, todos acaban congratulándose de que alguien por fin les entienda, y de que se proponga empezar a hacer las cosas bien, de forma "industrializada", como una "ingeniería".

    ¿De que iban a vivir entonces ordas de parásitos?

    El taylorismo es obsoleto en todas las demás ingenierías desde los años 70, cuando se desarrolló el toyotismo. No se si os sonarán términos como "Lean", "Kanban", "Jidoka", o "Kaizen", propias del ámbito industrial, pero seguro que sí os suenan las metodologías ágiles de desarrollo como Scrum o Programación Extrema, donde no hay ni jefes, ni analistas, ni testers, sino simplemente equipos de desarrolladores auto-organizados, donde todos prueban, codifican, analizan y documentan. La ingeniería de software es, curiosamente, una de las disciplinas más reaccionarias ante estos enfoques. Habría que tirar a la basura, o mejor, quemar en la hoguera, toda la bibliografía taylorista sobre ingeniería de software, que parte de la visión de la programación como una actividad de construcción, y del programador como un peón albañil.
    A la quema añadiría los libros de "metodologías ágiles", y sus "gurús". Una cosa es la idea, y otra que se tome
    • Re:Ojo con el análisis

      (Puntos:4, Inspirado)
      por ejimenez (23107) el Sábado, 25 Septiembre de 2010, 09:52h (#1240924)
      ( http://www.ingsoftagil.com/ | Última bitácora: Viernes, 24 Septiembre de 2010, 22:50h )

      Lo achacaría más bien a la oferta y la demanda. En el periodo 1999-2001 los salarios eran mejor que ahora, como también lo fueron en el 2006-2007. Ahora están cayendo en picado, y quien pierda el empleo, salvo que se dedique a algo muy concreto, va a ver reducido mucho su salario.
      A la oferta y la demanda, pero de mano de obra barata y no cualificada, es decir, de peones albañiles. De personas realmente cualificadas no hay demanda, aunque sean 20 o 30 veces más productivas, y eso se debe al problema cultural de considerar al informático como un peón.

      A la quema añadiría los libros de "metodologías ágiles", y sus "gurús". Una cosa es la idea, y otra que se tome como una religión, perdiendo el foco de que es sólo una herramienta, y que no puede estar por encima del sentido común.
      Es cierto, se han convertido en las nuevas balas de plata. Hay una verdadera fiebre por las metodologías, una "metodologitis" como yo lo llamo.
      [ Padre ]
    • Re:Ojo con el análisis de baikal (Puntos:1) Miércoles, 29 Septiembre de 2010, 15:29h
    • 2 respuestas por debajo de tu umbral de lectura actual.
  • pdf

    (Puntos:1, Informativo)
    por pobrecito hablador el Sábado, 25 Septiembre de 2010, 10:03h (#1240927)
    Me he bajado el 1er capitulo en pdf.
    El texto se ve muy apelotonado y se hace difícil de leer, deberías dejar una linea en blanco entre párrafos.
    • Re:pdf de ejimenez (Puntos:1) Sábado, 25 Septiembre de 2010, 18:41h
      • Re:pdf de pobrecito hablador (Puntos:1) Domingo, 26 Septiembre de 2010, 16:13h
      • 2 respuestas por debajo de tu umbral de lectura actual.
  • Cualificación y 'consultoras'

    (Puntos:1, Inspirado)
    por pobrecito hablador el Sábado, 25 Septiembre de 2010, 10:40h (#1240934)

    Mientras, las consultoras en España han sido víctimas de sus propios errores, ya que aquello en lo que han fallado miserablemente es en explicar que lo que los proyectos requieren no es fuerza bruta, ni mano de obra barata, sino personal experto y cualificado. Este personal cualificado también es más barato, ya que es más productivo, y no sólo produce más, sino que produce mejor o con mayor calidad. Al fin y al cabo eso es lo que realmente la gente espera de un consultor: alguien cualificado y experto.
    Las consultoras, en mi opinión, están interesadas única y exclusivamente en facturar carne/hora. Que acepte trabajar una persona sin experiencia, OK, pero con experiencia y cualificación, salvo que sea para no pasar hambre, hay que estar loco para trabajar en una "cárnica".
  • Ley de Parkinson

    (Puntos:2, Informativo)
    por faragon (17575) el Sábado, 25 Septiembre de 2010, 18:43h (#1240998)
    ( http://www.voluntariado.net/ | Última bitácora: Lunes, 14 Febrero de 2011, 20:52h )

    Las grandes consultoras han apoyado el taylorismo, o el desarrollo de software mediante mano de obra barata y poco cualificada, porque durante muchos años ha sido un modelo muy rentable. Cuanto más improductivo es el modelo, más personal requieren sus clientes, y durante más tiempo, lo que implica mayores ingresos y beneficios. Si además se establecen procesos formales lentos y pesados, basados en la elaboración de montañas de documentación, los proyectos requerirán cada vez más recursos y más tiempo. Esta dinámica no es realmente intencionada, ni es exclusiva de la ingeniería de software. La tendencia de toda organización a multiplicar la burocracia para maximizar el esfuerzo fue descrita por primera vez por Cyril Northcote Parkinson en 1955, y es conocida como la Ley de Parkinson [wikipedia.org].
    Se da con especial virulencia en España, donde hasta para hacer la O con un canuto se contratan ayudantes, y cualquier cosa trivial se convierte en un desempeño milagroso.

    El año pasado añadí una entrada de bitácora con una traducción de la Ley de Parkinson [barrapunto.com] (traducción rápida, seguro que tiene bastantes errores).
  • Sobre metodologías ágiles

    (Puntos:4, Informativo)
    por Quin (13945) el Lunes, 27 Septiembre de 2010, 08:16h (#1241171)
    ( http://aparatos.blogspot.com/ | Última bitácora: Miércoles, 22 Julio de 2009, 06:44h )
    Lo primero, enhorabuena por un texto muy bien escrito.

    Yo estoy en parte de acuerdo (en especial en considerar la programación como una labor mucho más compleja que poner ladrillos), pero no tengo claro que las metodologías ágiles sean la solución para todo. Me parece interesante esta crítica a las metodologías ágiles [whattofix.com].
  • Matizar

    (Puntos:3, Interesante)
    por toggle (46333) el Lunes, 27 Septiembre de 2010, 19:25h (#1241303)
    ( Última bitácora: Viernes, 04 Febrero de 2011, 10:50h )
    Me perece un buen análisis pero no estoy de acuerdo en la causa de este párrafo:

    Cuando las consultoras decidieron dejar de ser consultoras, para convertirse simple y llanamente en ETTs de mierda, operando al borde de la legalidad, firmaron sus sentencias de muerte. Creo que muchas empresas deberían estar planteándose hoy si quieren ser realmente ETTs encubiertas, y dedicarse a competir en mano de obra barata (lo que se me antoja harto difícil), o volver a ser consultoras, y empezar a combatir desde ya los procesos de deslocalización en sus clientes. Claro, es poco creíble que los mismos que han defendido las bondades del offshoring y de las software factories, defiendan ahora un modelo completamente contrario.
    La evolución a la subcontrata no ha sido tanto decisión de la empresa como del legislador. Una legislación proteccionista europea es la que incentiva a la empresa a controlar el riesgo de que le salga el empleado problemático. Además los desarrolladores (a diferencia de otros informáticos como los administradores) no se necesitan de forma continua sino sólo mientras haya projectos. La solución más usada ha sido subcontratar y devolver al programador si sale malo o deja de haber proyectos.
    • Re:Matizar de pobrecito hablador (Puntos:1) Lunes, 27 Septiembre de 2010, 21:49h
      • Re:Matizar de toggle (Puntos:2) Martes, 28 Septiembre de 2010, 08:10h
    • Re:Matizar de pobrecito hablador (Puntos:1) Martes, 28 Septiembre de 2010, 12:35h
      • Re:Matizar de pobrecito hablador (Puntos:1) Martes, 28 Septiembre de 2010, 22:30h
  • la raiz estará

    (Puntos:3, Inspirado)
    por obreiro (37284) el Martes, 28 Septiembre de 2010, 11:15h (#1241392)
    ( http://www.galizalivre.org/ )
    la raiz estará en donde las demas raices no?

    O es que en otros sectores no hay percariedad? La informática no es el unico sector. En todos sucede lo mismo y la raíz es la misma: Una educación muy deficiente sumado a un sistema productivo aún más deficiente sumado a una patronal muy poderosa.

    Y hasta que eso no cambie, ni colegios, ni cárnicas ni leches van a arreglar nada.
    --
    nem guerra entre povos, nem paz entre classes!
  • Buen análisis

    (Puntos:3, Inspirado)
    por knar (4125) <solrac888@QUITAESTOyahoo.com> el Martes, 28 Septiembre de 2010, 13:32h (#1241411)
    ( http://blog.irreality.eu/ )
    Muy buen análisis. Efectivamente, siempre me ha llamado la atención que los que quieren prestigiar la ingeniería informática en España suelten lo de "programar es cosa de albañiles, un ingeniero informático debe dirigir proyectos". Con eso al final lo único que consiguen es condenar a los ingenieros informáticos a reconvertirse al "management" (cosa que no nos suele gustar a los que tenemos un perfil técnico) o bien a sufrir precariedad. Y lo que es peor, a que en España no se lleven a cabo proyectos interesantes, porque el modelo "mánager que no se ensucia las manos con asuntos técnicos + grupo de curritos mileuristas" sólo vale para hacer aplicaciones estándar de gestión y poco más.

    En otros países, se sabe que hay programadores y programadores: para sumar columnas de una base de datos puedes poner a un "albañil", para optimizar un proceso de indexación en un buscador o programar un sistema de tiempo real para un equipo médico no. Así tienen las ofertas de trabajo que tienen, y que aquí ni existen, porque no se acometen ese tipo de proyectos.

    Felicidades al autor por hacer este análisis objetivo y sin caer en los flamebaits título sí/título no.
    --
    Mi bitácora: Reductio ad Absurdum 2.1 [irreality.eu]
  • por pobrecito hablador el Martes, 28 Septiembre de 2010, 13:58h (#1241415)

    Cuando digo perfiles poco cualificados no me refiero a titulados o no titulados. Me refiero a personas sin ninguna vocación, y sin ningún interés por aprender, empezando por aquellos, tanto informáticos como otros titulados, que afirman que "no han estudiado una ingeniería para acabar picándo código", o que "la labor de un ingeniero no es poner los ladrillos".
    Quisiera hacer una apreciación sobre esta frase. Y es que esto mismo nos ocurre a los recién egresados, que tras cursar asignaturas orientadas a la ingeniería del software se nos transmite la idea (cierta o no) de que el programador cobra poco, trabaja en malas condiciones y que la solución es especializarse (auditoría, peritaje, ...) y/o certificarse para ser un «jefe» y no un currito como compensación por años de formación académica.

    Más aún cuando ves una oferta de trabajo o beca de una multinacional y los requisitos son tener dos dedos de frente para estar titulado en una carrera (desde economía y derecho, pasando por periodismo y publicidad hasta cualquier ingeniería) de 5 años, algo incomprensible y que te desanima.

    Con esto quiero decir que si a programar se le asocia despectivamente con «picar código» no es problema de los titulados (informáticos en mi caso) y su falta de vocación, sino que es consecuencia de lo que se nos transmite tanto en la universidad como en el mundo laboral por parte de allegados.

  • Carnicas y vegetarnicas

    (Puntos:1, Interesante)
    por pobrecito hablador el Martes, 28 Septiembre de 2010, 14:38h (#1241423)
    He trabajado en unos cuantos sitios ya como programador (titulado pero ni licenciado ni diplomado, pero estoy en ello) y en cada uno me he encontrado cosas muy dispares. El primer sitio que estuve no era cárnica pero los documentos internos para el programador junior eran EXCELENTES, te daba la solución para la mayoría de problemas comunes que podía encontrarse un programador, desde la sintaxis a la lógica pasando por la estandarización de nombres, etc. El trabajo era poco mas que "poner un ladrillo detrás de otro". Me parece excelente, esta metodología, requería mucho tiempo crear esos documentos pero una vez creados era imposible que un "albañil" se equivocara poniendo ladrillos y si no sabia muy bien como seguir, solo tenia que preguntar al analista. Poco después cambie de trabajo y como bien dices, no era un "albañil" lo que buscaban sino un genio del espacio-tiempo. Con pésimos jefes de proyecto que "delegaban" sus funciones en personal no cualificado para "quitarse marrones" eso si facturaba todas las horas. Estos mismos jefes no dudaban un segundo en acercarse a tu puesto a comentarte como se hacía un bucle "For" correctamente, válgame dios no fuera a equivocarme con tan extraña herramienta del demonio. Adivinad por un sueldo de jefe de proyecto, cual de las 2 era la cárnica.
  • por juangarcia (44858) el Martes, 28 Septiembre de 2010, 16:49h (#1241456)
    El problema es el mismo de siempre y no es exclusivo del sector de la informática, está más arraigado por el simple hecho de ser más vulnerables porque no estamos unidos y de eso se aprovechan las ETT y empresas de servicios informáticos que como todos sabemos no son más que intermediarios que se llevan cada mes el dinero que tanto te cuesta ganar. Si fuéramos un poco más listos y nos uniéramos, nos ayudamos entre nosotros y nos apoyamos entre todos. Otro gallo cantaría!!! En definitiva todos buscamos lo mismo, salario digno y un puesto acorde con nuestras perspectivas.

    Lo primero es quitarnos al intermediario, con esto conseguiríamos un empleo digno con salarios dignos pero para eso hay que unirse y obligar a las empresas a que te contraten directamente a ti, sin intermediarios, y negociar los contratos sin pelearnos entre nosotros, porque ahí reside nuestra debilidad.

    Una idea sería crear una única fundación "si ánimo de lucro" que nos representara a todos donde al inscribirte tengas garantizado que cualquier empresa que busque un profesional de la informática, no tenga más alternativa y que negociar con la fundación, el tipo de contrato, el salario y el puesto en cuestión. Todo esto negociado y basado en los estatutos establecidos por los componentes de la misma fundación, que somos todos nosotros. De esta manera cuantos más profesionales de la informática compongan la fundación más fuerte es uno a la hora de imponer nuestras condiciones. Esta sería una idea...

    Salu2.
  • Mi experiencia y el futuro que viene.

    (Puntos:2, Interesante)
    por pobrecito hablador el Martes, 28 Septiembre de 2010, 17:57h (#1241463)
    Leo esas reflexiones y creo que debo contar brevemente mis experiencias profesionales en el extranjero.

    No soy informático, soy ingeniero industrial y he trabajado en proyectos de ingeniería de infraestructuras en varios emiratos del golfo.

    En Dubai, durante muchos años ha sido un polo de atracción papa los ingenieros, nos juntamos centenares de ingenieros españoles, y muchos otros europeos, sueldos astronómicos, libres de impuestos, facilidades para vivienda, sanidad, etc.

    Todo eso se acabó, no ya por la propia crisis inmobiliaria, ahora ya se ha descubierto que donde había un equipo de 10 ingenieros europeos se arreglan con un europeo y 12 ingenieros indios, algun filipino, etc.,y se gastan sólo 1/3 o 1/4 de los costes anteriores.

    Es cierto que (aún) no trabajan igual, pero lo harán, es cuestión de tiempo.

    En España, en cierto modo con la ingeniería pasa de la misma forma que ha ocurrido en otros sectores laborales (sin cualificación, por ejemplo)... ahora es difícil encontrar como españoles trabajos en la hostelería, limpieza, etc, porque son puestos que han copado personas dispuestas a cubrirlos con pocos sueldos.

    Hace años era impensable pero hoy ocurre, decenas de miles de ingenieros de cualquier especialidad salen cada años de universidades de La India, China, Filipinas, etc y nada tienen que envidiar (por mucho que les critiquemos) con la formación de un europeo.

    De la misma forma que un español jardinero, barrendero, o camarero a día de hoy, hay que prepararse para la competencia que viene, es la cruda realidad.

    Un médico, al menos tiene la barrera del idioma, o la titulación en cuanto a territorialidad, pero un ingeniero (o un informático) va a ver como un proyecto se va a realizar en La India y, en el mejor de los casos, alguien lo firmará (una construcción, por ejemplo), en España.

    España ha perdido una oportunidad de oro en estos últimos 10 años, por la razón que sea hay países como Polonia, Rumanía, etc en los que sus profesionales cualificados han sabido ganarse un puesto en sus sociedades y aumentar con ello si status e ingresos, en España no, en España se ha ido degradando su situación...

    Hay casos como la arquitectura que son escandalosos, y no tiene nada que ver con la legislación laboral, ni con los Colegios Profesionales, ni nada de eso, la diferencia está en LA INICIATIVA EMPRENDEDORA de esos profesionales en otros países.

    En España siempre queremos llevar la vida cómoda de "que alguien me dé trabajo", en otros países los profesionales lo han pasado tan mal que se han buscado la vida, Argentina es un ejemplo.

    Quizá hay que cambiar de mentalidad... me da mucha pena ver (hace unos días lo ví) como un analfabeto sin formación pero que tenía afán emprendedor, tenía a sueldo a algunos de vosotros para realizar proyectos de publicidades en webs relacionadas con SMSs... me recordó aun tal Jesus Gil por modos y formas, a lo mejor lo que hace falta es ese caracter emprendedor en este sector por parte de los profesionales.

    Saludos.
  • El Artesano desconocido

    (Puntos:2, Interesante)
    por pobrecito hablador el Martes, 28 Septiembre de 2010, 21:35h (#1241486)
    Llevo varios años trabajando en algo que realmente me apasiona y preocupándome cada día por intentar hacerlo mejor. Lo primero agradecer el artículo !te lo has currado! Siempre me ha impresionado ver como gente que no se conoce de nada al vivir experiencias similares sacan conclusiones parecidas.

    Me gustaría compartir con vosotros algunas de mis reflexiones ;-)


    El proceso de desarrollo como cadena de producción

    Si miramos a industrias como la de manufacturación, vemos como hay procesos perfectamente definidos. Se conforman cadenas de producción. Hay sistemas que aseguran la calidad de los productos y la mejora continua. Se tienen procesos con los que, independientemente de las personas, siempre generan los mismos resultados.

    Se disminuye considerablemente el coste de remplazo, ganando flexibilidad. Permitiendo la externalizarían de la cadena a zonas con tasas por hora más bajas y por lo tanto generar una alta reducción en los costes de producción.

    Además, cuando entramos en la producción mecánica de productos o servicios, la diferencia de productividad entre personas es muy baja. Se conoce de antemano cual es el rango de productividad por persona admisible, por lo que podemos detectar rápidamente a las personas más conflictivas y reemplazarlas.

    Estas industrias permiten la producción en escala de un producto al precio más competitivo. De un producto, de una vez y otra vez el mismo producto. Pero... ¿es el Software equiparable? La primera pregunta que nos hacemos es si realmente producimos una y otra vez el mismo software. Desde nuestro punto de vista creemos que no, pues si ya lo tuviésemos no lo produciríamos, haríamos una copia.

    Creo que ésta, es una de las grandes diferencias que siempre pasa desapercibida. El software no es equiparable a las materias primas, las materias primas no se pueden clonar el software sí.

    Toda la metodología de las ingenierías se basa en esa propiedad que no tenemos en el software. Por tanto no se puede extrapolar sus métodos al software.

    Y en el estado de conocimientos actuales ni siquiera podemos esperar que el software llegue a tener unos métodos con características similares.

    Hoy en día se considera aceptado, en gran parte debido al artículo "No Silver Bullet" de Frederick Brooks [wikipedia.org], que no existen ni existirán inventos milagrosos que vayan a transformar el desarrollo del software en algo trivial o automático, ya que la naturaleza de la complejidad del software no reside en las herramientas.

    Entonces..., si cada vez producimos productos parecidos pero diferentes, no será que intentamos montar una cadena de producción de la fase de creación de la cadena de producción.

    Es decir, en la cadena de producción de coches producen una y otra vez el mismo modelo de coche. Pero el proceso de creación de un nuevo modelo de coche ¿es realmente una cadena de producción?, ¿es realmente independiente de las personas?, ¿Porqué cuando se comienza un nuevo proyecto queremos que estén unas determinadas personas?

    ¿No dependen en parte de la creatividad las personas? ¿Qué ha marcado la diferencia entre el IPhone y el resto de teléfonos móviles? ¿Qué ha marcado la diferencia entre la Wii y el resto de consolas? ¿No es la capacidad de innovación lo que hace rompedor un nuevo producto? ¿Podemos crear una cadena de producción de artesanía?


    La Arquitectura

    En otras industrias, como la construcción, un Arquitecto realiza el estudio de las partes principales del edificio y define como se debe realizar la construcción. Después otros equipos menos especializados llevan

  • por cicerone (27675) el Miércoles, 29 Septiembre de 2010, 00:34h (#1241498)
    todos hemos tenido unos cuantos de jefes lerdos pa matarlos, pero no estoy de acuerdo en el axioma de que el jefe tiende a ser el mas gilipollas

    entiendo que la solucion que la mayoria pretende proponer, es que jefes listos, contraten programadores listos

    el problema de esto es que cuando entras en una dinamica de grupos, necesaria para un proyecto grande, entran en juego otros factores, osea, creo que esa solucion es falsa, por ser demasiado trivial

    solucion que yo propongo: ninguna, porque creo que el problema que se plantea (injusticias laborales) no tiene solucion porque un gestor no puede fiarse de las valoraciones de sus secuaces

    el dia que este mercado este maduro, puede que existan cuantificadores con tiznes de objetividad del trabajo de un programador

    una cosa son los conocimientos de un pavo (que pueden medirse), y otra es la calidad del trabajo del individuo

    entre tanto, ... guena zuete, chato
  • Y esto sale...

    (Puntos:2)
    por israelviana (12786) el Miércoles, 29 Septiembre de 2010, 07:51h (#1241515)
    ( http://www.israelviana.es/ | Última bitácora: Martes, 20 Octubre de 2009, 22:16h )
    ...justo el día antes de la huelga. Que no somos tontos [barrapunto.com].
  • por RBroncano (47638) el Miércoles, 29 Septiembre de 2010, 08:26h (#1241523)
    Creo que el artículo es algo subjetivo. La documentación es necesaria, primero para facilitar el mantenimiento y segundo para fijar los requisitos. Si no desarrollas unos requisitos detallados para que te los firme el cliente vas a estar realizando cambios a su antojo. Y ya sabemos que los cambios sobre la marcha bajan mucho la calidad del software. Hay muchos a los que les gustaría ser programador si no estuviera mal visto. Sobre el problema de las empresas que no valoran al informático. Everis, antigua DMR pegó un pelotazo en el mercado usando ese modelo de negocio. Entonces, o no hay suficiente competitividad como decís algunos de manera que el uso de expertos saque del mercado a las empresas cárnicas/explotadoras, o es que realmente un experto no añade nada de valor. Yo me inclino a pensar que el mercado no está maduro y que es necesaria la creación de empresas de valor que consigan sacar provecho de la programación y la calidad de los proyectos. Aunque puede que me equivoque. Muchos clientes están muy contentos con desarrollos de software que cualquiera de nosotros calificaría como auténtica bazofia. Yo apuesto por el ESPÍRITU EMPRENDEDOR y la puesta en valor de la programación y del desarrollo de software. Y una mayor orientación a producto.
  • por CitoJam (9245) <jamNO@SPAMgatogordo.es> el Miércoles, 29 Septiembre de 2010, 08:50h (#1241526)
    ( http://www.gatogordo.es/ | Última bitácora: Sábado, 29 Mayo de 2004, 03:47h )
    ... son los propios empleados quienes se quejan, se quejan y se quejan pero acaban tragando. "Este trabajo no es digno, pero como no hay otra cosa me lo como igual". Mientras al empresario se le siga dando lo que quiere no pedirá otra cosa. No es cuestión de leyes, cárnicas, títulos, es cuestión de mentalidad.

    ¿Quieres un trabajo adecuado a tu talento y no lo encuentras? Cambia de ciudad. ¿Sigues sin encontrarlo? Cambia de país. ¿Sigues sin encontrarlo? Crea tu propia empresa, lucha por lo que es tuyo, da ejemplo. Pero no hagamos quejas de barra de bar refugiándonos en el tópico "no hay nada que yo pueda hacer, la solución está en manos de otros", porque para esos "otros" no hay problema alguno.

    (Y cuando digo "lucha" no me refiero a monta un piquete, quema neumáticos y distribuye pancartas, me refiero a no caigas en el conformismo).

    --
    El Gato Gordo [gatogordo.es]
  • por rapumax (38310) el Miércoles, 29 Septiembre de 2010, 10:49h (#1241535)
    En cuanto a lo del intrusismo, si es cierto que cualquiera puede programar independientemente si es de un curso, un ciclo o una licenciatura y evidentemente cualquiera de ellos con un par de años de experiencia programarán mucho mejor en la empresa que cualquier ingeniero. La ventaja que tenemos los ingenieros es la formalización de los conceptos a la hora de diseñar y documentar. Hablo de patrones de diseño, términos como la cohesión y el acoplamiento, malos olores, antipatrones... No es lo mismo documentar un proyecto diciendo "he usado esta interfaz que es implementada por estas tres clases para..." que "he usado un patrón estrategia para resolver este problema", ya se que puede sonar raro pero cualquier ingeniero entenderá la solución al instante y se hará una idea de las clases e interfaces que has usado (o debería).
    De todas formas para entender estos conceptos no es necesaria una ingeniería, sino darse una vuelta por la wikipedia y se lo recomiendo a todos los desarrolladores.
  • Claro que hay un error de concepto al hacer paralelismo entre construcción e informática, pero porque se escogen roles equivocados: el programador es más parecido a un delineante que a un peón.
    Crear un proyecto informático ni es más creativo ni es más caótico que entregar un gran proyecto civil, industrial o arquitectónico.

    El ingeniero en informática debe saber programar pero asumir que informática, software y programación son lo mismo es un abuso del lenguaje pernicioso. Si un ingeniero en informática decide trabajar como consultor SAP, analista de GIS, diseñador de periféricos, montar sistemas de toma de decisiones (DSS), hacer data mining en marketing, gestionar redes telefónicas, participar en un departamento de instrumentación y automatización industrial, etc... para mí estará siendo igualmente ingeniero en informática y necesitará saber un poco de programar y algo más que programar.

    Cada uno con su libertad individual puede hacer lo que desee y puede encasillarse en una factoría de software a picar código en un cubículo y creerse un artista algorítimico como Dijkstra o Knuth.
    Desafortunadamente, la realidad que nos toca vivir es otra y no la de los papers universitarios de los felices 70s y 80s: el que no programe difícilmente logrará empleo, pero el que sólo programe -con título o sin título- tras diez o quince años de experiencia estará con mucha probabilidad fuera del mercado laboral aquí o en el Silicon Valley.
    --

    Not only bridges [blogspot.com]
  • por aprendiendo (23344) el Miércoles, 29 Septiembre de 2010, 20:39h (#1241596)
    Magnífica respuesta de Grady Booch (en.wikipedia.org/wiki/Grady_Booch) a estas eterna pregunta sobre la importancia de la programación:

    http://www.informit.com/articles/article.aspx?p=14 05569 [informit.com]

    Spolsky seems to represent a real constituency that is not just dismissive but outright hostile to software development approaches that are not code-centric. What do you say to people who are skeptical about the value of work products that don't compile?

    Grady: You may be surprised to hear that I'm firmly in Joel's camp. The most important artifact any development team produces is raw, running, naked code. Everything else is secondary or tertiary. However, that is not to say that these other things are inconsequential. Rather, our models, our processes, our design patterns help one to build the right thing at the right time for the right stakeholders.

    Yet, while code is king, one must realize that it is also a servant, for it in the end must serve some constituency, deliver some measurable value. Just as I loathe architecture astronauts--people who have no skin in the game, people who are so divorced from the reality of executables that they melt in the sight of a line of code--I also loathe code bigots who are so blinded by their own prowess and tools that they lose sight of why or for whom they are toiling. Design for design's sake is meaningless; code for code's sake may be fun but it is also meaningless.

  • Sensacion laboral

    (Puntos:1)
    por EncuestasIT (49007) el Martes, 02 Noviembre de 2010, 18:09h (#1248445)

    Hay una encuesta bastante interesante sobre trabajo en IT que aborda la sensacion laboral de los empleados

    http://www.encuestasit.com/Encuesta.aspx [encuestasit.com]
  • Re:Libro en pdf

    (Puntos:2, Informativo)
    por ejimenez (23107) el Sábado, 25 Septiembre de 2010, 19:07h (#1241000)
    ( http://www.ingsoftagil.com/ | Última bitácora: Viernes, 24 Septiembre de 2010, 22:50h )

    Quiero sacar una versión en PDF, pero Bubok por algún motivo se carga los enlaces dentro del texto, y eso me parece inadmisible.

    Además quiero ofrecer varias versiones en distintos tamaños de papel, más apropiados para esas pantallas, pero con Bubok no puedo.

    No he tenido tiempo para solucionar todo esto.

    Descontando el margen de Bubok (20%) y la retención del IRPF (15%) creo que gano unos seis euros por ejemplar, pero hay otros costes indirectos (ISBN, depósito legal, ...).

    [ Padre ]
    • Re:Libro en pdf de pobrecito hablador (Puntos:1) Domingo, 26 Septiembre de 2010, 16:16h
    • Re:Libro en pdf de xlopez (Puntos:2) Martes, 28 Septiembre de 2010, 12:14h
    • Re:Libro en pdf de Sothoth (Puntos:2) Martes, 28 Septiembre de 2010, 22:29h
    • 1 respuesta por debajo de tu umbral de lectura actual.
  • por sammael (16347) el Martes, 28 Septiembre de 2010, 09:29h (#1241372)
    ( http://barrapunto.com/ | Última bitácora: Miércoles, 01 Septiembre de 2010, 08:54h )
    Un comentario sobre esto, yo tambien he pasado por los procesos de seleccion de Amazon y Google (y AOL, Mastercard y varias empresas interesantes mas) y cada vez estoy mas cansado de esos procesos...

    A ver, no me entiendas mal, las preguntas tecnicas complicadas y que te hagan pensar estan bien, los ejercicios de programacion donde no esperan que obtengas la respuesta correcta a la primera, sino que quieren ver como piensas y como te enfrentas a los problemas tambien estan bien. Creo que eso es muchisimo mas importante que un simple cuestionario o que te dediques a soltar chorradas acerca de tu curriculum.

    Ahora bien, las 12 entrevistas tecnicas que te hace Google no me parecen bien (el proceso tarda, como minimo, 3-4 meses y si estas trabajando y no tienes libertad absoluta para hacer las entrevistas presenciales, en Londres, Dublin, Zurich..., pueden ser mas de seis meses), las 8 horas de entrevistas presenciales que te hace Amazon tampoco (despues de dos entrevistas por telefono y un ejercicio de programacion de dos horas), las 5-6 horas de AOL (metido en una salita por la que va entrando y saliendo distinta gente) tampoco me parecen bien...

    Despues de esos y varios procesos mas, te puedo asegurar que cada vez me atrae menos pasar por todo eso simplemente para conseguir un trabajo. En el caso de Amazon, por ejemplo, lo he dejado a medias porque tenia otra oferta ya y no me daba la gana continuar.
    --


    Dale fuego a un hombre y estara caliente un dia, prendele fuego y estara caliente el resto de su vida.
    [ Padre ]
  • Re:Un par de cosas

    (Puntos:2)
    por toggle (46333) el Miércoles, 29 Septiembre de 2010, 16:24h (#1241574)
    ( Última bitácora: Viernes, 04 Febrero de 2011, 10:50h )
    Déjame adivinarlo: Trabajas como gestor de proyectos
    [ Padre ]
  • por svalk (4919) el Miércoles, 29 Septiembre de 2010, 18:14h (#1241582)
    tienes toda la razon ; es mucho mejor ir encorbatado apestando a hugoboss
    y no tener putaidea de nada mas que clicar 3 botones

    espana rules!
    [ Padre ]
  • por toggle (46333) el Miércoles, 29 Septiembre de 2010, 18:16h (#1241583)
    ( Última bitácora: Viernes, 04 Febrero de 2011, 10:50h )
    Y poe eso en cuando se acabe el avál del BCE van a caerse todos estos proyectos.
    [ Padre ]
  • 19 respuestas por debajo de tu umbral de lectura actual.