Empezamos nuestra vida profesional programando. A muchos nos encanta. Va más allá de una obligación o un mal menor y temporal en un camino mezquino. Es una pasión. Disfrutamos construyendo buen software y cúanto mejor lo hacemos, más nos gusta. Por eso nos cuesta abandonar la rama técnica de nuestro sector. Aunque es una rama corta, torcida y con un techo salarial injusto.
Hace unos dias
os contaba que
Kent Beck ofrecía sus servicios durante 2 horas de forma remota a través de ebay. Me pareció una buena prueba para saber dónde está este techo ahora. Para saber cúanto vale un experto en programación y animarme a no cambiar de rama.
Finalmente la
puja se cerró en 405 dolares americanos. No llega a 300 euros al cambio actual. Más o menos lo que cualquier consultora cobra por una jornada de un perfil técnico medio aquí en España. No sé a vosotros, pero a mi me parece poco. Me cuesta creer que haya faltado repercusión o que la cuestión del remoto haya sido un impedimento. Sinceramente me esperaba más dinero. Sobretodo teniendo en cuenta que por casi cualquier curso o seminario con un profesor anónimo ya se está facturando eso o incluso más. Y no es lo mismo un formador que un experto.
La conclusión es tan clara como desmotivadora.
Un experto en programación vale poco en comparación con otros expertos.Por qué
Por un lado es un
problema de actitud. Nos quejamos mucho en nuestros circulos internos pero reivindicamos poco o nada en comparación con otros colectivos de trabajadores.
Pero principalmente pienso que es un problema de
no saber reconocer la calidad ni importancia del trabajo de un programador. Me explico. Reconocer la calidad del trabajo de un diseñador gráfico es sencillo (gustos aparte). Reconocer la calidad del trabajo de un experto en usabilidad es sencillo. Reconocer la calidad del trabajo de un tester es factible con métricas sobre el número de bugs detectados. Reconocer la calidad del trabajo de un formador también es sencillo. Calcular la comisión del trabajo de un comercial se hace todos los dias.
Sin embargo, reconocer la calidad del trabajo de un programador no es fácil para alguien que no sea también programador. Características como la eficacia, estabilidad y escalabilidad del código de una aplicación no son fácilmente medibles a primera vista. Ni siquiera para un programador. Ya sea sobre el código o sobre la aplicación funcionando. ¿Es culpa del análisis, del código propio de la aplicación, de alguna librería externa, del servidor, del proxy, de la base de datos,...?
Mucho más dificil es responsabilizar de cualquier mérito o demérito a un programador concreto dentro de todo un equipo de desarrollo. ¿Trazabiliqué? Todos somos de excusa rápida para nuestros fallos y muy poco comprensivos para los de los demás.
La complejidad se multiplica para el caso de aplicaciones enterprise donde existen numerosas fuentes de datos, cuya integridad y fiabilidad no dependen directamente del programador pero si pueden afectar a la aparente calidad de su trabajo. ¿A quién no le han abierto una incidencia que realmente era por un bug en un servicio externo, por inconsistencia de datos o simplemente porque estaba caido algún sistema externo?
Al final el cliente termina por aceptar y convivir con que sus aplicaciones fallan y necesitan de grandes contratos en mantenimiento correctivo y funcional. Los comerciales hacen su trabajo. La empresa gana dinero. Y nosotros terminamos parcheando dinosaurios. Todo puede seguir como estaba.
Aún así, nosotros, los que programamos, sabemos que un buen programador no es que valga x2 o x3. Vale mucho más. Mientras que un mal programador ya no es que sume poco, es que llega a restar. Lo sabemos porque lo vivimos a diario, pero comunicar esta lección a otros niveles no es fácil.
Un futuro mejor pasa irremediablemente por
medir la calidad de un proyecto, y por tanto
medir la calidad de sus programadores. Con números delante, todo el mundo es capaz de medir y comparar. Para ello se puede (1) medir la calidad del código mediante métricas de análisis estático, (2) medir la cobertura de tests unitarios del código y (3) definir tests de aceptación funcionales y de esfuerzo sobre la aplicación. Con lo primero medimos mantenibilidad, con lo segundo fiabilidad y con lo tercero eficacia, estabilidad y escalabilidad.