Este tema me preocupa que me acerco peligrosamente a los 40 jaja. En mi experiencia entre las distintas variables que determinan si alguien es buen o mal desarrollador la edad no es de lo más determinantes, conozco chavales de menos de 25 que son increíblemente buenos y gente de más de 40 anquilosados, y también conozco todo lo contrario. Al final la edad va acentuando lo que uno es, el que es bueno con la edad irá siendo mejor y mejor por la experiencia acumulada y el que es malo cada vez sera peor por el desgaste, la falta de actualización y el encabezamiento con x formas de hacer las cosas anticuadas y que siguen aplicando porque si, sin contextualizarlas, porque en el fondo nunca las entendieron
"...muchos proyectos informáticos públicos que han pasado por mil manos..."
Este es el problema, y no sólo por los fallos de seguridad que son los que salen en la noticias y llaman la atención, lo que está mal de base es la forma en la que la administración desarrolla el software que necesita. A ver cuando alguien entiende que el software no es un producto cerrado que se encarga como el que compra una mesa, el software es algo en constante evolución que contiene las reglas de negocio con las que funciona la administración, el conocimiento sobre cómo está construido este software y la capacidad para cambiarlo no se puede dejar en empresas externas, tiene que estar en la propia administración.
Si no tienes capacidad de modificar el software que gobierna tu administración sin recurrir a empresas externas, has perdido tu autonomía como organización y no tienes control sobre la calidad del software que te gobierna. Actualmente el software tiene un papel CENTRAL en cualquier organización compleja, y cada vez tendrá un papel más y más importante, si lo dejas en manos de terceros, y encima de terceros cuya única preocupación es vender horas de programadores y llenarse los bolsillos, pues estos son los resultados. Claro que no es un problema aislado el caso de lexnet, es una evidencia más (como si hubiera ya pocas), de que este modelo de desarrollo de software para la administración no funciona y además nos cuesta una pasta a todos.
"El precario sector del software", no el sector no, una parte del sector es precario, por suerte no todo son cárnicas. ¿qué porcentaje del sector tienen esas carnicas?, la verdad es que no tengo ni idea, ni yo ni nadie porque no hay números de esto, no se puede hablar de las cárnicas como si fueran "todo" el sector porque no lo son.
De todas maneras, el problema gordo por desgracia no tiene que ver sólo con corruptelas y amiguismos como dice el de los tuit, ojala, pera la realidad es que hasta en una licitación limpia se siguen haciendo las cosas mal porque lo que falla es el enfoque de cómo la administración construye el software que necesita.
El problema es que la administración utiliza el mismo procedimiento para hacer software que para comprar mesas de despacho, el software no es un producto con X características que se empieza un día y se termina otro. El software en un administración es el sistema nervioso de la administración, es donde están las reglas de negocio que rigen su funcionamiento, si mañana quieres cambiar el funcionamiento de esa administración eso lo vas a tener que reflejar en tu software de alguna manera. Este software no es un desarrollo cerrado, es algo vivo que esta en constante cambio . Con esto en mente, externalizar todo el desarrollo es una barbaridad, la propia administración tendría que tener la capacidad de desarrollar y evolucionar este software, y sobre todo, tener de forma interna el conocimiento para hacerlo. Otra cosa es contratar empresas externas especializadas en esto y aquello para que te ayuden con determinadas cosas, cosas como formar a tu equipo, cosas como hacer una auditoria de seguridad etc,etc.
Mientras esto no cambie, la administración seguirá construyendo software de mierda gastando mucho más dinero del necesario, que sale de los bolsillos de todos. Los únicos contentos con la situación, los dueños de las cárnicas que se forran a costa de construir software de mierda en condiciones para sus trabajadores, no se si precarias, pero desde luego no muy buenas.
#91 No, no estoy diciendo eso, no inventes, y un consejo, de paso deja de inventar porcentajes así a boleo sin el más mínimo criterio.
No hacéis más que llorar, españa es una mierda!, las carnicas son una mierda!, no tengo suerte!. Y luego alguien os plantea que en esta profesión hay alternativas a eso, y lo atacais como si fuera el enemigo, pues nada chico, a seguir nadando en la mierda que parece que es lo que os gusta, es alucinante.
#86 ¿Manipular?, estoy informando de que igual que hay ofertas de mierder como la que tu has puesto hay otras muchas empresas que si buscan talento y ofrecen unas condiciones razonables. Evidentemente exigen unos conocimientos, no te van a pagar 45k al año por reinstalar windows con 0 años de experiencia.
Ahora, con esta información ya que cada cual haga lo que quiera, una opción es ver que piden este tipo de empresas que ofrecen buenas condiciones y prepararse en esa dirección, luego otra segunda opción es seguir lamentándose de lo mala que está la cosa. Cada cual que elija, yo sólo informo y no tengo ningún interés. En realidad si tengo uno, que alguien que este empezando en este mundo no se desanime con tanto cenizo, que esta profesión puede ser una forma cojonuda de ganarse la vida.
#72 O gente que trabaja en remoto desde cualquier parte porque son muy buenos en lo suyo, o gente que ante la situación ha decidido montarselo por su cuenta y correr el riesgo, o gente que se fue unos años a esas malditas ciudades y luego pudo volver a su zona con la experiencia adquirida, o en definitiva, gente que piensa que su futuro profesional no depende de factores externos (aka suerte) y que han sabido buscarse la vida (que ni es tan difícil, ni requiere tanto sacrificio en esta profesión por dios).
Ahora, si lo que quieres es quedarte en tu casa y esperar que alguien llame un día a la puerta ofreciendote 3000 euros por currar 3 días a la semana, pues entonces, coincido contigo en que para eso hace falta suerte.
#68 No, es más dificil, requiere más esfuerzo, pero no es cuestión de suerte.
De todas maneras, si tu crees que es cuestión de suerte, pues nada, sigue esperando a ver si un día te toca. Mientras tanto te podría hablar de gente casi en cualquier lugar de españa a la que le va de puta madre en esta profesión, y todos tienen algo en común, ninguno se quedó sentado esperando su "suerte".
Porque no se han leído peopleware, en concreto el capítulo "furniture police" un libro fundamental sobre management, centrado en desarrollo de software pero extrapolable a cualquier trabajo de oficina en muchos casos. Y mira que es antiguo...
#104 Estoy de acuerdo con casi todo lo que dices, pero no entiendo esa insistencia en decir que el agilismo es una metodologia en lugar de un conjunto de principios y valores. Scrum por ejemplo, define una serie de herramientas concretas para dar soporte a esos principios, scrum es un método concreto de materializar esos principios y valores, pero el agilismo en si no prescribe ningún proceso concreto, por eso no creo que el agilismo se pueda catalogar como metodología porque sólo define un marco conceptual y no procesos concretos.
Entiendo que esto es más un problema de naming y de semantica que otra cosa, por lo que dices me da la sensación de que estas considerando al agilismo como el conjunto de esos valores y principios más una serie de metodologias concretas que los materializan. En mi visión el agilismo es sólo el marco conceptual y las metodologías son procesos concretos para materializar las ideas de ese marco conceptual. Pero estamos hablando de lo mismo.
En lo que no estoy de acuerdo contigo es que el problema sea que la gente se lea el manifiesto y piense que el agilismo es algo hipster o poco serio. Yo el problema que me encuentro con más frecuencia es el contrario, que la gente se lee una guia de Scrum y lo aplica siguiendo la receta a ciegas sin leerse el manifiesto y sin entender los principios, y esto lleva a implementaciones de scrum fallidas y terminar haciendo cargo-cult scrum. Un ejemplo clasico es cuando la dirección de la empresa X decide implantar scrum porque algún jefecillo ha oído campanas pero luego quieren una estimación inicial del proyecto a un año vista, "Responding to change over following a plan" pero me das una fecha exacta de fin.
Y claro que esto es serio e ingenieristico si quieres llamarlo, no se si has visto esta charla de Gleen Vanderburg, si no la has visto echale un ojo que intuyo que te va a gustar: www.youtube.com/watch?v=NP9AIUT9nos
Y hombre no te trato de tonto, pero no me vengas "corrigiendo" y afirmando cosas como "no existe tal cosa como valores ágiles" taxativamente cuando precisamente los autores del manifiesto, que son en definitiva los que han definido que es y que no es agilismo, dicen explicitamente que el manifiesto es un conjunto de valores y principios.
Y yo también me decido a esto, desde la época en la que a los que hablábamos de cosas como TDD o scrum nos miraban raro y nos juntábamos cuatro gatos en las primeras reuniones de agile madrid para contarnos las penas.
#96 El "agilismo" no es una metodología concreta, en realidad el termino agil aparece en una reunión donde diversas personas con cierta relevancia dentro del sector y que proponían cada uno diferentes metodologías buscan que cosas tienen esas metodologías en común y redactan el famoso manifiesto agil que se compone concretamente de 4 valores y 12 principios.
Tipos específicos de proceso son scrum, extreme programing o incluso kanban. Pero el agilismo no prescribe ningún proceso especifico, se limita a exponer un conjunto de valores y practicas. Y esto no lo digo yo, lo dicen sus creadores, si no te gusta la definición se lo puedes comentar a jeff shuterland, kent beck, alistair cockburn etc,etc.
Por ejemplo, en palabras de Jeff Shuterland, el creador de scrum: "The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time.", articulo completo: msdn.microsoft.com/en-us/library/dd997578(v=vs.120).aspx
Un articulo de un medio generalista sobre "desarrollo de software agil" que se queda en la anécdota, no es estar a las 9:06 en punto o salir a las 6 lo que hace que esta empresa funcione, son los valores y los principios que esta empresa tendrá si son verdaderamente agiles, y esta forma de reunirse y organizarse será consecuencia de la aplicación de estos valores y principios. Vamos que nadie se piense que si pone una reunión a las 9:06 su empresa/equipo va a funcionar mejor así por arte de magia, será simplemente el enésimo caso de cargo cult (www.jamesshore.com/Blog/Cargo-Cult-Agile.html)
Y espero que el código que sale en la foto no sea un ejemplo de lo que hacen... un método que no cabe en la pantalla, duplicación de código evidente, dos elseif y uno que solo contiene un comentario... canela fina jeje.
#43 El master Dijkstra decia: "Program testing can be used to show the presence of bugs, but never to show their absence!". Personalmente soy defensor de cosas como TDD y es mi forma de trabajo, pero si algo falla en producción falla y hay que arreglarlo tengas los tests que tengas. La falta de competencia técnica es un problema igual que lo es la falta de competencia en la gestión y la definición de producto, y normalmente suelen ir juntas.
Hombre está bien que lo eliminen si eso sirve para que el Visual Studio arranque un poquito más rápido...
UML puede tener su valor en determinadas situaciones, para explicar algunas cuestiones de diseño y tener una visión compartida en el equipo, pero esto se puede hacer en una pizarra, en una hoja de papel o en cualquier herramienta sencilla. No veo la necesidad de tenerlo integrado en un IDE, así que por mi estupendo, los IDE's como VS lo que necesitan es hacer menos cosas y hacerlas mejor y más rápido no tropecientas funcionalidades que se usan raramente y sólo sirven para sobrecargar de funcionalidad el monstruo.
#103 Es una forma de catalogar un uso real que se hace de UML en la industria, y fowler lo que hace es simplemente reflejar esa realidad ponerle un nombre y ayudarnos a todos a entender las motivaciones de la gente que usa las cosas de una determinada forma. Y Fowler, creeme, sabe de lo que habla. Leete el articulo.
#90 Eso que llamas "diagramas y bolitas" es un uso del UML que fowler catalogaba como "UML as Sketch" (martinfowler.com/bliki/UmlMode.html como siempre, leer a a fowler obligatorio :P), dibujos informales que pueden ayudar sobre todo para compartir en un equipo una idea de diseño, a mucha gente le ayuda verlo visualmente y no esta mal tener un lenguaje común de modelado donde sepamos que es una flecha y que es una caja, aunque sin mucho formalismo porque entonces te pierdes en los detalles y precisamente eso juega en contra de tener una visión compartida de algo simple y rápida.
Lo que nunca ha funcionado muy bien es tratar de usar "UML as blueprint" o "UML as programming language", donde UML tiene un rol central en el desarrollo, en general las herramientas visuales de programación visual o mediante diagramas se han demostrado con los años bastante ineficientes y engorrosas y hoy en día poca gente se plantea su uso, los más viejunos podemos recordar como estas herramientas se supone que iban a ser la panacea a finales de los 90 principios de los 2000 y al final como tantas cosas en software la cosa quedo en agua de borrajas.
#70 En una metodología en las que las fases de testing y despliegue se colocan sólo al final del proyecto, eso es waterfall, los problemas tanto funcionales que se descubren en la fase de testing como de infraestructura y no funcionales que se descubren en la fase de despliegue llegan siempre al final del proyecto, aunque las cosas se hayan echo bien, cuando llegan esas fases el tiempo que se va a tardar en resolver esos problemas es totalmente indeterminado, como metodología es absurdo, es un proceso mal planteado. De echo si hablas de metodologías "clasicas" incluso RUP define su proceso como iterativo, nadie ni clásicos ni agilistas, hacen waterfall en realidad.
Tu hablaras de TU práctica del día a día o de la que hayas conocido, evidentemente si no cumples los principios agiles no estas haciendo agilismo así que no esperes otra cosa que alguien te venga "siempre con lo mismo de que no se aplican bien los principios ágiles" hasta que los apliques bien o dejes de decir que haces agilismo, una de dos. Yo llevo más de diez años aplicando metodologias agiles en mi día a día y ayudando a empresas a hacerlo, no hablo de sólo de "teoría" te hablo de cosas que en puesto en practica decenas de veces.
Yo creo que tenemos que empezar a cambiar la mentalidad y pensar al reves, en lugar de pensar "¿es posible hacer este trabajo en remoto?" yo me plantearía "¿que nos obliga a que este trabajo se tenga que hacer en una oficina?".
El trabajador se ahorra tiempo de desplazamientos y gana en calidad de vida y la empresa se ahorra en costes, todo el mundo sale ganando.
#21 Uno de los principios de XP, que se puede considerar la primera metodología ágil ampliamente conocida, es precisamente sustainable pace o ritmo sostenible vamos (www.extremeprogramming.org/rules/overtime.html). Si metes horas extra por sistema no estas siendo ágil, estas haciendo el tonto porque pocas cosas hacen más daño a un proyecto que quemar al equipo con horas extras.
Waterfall, que ni siquiera existe como metodología por cierto es más bien un error de interpretación de un paper, no es bueno ni para el trabajador ni para el producto, para el trabajador supone una etapa de falsa tranquilidad inicial seguido de un deadline al final que suele ser un absoluto desastre ahora si que horas extras a tutiplen y una carga de estrés brutal. Si vas entregando un proyecto en pequeñas iteraciones sostenibles el trabajador puede vivir con tranquilidad y hacer un buen producto, esto claro si se siguen los principios agiles, si nos limitamos a decir que hacemos scrum y lo único que hacemos es llenar las paredes de posit de colores y poner deadlines cada dos semanas pues entonces al carajo, lo que tenemos son mini-waterfalls de dos semanas.
Yo tengo 37 y desde los 20 trabajo desarrollando software. A los 50 espero seguir dedicando a lo mismo porque es lo me gusta hacer.
Del articulo hay algunas cosas un poco ridiculas, como pensar que la evolución de un programador es terminar siendo analista y luego jefe de proyecto, esto será así en algunos lugares donde existen estas jerarquías absurdas donde un programador termina gestionando un equipo o donde el gestor es el jefe de los programadores, ninguna de las dos cosas tiene sentido. La tendencia es que cada vez exista menos jerarquía, por supuesto según niveles de experiencia o capacidad se tendrán distintas responsabilidades dentro de un equipo, pero los equipos tienden a ser más planos y la figura del gestor de proyectos a desaparecer en favor de equipos autogestionados con contacto directo con los clientes/responsables de producto. En ese contexto ser "programador" no implica quedarse toda la vida en el escalón más bajo por no querer o no estar capacitado para asumir tareas de gestión, simplemente con los años vas ganando experiencia y asumes más responsabilidades técnicas en los proyectos.
Y leyendo las opiniones de otros profesionales en el articulo, me entristece ver que seguimos a vueltas con las tonterías del intrusismo y los "no-informáticos". Para mi los únicos intrusos en esta profesión son los malos desarrolladores, y de estos por desgracia tenemos para dar y regalar, con titulo y sin titulo.
Muy deacuerdo con todo lo que dice el articulo, es importante ponerse algunas "normas" para no volverse un ermitaño del todo, como por ejemplo no trabajar en pijama jeje o salir al tomar el cafe fuera o dar una vuelta de cuando en cuando. Por un lado se puede aprovechar mucho mejor el día si te marcas unos horarios y por otro lado corres el riesgo de volverte loco y no desconectar nunca, es cuestión de plantearse unos buenos hábitos.
Lo único en lo que no coincido es sobre el punto de "aprender de tus compañeros", trabajar en remoto no implica trabajar sólo, yo paso la mayoría del día haciendo pair programming en remoto, igual que lo haría si estuviera en la misma oficina en presencial. Un equipo remoto que use bien sus herramientas de comunicación puede estar mucho mejor coordinado y compartir muchas más cosas que un equipo presencial con gente que se pone los cascos para trabajar y se aísla del mundo.
De todas formas prefiero el trabajo en remoto combinandolo con días en presencial de cuando en cuando, pero bueno cada equipo es diferente y tiene que encontrar la forma en la que todos estén más cómodos, que al final es lo que te permite hacer un buen trabajo.
Pues depende, hay trabajos donde la relación entra las horas dedicadas y lo que se produce es directamente proporcional y muy evidente, y luego hay otros trabajos donde esa relación no es tan evidente e incluso un número de horas excesivo puede ir en contra de la productividad.
Por lo general, en aquellos trabajos donde se necesite cierto grado de creatividad y frescura mental para resolver problemas más o menos complejos la relación entre horas y productividad no es nada evidente, depende mucho de cada persona, lo que realmente aumentaría la productividad en estos casos es dejar la libertad a cada persona de que decida cuantas horas dedicar, cuando dedicar esas horas, desde donde prefiere trabajar etc,etc. Esa libertad en la forma que organizas tu trabajo que te permita trabajar con comodidad es lo que te va a permitir tener la mente fresca y enfocada cuando estes haciendo tu trabajo, y si un tio es productivo para la empresa me da igual que trabaje 6 horas, 4 o 10 o que trabaje por las mañanas, por las tardes o en su casa de madrugada.
Aunque parezca lo normal, lo que es tremendamente extraño y anti-productivo es obligar a la gran mayoría de trabajadores a hacer las mismas horas, los mismos días de la semana, a tener que desplazarse a diario, aunque sean personas con formas de trabajar totalmente diferentes, con necesidades totalmente diferentes y se dediquen a actividades totalmente diferentes.
La historia es difícil de creer, no sólo se debe sino que es imprescindible en cualquier sitio serio automatizar la labor de testing, lo que no es creible es que la automatización que construyo le sirva durante 6 años sin cambios, el software que estaba probando tendría nuevas features en esos 6 años digo yo y tendría que ir actualizando esas pruebas automáticas para que probasen esas nuevas features, en caso contrario una de dos esa empresa lleva 6 años sin añadir nada nuevo a su software, parece poco creíble, o el tio realmente no estaba haciendo ni el huevo.
Me preocupa que la moraleja parezca ser "no automatices que te quedas sin trabajo", cuando debería ser justo lo contrario, si automatizas las partes mecánicas de tu trabajo podrás dedicarte ha hacer cosas mucho más satisfactorias que pasar una bateria de pruebas manualmente todos los días, cosas como seguir automatizando pruebas y mejorar la detección y los informes de error, automatizar otro tipo de pruebas (pruebas de carga, pruebas de rendimiento), ayudar al equipo de desarrollo para que los fallos no lleguen a QA (por ejemplo enseñandoles a crear ellos sus propias pruebas automáticas). Si haces estas cosas no sólo no perderas tu trabajo sino que te convertiras en alguien con unos concimientos tremendamente valiosos tanto para esa compañia como para muchas otras, a un experto en automatización de pruebas no le falta el trabajo y además tiene un trabajo interesante. Un tio de QA que no automatice y se dedique a apretar botones siguiendo un plan de pruebas tiene un trabajo monotono y aburrido a más no poder y ningún conocimiento especialmente valioso.
#84 alfredo_casado 