Se dice que son necesarias 10.000 horas de trabajo de programación para alcanzar el nivel de experto, pero una vez llegado a él, ¿cuál es la evolución? ¿Se mantiene? ¿Continúa mejorando? ¿Retrocede?

Aunque hay diversas opiniones, posiblemente la más habitual considera que la edad desgasta la capacidad para adoptar y absorber nuevos conocimientos, por lo que al avanzar va transvasando a puestos comerciales, de gestión, de asesoría, o incluso a otras actividades. 

Como la demanda de software continúa creciendo, y en el medio plazo no es probable un cambio de tendencia, se empieza a cuestionar si la preferencia de candidatos jóvenes, o la percepción del "demasiado mayor" tiene sentido o puede ser un comportamiento inducido por una falsa lógica.

Patrick Morrison y Emerson Murphy-Hill del departamento de Ingeniería del Software de la Universidad de Carolina del Norte, han realizado un estudio pionero en esta línea, basándose en el análisis de los datos de la comunidad de programadores de stackoverflow.com (edad, reputación en la comunidad, tecnologías tratadas).

El objetivo de su primer estudio en esta línea es identificar si se aprecia algún tipo de correlación entre edad y nivel de programación, antes de profundizar con posibles correlaciones entre la "inteligencia fluida" o capacidad para identificar relaciones complejas y sus inferencias, y la "inteligencia cristalizada" que refleja la amplitud de conocimiento, comprensión juicio y sabiduría adquirida por la experiencia".

La conclusión a la que llegan los autores es que sí que existe una correlación entre la edad y la reputación de los programadores en stackoverflow.com, que parece indicar que se puede mantener un nivel de programación alto en los 50 y los 60, y que los usuarios más veteranos de stackoverflow se encuentran al día y adquieren sin problemas los nuevos conocimientos en las tecnologías que ha examinado este estudio.

Este es el documento del estudio: Is Programming Knowledge Related to Age? que presentarán los autores el 18 de mayo en el eventop "10th Working Conference on Mining Software Repositories" en San Francisco.

"Un problema de los equipos de programación con importante impacto económico es la alta rotación de personal. La relación entre insatisfacción y rotación es una evidencia contrastada. El estudio (Comparative Analysis of Job Satisfaction in Agile and Non-Agile Software Development Teams) investiga si existe una relación entre la satisfacción laboral y el método de desarrollo empleado, y encuentra una correlación positiva moderada entre el nivel de satisfacción y el uso de metodologías ágiles..." (1)

 "El análisis comparativo entre equipos ágiles y la media general de profesionales TIC, ha revelado tasas significativamente más altas de satisfacción en los miembros de equipos ágiles. Además no sólo en los trabajadores, sino también en los administradores se da mayor satisfacción con sus empleos. Este es un claro indicador de que los métodos ágiles no son un movimiento orientado sólo a los programadores".

El informe completo y todas tablas comparativas del estudio en:

(1) Melnik, G., & Marurer, F. (2006). Comparative Analysis of Job Satisfaction in Agile and Non-agile Software Development Teams. Extreme Programming and Agile Processes in Sotware Engineering, 32-42.

]]> juan.palacio@gmail.com (Juan Palacio) Blog Thu, 02 May 2013 17:47:20 +0000 http://navegapolis.com/index.php/90-motivar-para-programar http://navegapolis.com/index.php/90-motivar-para-programar

En otras profesiones no sé, pero si se trata de programadores, de gente apasionada por la tecnología y por la programación de nuevas soluciones, no se preocupe por motivarles. Son profesionales motivados por su trabajo mucho más de lo que usted lo está por el suyo.

La cuestión no es motivar, sino no desmotivar con "programas de motivación", planes de desempeño, control de horas de trabajo, recompensas y castigos, etc.
Quieren programar, son gente inteligente y los modelos de motivación de manual de recursos humanos, les resultan pueriles y denigrantes y les quitan las ganas que traían con ellos cuando llegaron a su empresa el primer día.

Estamos hablando de programadores, "programadores": personas a las que les gusta su profesión. Son un porcentaje escaso. Gente que cuando deja el equipo de la oficina, continúa, investigando y "jugando", que disfruta con retos intelectuales y a la que gusta estar en continuamente descubriendo y aprendiendo.

Si los programadores de su empresa no son de este tipo, si desde que dejan la oficina hasta que vuelven a la mañana o el lunes siguiente, no echan de menos un teclado... seguramente el consejo de este post no es bueno para usted, y es posible que sí que necesite las prácticas de motivación del manual de RR.HH. También es posible que no consiga nunca productos brillantes.

]]> juan.palacio@gmail.com (Juan Palacio) Blog Sun, 13 Jan 2013 20:56:16 +0000 http://navegapolis.com/index.php/87-de-cmmi-a-scrum http://navegapolis.com/index.php/87-de-cmmi-a-scrum

"Tras algunos momentos difíciles, paramos la implantación de CMMI y retomamos técnicas ágiles, más colaborativas. Aquí describimos esta experiencia en la implantación de un marco Scrum distribuido y en la creación de una cultura kaizen".

"... La opinión de diferentes expertos y la experiencia en empresas veteranas resaltaban la importancia de establecer procesos compartidos que pudieran ser empleados por todos. Expertos en consultoría nos aconsejaron la implantación de CMMI en ambas ciudades. Se realizó un estudio inicial de viabilidad para lanzar la nueva empresa en Bangladesh e implementar CMMI con la ayuda de una consultora externa. Aunque veíamos muchos desafíos, parecía muy prometedor."

"... Encontramos un partner competente con el que firmamos un contrato por el que nos ayudaría a alcanzar un nivel 3 de CMMI certificado en año y medio ... Uno de los directores más experimentados de la organización se trasladó a Bangladesh durante dos años como director general."

"Todos los nuevos empleados de Bangladesh vinieron durante un mes a Dinamarca, en otoño de 2005 para conocer y trabajar junto con el equipo local, comprender bien el dominio del negocio y establecer un entendimiento cultural entre las dos empresas ... En ese momento no éramos conscientes del impacto de poner el objetivo en la certificación para integrar las dos ciudades. En lugar de que nuestro objetivo fuera crear valor para el negocio y ofrececer soluciones eficientes a nuestros clientes, teníamos por meta estratégica establecer un proceso marco y cumplir una serie de prácticas clave para las áreas de proceso de CMMI ... "]]> juan.palacio@gmail.com (Juan Palacio) Blog Sun, 09 Dec 2012 22:35:19 +0000 http://navegapolis.com/index.php/85-videos-2012-cohaa http://navegapolis.com/index.php/85-videos-2012-cohaa

Para asistir en diferido a las sesiones sobre agilidad de la conferencia  "The Path to Agility 2012" que se celebró en mayo de este año organizada por The Central Ohio Agile Association: "Craftsmanship", "Clean Architecture and Design", "Reality in Software Development", "Scrum and Continuous Improvement", "Driving Real Business Value Thrugh Agile", etc.