¿Qué pasa en este país?
Nota de Ingenieros de Primera: Este artículo centra el debate sobre la actividad de la programación. Aún siendo conscientes de que hemos remarcado que los Ingenieros e Ingenieros Técnicos no son exclusivamente programadores, hemos considerado interesante su publicación porque no puede obviarse que los titulados realizan en su mayoría estas labores, y que las reflexiones del mismo pueden ser extrapoladas a otras actividades.
Sobre el Autor: Alejandro Conty es Ingeniero en Informática, creador del motor de raytracing YafRay, así como de otras aplicaciones de software libre. Actualmente trabaja en su propia empresa de desarrollo.
Este artículo recoge una serie de impresiones personales sobre el mundo laboral del programador en España. Las directivas que en él se recogen no son evidentemente aplicables como norma. La intención del texto es la de denunciar una serie de aspectos a mi juicio profundamente perjudiciales para el sector.
Como se menciona en "The mythical man-month": Recogiendo patatas el individuo más productivo puede tener una relación de 2, como mucho 3 a 1 contra el menos productivo. En el mundo del desarrollo de software, la relación entre el más productivo y el menos productivo puede ser de 10 e incluso 100 a 1. Sin embargo, el más productivo aceptará trabajar sólo por el triple.
Esta ventaja que en principio tienen los empresarios pasa totalmente desapercibida en este país. Hay ya unos cuantos programadores que pueden ser productivos. También hay unos pocos programadores brillantes que podrían, en el entorno adecuado, generar verdaderas fortunas. Pero el programador no es una persona respetada en el mundo laboral. Ni siquiera se le respeta en la calle.
Uno se encuentra programadores cobrando menos que los del servicio de limpieza. No es que éstos deban cobrar menos, es que los programadores deberían cobrar más. Además nos da una idea de como valora la empresa el papel del programador. Al fin y al cabo, en la industria del software son los programadores los que crean riqueza de la nada. Es difícil entender como pueden tener una valoración tan baja. También es sorprendente que los propios programadores lo consientan.
Todos sabemos lo que supone reemplazar a un programador en medio de un proyecto. Puede significar un retraso de 6 meses en el mejor de los casos. El atasco completo del proyecto en el peor de ellos. Pero nadie en la dirección de las empresas se da cuenta. Es más, ni siquiera les importa. En España el 90% de las empresas se dedican a vender humo o a hacer proyectos con la Administración cuyo buen fin preocupa a muy pocos. No es de extrañar que de aquí no salga ninguna empresa espectacular como Skype, Keyhole, o no digamos ya, Google. Debe existir algún motivo.
Trabajando como programador uno se enfrentará a un montón de iluminados visionarios que, sin tener ningún conocimiento, proponen cada día ideas como "¿Y si hacemos un sistema de telefonía por internet?". Normalmente estos ataques de creatividad ocurren al día siguiente de que salga por la tele la noticia de que alguien ha hecho lo mismo en alguna parte. A los dos años cuando la idea esté ya implantada podrán decir "eso se me ocurrió a mí, pero nadie me apoyó".
Todo este entorno frena a cualquier programador de provecho de hacer nada útil ni revolucionario. A diferencia que en otros paises, las empresas de tecnología no están dirigidas por personal técnico. Están dirigidas por gente de mucho dinero o tipos que ganaron algo de dinero haciendo otra cosa y ahora quieren apuntarse al carro. Nunca saldremos del agujero tecnológico hasta que esto cambie.
En mi corta experiencia como programador he ido desarrollando fuertes alergias a prácticas comunes. Como ahora están de moda los estatutos, he decidido empezar a redactar un Estatuto de los Programadores. Para generar polémica, todo estatuto tiene que tener un preámbulo incendiario que reclame derechos de nación o algo similar. Como no está el horno para bollos, hemos de maquillarlo un poco para que no suene muy radical. El preámbulo propuesto es el siguiente:
"El mundo de la programación es una realidad prostitucional"
Dicho esto procedemos con el primer y más importante artículo:
Artículo 1: Toda persona incapaz de realizarlas tendrá, terminantemente prohibido, tener ideas
Lleva un poco de reflexión darse cuenta de cuánto beneficio haría una norma como ésta. Primero invito a pensar si podría en algún caso hacer daño a la sociedad. ¿Ha habido alguna vez una buena idea tecnológica o científica que surgiera de mano de alguien incapaz de desarrollarla? Aunque así fuera (que no es), la idea se hubiera echado a perder por la mala gestión de la misma. Resulta impensable que el jefe de la oficina de patentes donde Einstein trabajaba se presentara un día en el trabajo diciendo:
"Albert, he pensado que quizás la velocidad de la luz es una constante universal no sujeta a la medición relativa que sufren todas las demás mediciones. Las consecuencias pueden ser muy interesantes, podemos llegar incluso a la energía nuclear. Quiero que dediques todos los días un par de horas a desarrollar esto. Tiene que estar listo en seis meses.
Los hitos del proyecto son:
- 1905 - relatividad especial (un primer boceto de la idea)
- 1915 - relatividad general (desarrollo matemático y generalización)
- 1950 - centrales nucleares"
Es mucho más probable que lo que ocurriera fuera algo como:
"Albert, el futuro es desarrollar unas nubes tan densas que la gente pueda volar en ellas y viajar prescindiendo del avión, que es un invento obsoleto. En dos años ya se habrá superado y no podemos quedarnos atrás. Así que deja esos papeles que garabateas todos los días y ponte con esto ya."
Las ideas son mucho más que una simple frase. En el mundo de la programación no cuenta sólo la idea, sino la idea de comó llevar a cabo la idea. A los fundadores de Google no se les ocurrió simplemente hacer un buscador. Eso lo hacía todo el mundo por aquel entonces. Se les ocurrieron ideas para hacer uno mucho mejor que el de los demás. Y eso nunca podría habérsele ocurrido a un tipo que reunió unos millones vendiendo camisetas y ahora quiere revolucionar la informática (porque él lo vale).
Un día el jefe llega y dice "Vamos a hacer un programa de CAD que desbanque al AutoCAD". Uno se queda esperando por lo que debería venir a continuación. A ver cuáles son esas ideas para un programa de CAD revolucionario. Pero no las hay, eso ya lo hará el programador que contratemos. Al final, si a caso el jefe nos dirá donde colocar los botones de dibujado para que el programa sea bueno de verdad.
Este tipo de casos tendrían que conllevar incluso penas de cárcel. Es por ello que el artículo 1 es fundamental. Las prácticas como ésta llevan a un total desperdicio de tiempo, dinero, paciencia y todo tipo de recursos.
Vamos ahora con el segundo artículo de nuestro estatuto:
Artículo 2: El uso del PowerPoint y herramientas similares será perseguido y castigado
Admito que puede parecer demasiado radical. Cierto es que a la hora de exponer algo a un público, unas transparencias pueden venir bien. Pero en los últimos años, estas herramientas se han convertido en el único objetivo de trabajo de un montón de desorientados. Es uno de los casos donde el medio acaba convirtiéndose en el propio fin. ¿A cuántas presentaciones vacías de contenido hemos de asistir para darnos cuenta? Una herramienta que permite a cualquiera hacer una presentación consigue implantar la creencia de que todos tienen algo importantísimo que decir.
Ahora mismo la relación señal/ruido en cuanto a presentaciones es bajísima en todas partes. Montones de personas en esta industria llegan cada día al trabajo para abrir inmediatamente el powerpoint y ponerse a hacer la presentación de mañana. Vendemos humo, pero vendemos humo con colorines, animaciones, gráficas dinámicas y sobre todo, mucha negrita e imágenes del catálogo "bussines".
Nadie que quiera decir algo necesita esa parafernalia. Siempre se han hecho "diapositivas", pero se hacían de otra forma, y no se hacía una presentación cada dos días. Lo que estos programas han creado, es una "cultura del powerpoint". El lector puede estar pensando ahora que el hecho de que un cuchillo pueda usarse para matar, no quiere decir que haya que prohibir los cuchillos. Efectivamente, pero si nos fijamos en el artículo 2, nadie habla de prohibir las herremientas. Se trata de perseguir y castigar su uso. ¿Cuántas veces hemos querido decir "Ese gráfico no dice nada, es más, causa confusión, vas a ir a la carcel chaval" ?. Que ocurra alguna vez es aceptable, pero no que ocurra todos los días, miles de veces, en todas las empresas al mismo tiempo.
Y finalemente vamos con el tercer y último artículo por ahora:
Artículo 3: Se prohíbe el desarrollo de ningún programa que no sea susceptible de ser programado por una sola persona.
Esto no quiere decir que no puedan trabajar varios en él. Pero un programa que no pueda ser hecho por un sólo programador está, sencillamente, mal pensado. ¿Qué pasa con los grandes sistemas complejos? Antiguamente se tendía al desarrollo de grandes programas monolíticos que tenían un montón de funcionalidades. Enormes sistemas de gestión que controlaban hospitales enteros, sistemas operativos que lo controlaban todo con el mismo código.
Ahora, la tendencia en el mundo ha cambiado. Esos grandes sistemas se desglosan en pequeños programas. Los sistemas de gestión se componen ahora de muchos servicios distintos que se interconectan usando múltiples protocolos. Los programas complejos de por si se reducen al mínimo de funcionalidades y se dejan puertas a la integración con otros programas que hacen otras cosas.
Con esta política de desarrollo, sin duda mejor que la otra, se consiguen programas que hacen unas pocas cosas muy bien. Los programas son más pequeños y por tanto más mantenibles. Incluso los sistemas operativos se dividen ahora en módulos totalmente independientes encargados de tareas específicas. Los clientes prefieren también estas soluciones, porque cuando quieren añadir algo nuevo al sistema no tienen que reemplazarlo todo. Pueden comprar el sistema de visualización de esta empresa, la gestión de bases de datos de esta otra y el interfaz web de la de más allá.
Pero aquí los empresarios no parecen haberse dado por enterados. Salvo unas pocas muy buenas, la mayoría de pequeñas empresas que quieren crecer se obsesionan con sacar un programa que lo haga todo. Tiene que servir para hablar por teléfono, para grabar cd's, para gestionar los clientes, para mandar un mail, etc ... Sólo las grandes compañías parecen adaptarse a este nuevo modelo de desarrollo. Pero es que en España, éstas llevan tiempo haciendo meras tareas de fontanería informática. En las pequeñas que se dedican a nuevos proyectos se cometen muchos errores. Incluso aunque parezca que los productos que se plantean son muy especializados, al final se le pide al programador que implemente todo tipo de funcionalidades que en ese programa no tienen ningún sentido. El resultado son programas que hacen un montón de cosas, pero ninguna bien.
Hay unos pocos ejemplos de empresas en España que triunfan con productos específicos y de calidad. No sólo por el personal de calidad, además tienen muy claro el objetivo del desarrollo. Por desgracia empresas así no abundan. Pero con pocas que sean, se demuestra que no es imposible.
Aquí acaba este primer boceto del estatuto del programador. Aunque son sólo tres directivas, son cruciales para arreglar el desastre local que sufrimos. Todo el mundo está invitado a intentar completar la lista de artículos en caso de que me haya olvidado de algún aspecto.
Ahora llegamos a la pregunta final. ¿Qué hacer? Lo primero abandonar ese tipo de empresas y convertirnos en su competencia. Muchos programadores deciden muy acertadamente ponerse a trabajar por cuenta propia. No todo el mundo se atreve debido a diversas razones. Entre ellas hay dos muy comunes.
La primera es el miedo a perder la tranquilidad de que vas a cobrar a final de mes. Pero esta tranquilidad no es más que una ilusión. Si en un momento dado la empresa deja de funcionar dejarás de cobrar. Y el problema es que no puedes hacer nada al respecto. Es decir, es posible, muy posible, que un grupo de inconscientes estrelle la empresa contigo dentro. Cuando sólo dependes de ti mismo o de otros como tú al mismo nivel, sí se puede hacer algo. Depende sólo de que hagas las cosas bien.
La segunda es una extraña concepción de la moral. Hay gente que considera incorrecto o desleal irse de una empresa para ir a hacerle la competencia. Hay que deshacerse de esa barrera imaginaria. La empresa no dudaría ni un segundo en prescindir de tus servicios si ya no te necesita. Tampoco verás un céntimo de la riqueza que hayas podido generar más allá de tu mísero sueldo. No sólo se debe hacer por uno mismo, los programas merecen ser bien hechos.
Por desgracia uno no puede decirle a su jefe que va a ser 10 veces más productivo y que quiere cobrar por lo tanto diez veces más. Tomo prestada esta frase de Paul Graham. Entre sus ensayos podemos encontrar un montón de consejos a la hora de lanzar iniciativas de empresa. Al contrario que yo, él es un hombre con experiencia en este campo. Su colección de "bombazos" empieza en el 95 con un sistema de comercio electrónico que vendió a Yahoo y que le hizo inmensamente rico. Obviamente no estamos hablando del típico que hizo dinero vendiendo ADSL y que ahora quiere hacer programas. Estamos hablando de un gran programador.
La falta de ambición es otro gran problema local. Nadie piensa ni de lejos que puede llegar a hacerse inmensamente rico con un producto. Algunos lo dicen, pero ni ellos ni los que les rodean creen realmente en ello. La gente aspira a ganar un poco de dinero para comprar un BMW y poder presumir en el barrio como "hombre de negocios".
Como advertencia a todo aquél que vaya a salir al mundo laboral de la programación como asalariado, aquí viene lo que encontrará:
- Salarios bajos. Dependiendo de la región, el sueldo de principiante va desde los 15000 a los 24000 euros al año. Teniendo ya cierta experiencia se puede llegar con suerte a los 30000. A modo de comparación, en Inglaterra, un sueldo de programador raso es de 50000 libras. Unos 80000 euros. Al igual más o menos que el resto de Europa. No mencionamos ya los sueldos de Estados Unidos por no deprimir al lector. La excusa del precio de la vida ya no es válida. Aunque un DVD cueste más que aquí, en Alemania se puede alquilar un piso por 300 euros.
- Régimen de desprecio. Generalmente se apila a los programadores en algún cuarto apartado. Si viene alguien importante, o simplemente, el gerente de otra empresa, en caso de que los llegue a ver será a modo de "Y estos son los programadores". Igual que si se tratara de una jaula de monos. Muchas veces he querido colocar un cartel de "no den de comer a los programadores". Este trato se debe a muchos motivos. Pero de todos ellos, el más sangrante es el miedo. El miedo a que alguien de fuera acabe haciendo una oferta a alguno de los programadores para que se vaya con él.
- Total anonimato. No tienes derecho a ningún reconocimiento externo por tu trabajo. El producto es de la empresa. Mejor dicho, del presidente de la empresa. Nadie vendrá a felicitarte por lo que has hecho y mucho menos verás un céntimo de los beneficios. En este país hay empresarios que serían capaces de poner a Miguel Angel a esculpir, hacer millones con sus esculturas y pagarle una miseria de sueldo. Porque al fin y al cabo, el mármol que usa es mío ... ¿Te gustan las esculturas que hace mi empresa?
Si no nos queda otro remedio que trabajar para una de estas empresas porque haya que pagar una hipoteca o cualquier cosa, mi consejo es el siguiente: Jamas regalar ni una sola idea a la empresa. Si se te ocurre cualquier forma de hacer mejor las cosas, lo haces en casa. Lo desarrollas por tu cuenta y ya lo venderás, lo darás como código libre o lo que apetezca. Ya que nos tratan como a ganado, actuemos como ganado. No hacer nada que no se ordene explícita y detalladamente.
No ha sido mi intención mostrar al programador como un individuo extramadamente valioso ni superior al resto de los mortales. El énfasis no se debe a una especial estima por la profesión sino al profundo agujero en el que se haya hundida. Pero existe el riesgo de que como pasó con otros colectivos marginados, se produzca un efecto rebote hacia la sobrevaloración. Convendría no esperar a que la herida fuera demasiado profunda o que todos hayan emigrado hacia otros paises. Este mal no es además exclusivo de la industria del software. Todos conocemos el fenómeno de la fuga de cerebros que sufren todas las disciplinas intelectuales en España. Este caso es sólo uno más de la lista.
Referencias:
- Ensayos de Paul Graham: http://www.paulgraham.com/articles.html
- Sobre PowerPoint:
Sin ánimo de ofender...
Me he reido un rato e incluso me he sentido identificado en algunos puntos, pero ese análisis es acerca de una realidad en la cual no está implantada la ingeniería del software.
Desgraciadamente, vivimos en esa realidad.
Quien pueda que salte pero no para hacer proyectos en solitario con el fin de controlarlo todo y hacerlo de maravilla sino para establecer el desarrollo de software como un proceso ingenieril.
Esta lectura sería perfectamente acertada en los 80 incluso 90, ahora me da que pensar seriamente acerca de mi trabajo 'Ingeniero Técnico en Informática' desempeñando labores en ingeniería del software.
Más bien al revés
La tendencia actual es hacer pequeños módulos que proporcionen servicios a otros. El ejemplo más claro es la POO donde cada clase especifica un interfaz público que establece un contrato de colaboración entre esta y las que la usan. Aún queda mucho más abierto el panorama con los servicios Web.
De este modo, cada uno debe preocuparse de que su parte funcione y haga lo que dice hacer. La concepción de la ingeniería tradicional aplicada al software era válida en los 70, 80 y 90, cuando los grandes sistemas eran cerrados y propietarios. Ahora la tendencia es justo la contraria. Los sistemas son cada vez más abiertos y orientados al cambio. Si para hacer un cambio tengo que poner de acuerdo a 50 personas estoy fracasando.
Por otro lado, los lenguajes de programación son cada vez más expresivos y más "human readable" ¿es suficiente el código fuente para modelar un sistema? Puede que sí, teniendo en cuenta el fracaso de UML como lenguaje de modelado, debido principalmente a que es descriptivo y ambiguo. No se puede realizar una implementación unívoca a partir de los diagramas de UML, que por otro lado necesitan gran cantidad de texto para ser comprendidos en su totalidad (lease, por ejemplo, un caso de uso).
La documentación adicional suele quedar obsoleta a las primeras de cambio y su mantenimiento coherente es prácticamente inviable, con lo que, tras un año de proyecto, si quieres saber lo que hace el sistema en cuestión debes acudir al código fuente, que nunca miente.
Se habla de emplear notaciones formales para análisis y diseño que eliminen la ambigüedad introducida por UML y similares, pero entonces ¿qué diferencia existe entre eso y un lenguaje de programación?
La conclusión de todo esto es: nos estamos equivocando pensando que un diagrama equivale a un plano en arquitectura y que los programadores equivalen a los albañiles. Realmente el plano es el programa en lenguaje de alto nivel y el albañil es el compilador. El reto de la Ing de sw está en hacer los lenguajes de alto nivel cada vez más expresivos y más comprensibles para los humanos.
¿UML ha fracasado?
Sólo quiero hacer unos comentarios personales sobre lo que has dicho. No es que quiera comenzar una batalla sobre "UML vs ¬UML", pero me gustaría equilibrar un poco la balanza a favor de UML. Ahí va:
¿es suficiente el código fuente para modelar un sistema? Puede que sí, teniendo en cuenta el fracaso de UML como lenguaje de modelado, debido principalmente a que es descriptivo y ambiguo.
No creo que UML haya fracasado como lenguaje de modelado. ¿Cuándo ha ocurrido eso? No estoy al corriente de tal hecho. En mi opinión, si se emplea bien, ayuda mucho a concebir un sistema. De hecho, la ambigüedad que plantea es a veces útil para abstraer ciertas cosas; así que más que ambigüedad, yo lo llamaría flexibilidad... y eso es bueno ;).
No se puede realizar una implementación unívoca a partir de los diagramas de UML, que por otro lado necesitan gran cantidad de texto para ser comprendidos en su totalidad (lease, por ejemplo, un caso de uso).
Siento discrepar, pero no no lo veo así. Para mí, los diagramas de UML son más bien un soporte para el texto y no al revés. Es decir, si el texto especifica algo con claridad y no describe un proceso muy complejo, ¿para qué hay que hacer un diagrama? Se hará si ello ayuda a mejorar la especificación.
Sobre la implementación unívoca a partir de los diagramas de UML, cada empresa tendrá sus convenios generales para convertir los diagramas de diseño en código. Incluso hay herramientas que generan la estructura del código (en varios lenguajes) a partir de los diagramas de UML, así que tampoco creo que sea un problema.
Se habla de emplear notaciones formales para análisis y diseño que eliminen la ambigüedad introducida por UML y similares, pero entonces ¿qué diferencia existe entre eso y un lenguaje de programación?
Pues que escribir programas es fácil, pero lento. Mucho más lento que describir algo "en prosa". En cambio, si ya se dispone de la documentación más o menos completa de todos los procesos del sistema, detallados, estudiados, etc., la escritura del código va a ser más ágil: el tiempo que se "pierde" por un lado se gana por otro. Y a mí, personalmente, me gusta programar sin tensiones, sin temor a que surjan cosas inesperadas.
UML fracasado
Fue una buena estrategia de marketing de Rational, pero no vale para mucho más.
Por mi experiencia (8 años como profesional desarrollando aplicaciones OO) puedo asegurarte que ha fracasado por:
- Las grandes organizaciones no lo usan más que para escribir casos de uso y diagramas de clase (a veces).
- Para que un programador programe un caso de uso sin preguntarte por los puntos oscuros tienes que perder más tiempo en escribirlo que en programarlo.
- Si especificas el caso de uso en detalle, el cliente no lo leerá y si lo lee no lo entenderá. Cuando le entregues el producto te dirá que no era eso lo que quería.
- Si especificas el caso de uso en unas pocas líneas, el cliente entenderá una cosa y el programador otra totalmente distinta.
- UML no está conectado unívocamente al código fuente (excepto en la vista estática). Cuando hay cambios, la coherencia entre código y documentación debe mantenerse a mano y, hazme caso, es extremadamente complicado. No digamos si introduces lenguaje natural como base de la especificación, como estás proponiendo.
- Lo único que se salva de UML son los diagramas de clase y aún así encuentras a poca gente que conozca la diferencia entre, por ejemplo, composición y agregación.
- Lo que comentas de la flexibilidad... bueno, puede ayudar a analistas ineptos a cargar la responsabilidad de su fracaso sobre el programador, que no lo entiende bien ¿quieres programar sin tensiones?
UML está bien para las prácticas de la carrera, pero no para un proyecto serio.
Un saludo
Mas bien es un conjunto de aspectos (UML)
Al menos según mi propia experiencia. Algunos aspectos a tener presentes:
1. Las grandes organizaciones no lo usan más que para escribir casos de uso y diagramas de clase (a veces) --> PORQUE SE VAN AL CRITERIO ECONÓMICO. El motivo es simple: con los casos de uso (y si están bien hecho) disponen de una herramienta de apoyo para explicar al cliente lo que se le va a ofrecer. Con los diagramas de clases, en muchos casos (y por usar Rational), tienen parte del código lo que les reduce el tiempo. Por no hablar de que a posteirori pueden modificar esas clases y que ello se transmita al código tb (nuevamente si se hacen bien las cosas). ¿Y el resto de diagramas? a los empresarios se la sudan... no tienen claro su necesidad o su objeto. Ese es un problema que con el tiempo entre todos deberíamos ir solucionando (ya que no podremos quitar a los jefes ineptos... tendremos que irlos "educando").
2. Para que un programador programe un caso de uso sin preguntarte por los puntos oscuros tienes que perder más tiempo en escribirlo que en programarlo.
Yo creo que si se hacen bien las cosas eso no sucede ni mucho menos. De todas formas, no veo claro a donde se quiere llegar. Los análisis son necesarios. Tardan el tiempo que tienen que tardar, son lo que une al cliente con el producto (el compromiso entre ambos, quiero decir), y lo que hacen entender a los programadores lo que el cliente ha pedido, y por último, son lo que nos sirve para el mantenimiento posterior y para no depender totalmente de personas concretas y el modelo de "lo tengo todo en mi cabeza". ¿Que lleva tiempo hacer un buen análisis? Si, pero luego se ahorra tiempo en el resto de ciclo de vida. ¿Que probablemente la culpa sea de los gestores que se empeñan en apretar los plzos hassta lo imposible y así no se hacen bien las cosas? Pues también. Pero sigue siendo un problema de otro tipo.
3. Si especificas el caso de uso en detalle, el cliente no lo leerá y si lo lee no lo entenderá. Cuando le entregues el producto te dirá que no era eso lo que quería.
Pues peor para el cliente. Porque eso es lo que ha pagado y lo que le van a dar. Y sino, id viendo como salen los temas en juzgados. El analisis se está considerando vinculante en la mayoría de los casos. Así que... ellos sabrán.
¿Has visto a algun comprador que no pregunte bien por los planos de su casa si es que no los entiende?
De todas formas, si se tienen muchas dudas por el tipo de cliente, que se haga un prototipado evolutivo, ¿no? a fin de cuentas es un ciclo de vida tan valido como cq otro.
4. Si especificas el caso de uso en unas pocas líneas, el cliente entenderá una cosa y el programador otra totalmente distinta.
Otra vez estamos hablando de cuando las cosas se hacen mal. Y es que, volvemos a lo de siempre. Para hacer el análisis hay que dar el tiempo necesario al analista y... ademas contratar analistas de verdad. Y esto no va por ti, evidetnemente. Pero queria apuntarlo porque ya me estoy cansando muchas veces de oir a compañeros del sector preguntandome por ese lenguaje de programación que sale en ofertas de trabajo y que se llama UML ¿?, o de oir que un analista es un "documentador", joder el producto final es un documento y por eso es "documentador"? pues nada un programador por esa línea de tres es.... ¿"ficheador"? ¿o "DVDador" porque va en un DVD?
5. UML no está conectado unívocamente al código fuente (excepto en la vista estática). Cuando hay cambios, la coherencia entre código y documentación debe mantenerse a mano y, hazme caso, es extremadamente complicado. No digamos si introduces lenguaje natural como base de la especificación, como estás proponiendo.
Hombre, es que creo que le pides mucho al UML. En realidad el UML adquirió la particularidad de estar conectado al código fuente amen de Rational... si eso echales la culpa a ellos. Pero el UML es un lenguaje de modelado. Por ejemplo... el OMT no tiene una herramienta ocmo rational que genere nada ... ¿y? pues nada, que es para hacer el análisis y diseño, sin mayores pretensiones.
Támbién han surgido en el mercado herramientas de extracion de requisitos ... pero que lo hagan mejor o peor o que conecten o no con las siguietnes fases no hace que la especificación de requisitos sean menos necesarias ¿no crees?
6. Lo único que se salva de UML son los diagramas de clase y aún así encuentras a poca gente que conozca la diferencia entre, por ejemplo, composición y agregación.
Ya, y poca gente que conozca el significad de diagrama de clase (y te sorprenderías si escucharas la explicación que me dio uno un día sobre lo que es un diagrama de caso de uso.. flipante). Pero es que no podemos confundir la falta de formación, de analistas y desarrolladores, o la mala ejecución con el sistema/modelo/metodología en sí mismo.
Por cierto, y hablando de malos analistas, perdonadme pero todavía no he visto programadores bien formados que entiendan los diagramas que se les ponen delante (probablemente por el nivel de intrusismo). Y eso... creo que es su obligación. Vamos, que quien quiera trabajar en el sector, al menos se forme ¿no? Yo se de muchas empresas que no se atreven a implantar una metodología o el UML porque sus programadores no tienen la preparación imprescindible para trabajar a partir de ello.
En fin, que UML no es la panacea, desde luego. Y que le queda por mejorar. Pero si es Ingeniería, puede que todavía le falte para ser ideal , pero yo si he visto proyectos en los que se ha utilizado con buenos resultados (tanto la parte de análisis como la de programación, y con satisfacción del cliente). Puede que lleve más tiempo inicialmente... y eso no interesa a los criterios de muchos gerentes, pero el resultado final merece la pena.
Lo que no es una opción, desde luego, es no tomar ninguna metodología o modelado y ponernos a tirar líneas de código en base a una anotaciones que hizo un compañero en una reunión. Eso es un paso atrás inmenso (y en eso estaremos todos de acuerdo).
Respecto al paralelismo con las obras, os propongo que probemos al revés:
--> Le doy a un obrero el material para que construya la casa sin los planos. Lo hará mejor o peor, pero bueno, seguro que no se cae.
--> Y ahora que tu compilador me construya el proyecto sin los planos (que según tú era el código!)... a ver si puede ;-)
No podemos comparar el trabajo de un compilador (que es absolutamente "tonto", y de alguna forma es "interpretar" lo que se le entrega como código) con el de un obrero, que no se le puede considerar trabajo "tonto" por el simple hehco de que este compuesto por ciertas tareas mas o menos mecanicas. Por cierto, si un obrero (o mas bien su jefe de obra, que nos estamos pasando por alto esta figura todos, me temo) interpreta los planos y se pone a ejecutar la obra (y que yo sepa en lineas generales no tienen una gran formacion academica)... ¿por que el 90% de los programadores no saben leer los análisis? ese es otro buen tema de debate.
Salu2 a todos.
El debate es estéril
Veo que este debate está siendo estéril. Sólo el que se haya enfrentado a problemas graves con la gestión de cambios, la traza de requisitos y la coherencia entre todos los elementos que forman un proyecto sw puede comprender lo que estoy diciendo.
Los ingenieros y arquitectos usan el dibujo técnico (formal y no ambiguo) y las matemáticas (idem) para modelar. Nosotros si modelamos con un lenguaje formal estamos programando. Si modelamos con un lenguaje descriptivo (UML), de nuestro modelo pueden salir infinitas interpretaciones y los cambios a lo largo del ciclo de vida van a producir (siempre) incoherencias, no porque las cosas no se hagan bien, si no porque es imposible gestionar esa cantidad de información.
Resumen:
- Gestión de cambios
- Formalismo vs descripciones
Pongamos el caso práctico de especificar un campo de entrada:
- Tipo
- Formato
- Validaciones
- Conversiones
- Tamaño
- ...
¿Qué diferencia existe entre especificarlo en un fichero XML bien formado o en un documento Word usando lenguaje natural?. De esfuerzo, ninguna. Beneficios de hacerlo en XML todos. ¿Qué ocurre si ese XML pasa a formar parte del código fuente del proyecto? ¿Está programando el analista? ¿Se ha manchado sus manos? Con los mecanismos actuales de abstracción ¿existe un salto real entre análisis diseño y programación?
Y por favor, no me respondais lo que os (nos) adoctrinan en la carrera. No estoy negando la necesidad de análisis y diseño. Estoy diciendo que con los mecanismos actuales, "programar" es una tarea mucho más inteligente ahora que en los años 70 y que análisis, diseño y programación pueden ser realizadas por la misma persona, tal y como propugnan los promotores de los métodos ágiles.
Bueno
De partida piensas que el resto no hemos participado en proyectos complejos y que decimos solo lo que hemos oido en la carrera. Pues vale.
Yo veo que en realidad los métodos ágiles SI que hablan de eliminar la etapa de analisis/diseño, por más que digas que no. Y aqui nadie esta hablando de que si es mancharse las manos programar ni nada de eso, no mezclemos, no estamos hablando de si la figura es Analista + Programador o Analista/programador.
Y aunque es obvio, no, no estoy muy de acuerdo con los métodos ágiles. Y han pasado por mis manos resultados muy reales de aplicarlos y dan risa. MI experiencia en esto, al final: código mondo y lirondo, comentarios nulos (o lamentables) y de pruebas mejor no hablar porque na de na (mucho tirarse el pisto con lo de las pruebas unitarias y luego resulta que se hace simple prueba y error de casos básicos). Y el cliente, muy muy descontento y diciendo que no se le había entregado lo que pedía (¿de que me suena esto?)
ahhh y para el que no quiera oir, se trataba de Programación Extrema (que se supone una de las mejores).
Y eso, no es mantenible. Y de eso tambien tengo experiencia (por desgracia).
Por último, ¿No se dijo en este mismo hilo que el cliente no entendía bien lo que se le entrega como casos de uso? ¿que pasa, que entiende mejor el XML y por eso propones que se sustituya con esto? amos, no fastidies.
Y si, estoy de acuerdo, siempre que se discute este tema es estéril. Porque unos estamos claramente posiiconados en un sentido y otros en otro. Y no veo que nadie vaya a convencer a nadie.
XP sin pruebas?
Si dices que has visto aplicar XP sin haberse hecho pruebas es que no has visto aplicar XP, porque precisamente es una metodología de desarrollo dirigido por pruebas. Vamos que si no escribes las pruebas antes no tienes nada de nada. Posiblemente los que dijeron a ese cliente que estaban aplicando XP no eran más que unos estafadores de los que gustan de usar palabros para que parezca que saben. Y de eso, trístemente, hay mucho en esta profesión.
Respecto a lo que dije de XML, un documento XML puede ser transformado en texto, pdf, word,... y eso lo puede leer el cliente. Ese mismo XML puede formar parte de un producto ejecutable... y eso lo puede leer la máquina. Lo importante es que ambos lean lo mismo.
Y no hablo de hacer los proyectos sin metodología (de hecho no he criticado ninguna metodología), yo sólo digo que UML como lenguaje de modelado sirve de poco por su falta de trazabilidad. Los DFD de Yourdon, por ejemplo, tenían muchísima más trazabilidad hacia el código fuente. Si alguien ha usado Designer de Oracle sabrá a qué me refiero.
Por último, te recomiendo la lectura de, por ejemplo, http://haacked.com/archive/2005/08/18/9536.aspx
Entonces nuestra opinión...
... no está tan alejada como parece.
De hecho, añoro la epoca Yourdon (que ahora a nadie le mola que se utilicen DFDs y a mi me parecía bastante clarificador). Creo que si UML se ha impuesto es por su orientación directa a OO y por existir el Rational (que claro, vende mucho con lo de "genera código automáticamente"). Que sino... dudo que tuviera tanto exito.
Y el XP... te aseguro que he visto lo que entrega una empresa que se vende como modelo a seguir en programación agil (no quiero decir nombres porque me gano una demanda seguro) y ... pufff... miedo daba.
Al final, unos cuantos programadores tirando líneas en base a conversaciones teléfonicas y e-mails... y pruebas ... bueno, si hacían pruebas del caso base, da gracias. Patetico. Un ejemplo a no seguir y una verdadera vergüenza para la profesión... y por desgracia es una empresa con un gran fondo de Ing. en Informática. Triste ¿eh?
Mi opinión
Desde la humilde opinión de un estudiante de la carrera, creo que el problema está en muchos casos en la falta de un estándar para cada uno de los procesos del ciclo de vida. Hay muchas empresas que no usan UML (que es estándar de facto), por cómo bien dices el intrusismo. El intrusismo en Informática en España es absolutamente vergonzoso. Algunos programadores y aun peor, analistas o Jefes de Proyecto con formación CCC no saben que diantres es un lenguaje de modelado.
Otro de los problemas gravísimos que se presentan en los desarrollos de software a medida son los cambios propuestos por el cliente a la mitad del ciclo de vida. Vamos a ver, yo no me lo puedo creer, de verdad. ¿Por qué se aceptan cambios en la Ingeniería del Software y no en la Arquitectura o la Ingeniería Civil? Alguien se ha planteado que si le digo yo a un arquitecto que me haga un plano para una casa, se hace el plano, se empieza a construir la casa, y cuando está casi terminada digo que quiero cambiar algo, ¿me mandan a tomar morcillas?
Cambios a esas alturas significarían pérdidas multimillonarias (para mi bolsillos, por supuesto, por mequetrefe). Hagamos o intentemos conseguir que el cliente especifique lo que quiere al principio y no casi al final porque "éso que está hecho no es exáctamente lo que yo quería". ¿Qué cojones quería usted entonces?
El software no es una casa
Otro de los problemas gravísimos que se presentan en los desarrollos de software a medida son los cambios propuestos por el cliente a la mitad del ciclo de vida. Vamos a ver, yo no me lo puedo creer, de verdad. ¿Por qué se aceptan cambios en la Ingeniería del Software y no en la Arquitectura o la Ingeniería Civil? Alguien se ha planteado que si le digo yo a un arquitecto que me haga un plano para una casa, se hace el plano, se empieza a construir la casa, y cuando está casi terminada digo que quiero cambiar algo, ¿me mandan a tomar morcillas?
Cambios a esas alturas significarían pérdidas multimillonarias (para mi bolsillos, por supuesto, por mequetrefe). Hagamos o intentemos conseguir que el cliente especifique lo que quiere al principio y no casi al final porque "éso que está hecho no es exáctamente lo que yo quería". ¿Qué cojones quería usted entonces?
Cuando modelas un sistema informático estás haciendo algo mucho más abstracto que un puente o una casa. Estás actuando directamente sobre el comportamiento de las personas que lo van a utilizar. El comportamiento no es algo medible como la inclinación de un terreno, la dureza de un suelo o la anchura de un rio. Si es complicado concebir sistemas informáticos para organizaciones cerradas, imagina lo que es en la actualidad con Internet y los sistemas abiertos. Estás modelando para la totalidad de la población.
Es lógico que un sistema informático esté sometido a continuos cambios. Nadie tiene tanta capacidad como para prever su impacto, sus posibilidades futuras o sus vulnerabilidades. En este mundo, el que mejor gestione el cambio será el que triunfe.
Me hace pensar esto...
Estoy mascullando...
Razón tienes, en parte...
hay que hacerse de valer
Lo que pasa es que nos tenemos que hacer de valer. Os cuento mi historia que es bastante larga:
Yo empezé mi vida laboral informática trabajando en una empresa durante 5 meses como principiante cobrando 14K al año. No estaba tan mal, ya que acababa de terminar la carrera y no tenia nada de experiencia, pienso que es un periodo que debemos pasar para ganar experiencia. Pero a partir de ese periodo no es normal que tengamos sueldos tan bajos.
Busqué otro trabajo y enseguida encontré otro cobrando 18k al año, que aún siendo un poco bajo, no estaba mal teniendo solo 5 meses de experiencia laboral. Lo que pasa es que era una empresa muy pequeña, eramos 4 en total, y si no habia proyectos pues no podian mantenerme en la empresa, así que cambié a una consultora grande.
Me equivoqué, esta empresa si que explota a los informáticos, me ofrecieron solo 16k. Sacrifiqué el sueldo por tener mayor estabilidad. Me contrataron como programador junior. Enseguida me ascendieron a programador senior porque se dieron cuenta que yo estaba en una categoría muy baja que no me corresponde, pues resulta que pensaban que 8 meses de prácticas que hize en una empresa mientras terminaba la carrera, los pasé haciendo fotocopias, es decir, que no lo contaban como experiencia en informática. Mentira, porque yo estuve trabajando como informático y encima les había llevado una carta de la empresa que explicaba lo que había hecho allí.
Y aquí me hicieron la guarrada. Me subieron a programador senior, pero no me aumentaron el sueldo. Me dijeron que como mi categoría se debió a un error con mi currículum, era una rectificación, y que mi sueldo ya estaba bastante bien ¡¡incluso como programador senior!!. Se creen que la gente somos gilipollas, no hubo manera de discutirles, me tenia que fastidiar. Asi que yo pensé ¿ah si? pues a la mierda. Busqué otro empleo y me largué.
Me cogieron en otra empresa pequeñita, ganando 20,5K al año, la cosa mejoraba. Estuve muy agusto durante unos meses, hasta que me compré un piso y ya el sueldo se me quedaba corto. Así que busqué en infojobs y en dos semanas encontré otro empleo como analista programador. Otra consultora grande, pero esta vez no me dejé tomar el pelo. La cosa ha mejorado bastante, 28k. Así que desde que empezé como informático, en abril de 2005, he multiplicado por 2 mi sueldo.
He de decir que durante esas dos semanas, otras empresas me llamaban, y cuando me preguntaban por cuanto me cambiaría, yo se lo decía, sin cortarme un pelo. Ninguna volvió a llamarme excepto una, que es en la que me han contratado. Espero estar en esta muchos años y no tener que cambiar de empleo para mejorar.
Para concluir, es normal que al principio, recién salidos de la universidad, el sueldo sea bajo, pero a partir de ahí os debéis hacer de valer. Que no os tomen el pelo, no aceptéis cualquier cosa, porque hay mucha demanda, y tarde o temprano alguien os cojerá. Yo cometí un error cuando acepté 16k, pues si hubiera esperado un poco, habría encontrado otro sitio donde me ofrecieran algo mejor. Si todos actuamos así, al final las empresas que ofrecen tan bajos sueldos, van a tener que subirlos, o se quedarán sin empleados.
APRENDER A "DE HABLAR" Y A "DE ESCRIBIR"...
ESTOY DE ACUERDO EN HACERNOS VALER O INCLUSO, EN DARNOS A VALER, PERO TAMBIÉN TENEMOS QUE IR A APRENDIENDO A "DE HABLAR" Y A "DE ESCRIBIR"... y a no "de estresarse" tanto
Es un ejemplo de libro
Estoy de acuerdo en todo, excepto en la última frase. Se quedarán sin buenos empleados, claro está. Los empleados que tengan, serán poco fiables, y al final la calidad del producto estará por los suelos. Pero quizás puedan coger empleados sin titulación que acepten ese sueldo. O titulados sin experiencia, deseosos de entrar en el mundo laboral y hacerse valer. Lo que no debería haber es empleados con titulación y con experiencia (esto es importante, porque como bien dices al principio es normal cobrar menos) cobrando 14.000 € anuales.
El ejemplo que pones es de libro: Y es que si uno no está a gusto, y vale mucho más de lo que le pagan los contratos son bidireccionales (el trabajador se compromete con la empresa, pero también la empresa se compromete con el trabajador: te pago un salario por un trabajo bien hecho, y trabajo contigo por un salario justo en condiciones decentes). Lo puede romper el empresario, pero también lo puede romper el trabajador, e irse a otra empresa, tranquilamente. Y ojo, que un titulado universitario ya vale mucho simplemente por tener el título. Esto último, la única manera de entenderlo que tienen los empresarios es viendo cómo su empresa con una alta rotación de ingenieros no crece, y la competencia que los trata bien, puede pagar buenos salarios, y no sólo eso, sino que consigue muuuuchos beneficios.
Muchos empresarios se enfadan cuando ¡aprenden y se me van! Pues págales lo que valen, trátalos bien, y ya verás cómo no se te van.
De todas formas, el problema sigue siendo siempre el mismo, la validación de todas y cada una de las etapas de cualquier desarrollo por un Ingeniero (Técnico) Informático, y que se valore nuestra titulación, que cada cual ocupe su lugar en la cadena de desarrollo. Y que siempre siempre en un proyecto las decisiones técnicas las tome personal cualificado (esto es, Ingenieros o Ingenieros Técnicos Informáticos). Y los comerciales, que se atengan a lo que se puede hacer (o sea, que consulten a un Ing. (Téc). Inf antes de decir una tontería detrás de otra), que no vendan imposibles por miserias de dinero. Mientras esto no suceda, a los clientes siempre les podrán dar gato por liebre, y seguirá habiendo empresas aprovechadas.
También en España al menos, sería necesario establecer la Responsabilidad Civil en el caso de Proyectos Informáticos. España es un país especial, en el que en muchos casos no hay ética, y si no obliga la Ley las cosas no se hacen (incluso si obliga también hay muchos que se la saltan). Por ello, es muy conveniente que los Proyectos Informáticos que puedan causar daños a terceros lleven aparejada la Responsabilidad Civil correspondiente.
Creo que la mayoría
La mayoría de los proyectos llevarían aparejada la Responsabilidad Civil, puesto que el riesgo de pérdidas económicas siempre está patente, y más si son miles de millones.
"España es un país especial, en el que en muchos casos no hay ética, y si no obliga la Ley las cosas no se hacen (incluso si obliga también hay muchos que se la saltan)"
Acabas de reflejar en una frase la "picaresca española", existente yo creo que desde que se "inventó" España. España es un país de pandereta, y si un empresariucho se puede ahorrar dos míseras pesetas a cambio de contratar personal menos cualificado, o saltándose la Ley, aunque redunde en la calidad del producto, pues lo hace. Aunque luego las pérdidas económicas sean importantísimas porque le trinquen en fraude o porque el producto sea basura. Pero ojo, no aprenden.
Señores, esto es Ejpein, un país que está muy bien para muchas cosas, cómo emborracharse por la noche, tomar el sol en la tumbona en Benidorm o hartarse a cervezas y tapas en la plaza; pero que para otras cosas sigue siendo Ejpein. Ya lo decía Fraga: "Spain is different". Somos un país lamentable.
Comentarios recientes
hace 5 horas 5 mins
hace 5 horas 14 mins
hace 5 horas 31 mins
hace 5 horas 36 mins
hace 5 horas 51 mins
hace 6 horas 30 mins
hace 17 horas 7 mins
hace 17 horas 23 mins
hace 18 horas 14 segs
hace 21 horas 51 mins