Cuanto vale un experto en programacion (ii)

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.

20 comentarios :: Cuanto vale un experto en programacion (ii)

  1. Podrías publicar un artículo en javahispano sobre todo sobre la parte final :)

  2. Muy interesante comentario. A medida que las tareas son más complejas se valoran menos. (Excepto cuando tu negocio depende de ello y no te funciona nada).

    Yo alguna vez he visto en los clientes la siguiente actitud (cuando no son tecnicos):
    - Comercial. (El amigo - se le puede pedir de todo que luego el hablará con los técnicos - muy bién valorado).
    - Diseñador gráfico. (Un artista - bien valorado).
    - Programador. (Esa persona que hace cosas raras y habla raro cuando le pido cosas y no me las quiere hacer - poco valorado)

    Pero en otros campos ocurre parecido. (Telefonía, bancos, etc). Muchas veces le damos más importancia a como nos trata el comercial o como lo venden en la publicidad que como es el producto.

    Conclusión, debes saber de todo de esta empresa y no solamente conocer sus comerciales, también sus productos y técnicos.

    Saludos,
    Jorge Rubira

  3. De nuevo tengo que aconsejarte Sonar: lo llevamos usando desde el inicio del proyecto, y aunque Hudson también da esas métricas, las ventajas de usar Sonar son mayores:

    - Se sigue la evolución desde el inicio del proyecto (no de los últimos x builds)

    - La información se muestra de forma MUY intuitiva (desde nubes de tags hasta gráficos de complejidad por módulo,clase y método)

    - Sólo se ejecuta una vez al día. Nadie mira la calidad de su código después de cada uno de sus commits, pero me estoy encontrando que los programadores lo miran al día siguiente mientras se toman el cafecito de la mañana (más interesante que el Marca! ;-))

    - Psicológicamente es brutal: la gente se PICA con lo que dice sonar de sus clases, y el que hace dos meses no sabía lo que era complejidad ciclomática, ahora evita los mega-métodos ;-). Además, tener una aplicación web que SOLO mide la calidad, demuestra al entorno la importancia que se le da en el equipo a hacer bien las cosas.

    Si tu proyecto usa maven y hudson es "semi-gratis". De verdad, merece la pena, al principio pensaba que sólo externamente al grupo, ahora me doy cuenta que también internamente.

    Salu2

  4. Yo he llegado a usar ésta:

    http://www.alphaworks.ibm.com/tech/sa4j

    Es muy sencilla de usar y te da un índice único de calidad. El problema es que está anticuada y lo mismo no reconoce código Java moderno y respecto al índice de calidad pues es muy discutible.

  5. Vamos con un poquito de matemáticas. Todo según tú articulo.

    Vende servicio 2h por 300€.
    300/2=150.
    150 * 8h = 1200€ al día... ¡más que cristiano ronaldo! ¿Y TE QUEJAS? No sé, pero yo no llego a los 6€/h.

  6. Yo es que lo de medir atributos siempre me deja... es como medir la calidad de un futbolista por sus medidas biométricas... te pueden dar indicaciónes claras negativas, pero las positivas es difícil.

    Y en cuanto a los tests... el mismo código, exáctamente el mismo, tendría una valoración diferente si en el proyecto hay muchos tests o si tiene pocos... lo cual dice claramente que el número de tests no dice nada directamente aplicable al código.

    Ojo, no digo que no sirvan para nada, pero creo que tampoco hay que dejarse llevar por el entusiasmo y confundir los medios con los fines.

    S!

  7. Lo importante no es el número de tests sino la cobertura de los mismos.

  8. crap4j tiene en cuenta la cobertura para dar una medida de calidad de l código.

    Estas herramientas están muy bien, yo las uso a diario (checkstyle, findbugs, cobertura...) pero no van a servir para que nuestro trabajo se respete más o menos, lo único que va a contar al final son los resultados, y esto es lo que tenemos que demostrar: "cuando mejora la calidad del desarrollo los resultados son mejores", y esto es lo dificil realmente...

    En mi opinión el problema radica en la dificultad de medir el dinero que se ahorra por los problemas que no se producen. Un buen programador hara código con muy bajo porcentaje de errores y mantenible, es decir, un buen programador esta ahorrando costos para el futuro tanto en mantenimiento como cuando se tengan que añadir nuevas funcionalidades, pero es muy dificil cuantificar este ahorro porque los problemas nunca se han producido...

    Esta es en mi opinión la principal causa por la que no se valora al buen programador como se debería, proque lo que ese programador te esta ahorrando no aparece las estadisticas de los que luego pagan.

  9. Lo primero muchas gracias a todos por vuestros comentarios.

    Es evidente que medir la calidad de nuestro trabajo no es fácil ni inmediato.
    El análisis estático de código no lo cubre todo. Tu código puede ser mantenible (bajo acoplamiento, métodos pequeños, comentado, etc.) pero eso no quiere decir que cumpla los requisitos del cliente, ni que sea estable, ni que sea escalable. Además el resultado del análisis tiene un fuerte componente subjetivo. Aún así, es mejor que nada.

    Las pruebas (IMHO) sí vienen a medir las características que solicita el cliente para sus aplicaciones (eficacia, estabilidad y escalabilidad). Pero claro, deben ser unas pruebas funcionales y de stress completas. Y eso tiene un coste. Las pruebas unitarias son un instrumento más propio del programador para probar su código sin necesidad de estar desplegando la aplicación.

    Las empresas de software deberían tener sus procesos de pruebas y QA para las aplicaciones que desarrollan.
    Pero aún más importante es que lo tengan las empresas cliente para conocer sus aplicaciones y comparar a sus proveedores. Por fin tendrian datos y pruebas para saber por qué los proyectos que hace la empresa X dan menos problemas que los que hace la empresa Y!

    En este último sentido sí estoy preparando una presentación sobre un sistema para medir la calidad de proyectos (@jm: aunque no sé si lo publicaré en jh, al menos con el nuevo sistema de remuneración es imposible) y SONAR es su componente principal (@Ibon: os tuve mucho en cuenta a Martín y a tí, pero para un equipo pequeño como el mio (4-5) y todos los proyectos con ANT, nos valía con los plugins de Hudson, pero SONAR es una herramienta impresionante que gana a todos cuando quieres medir la calidad a un nivel mayor de un único equipo o proyecto).

  10. Me alegro de reencontrarme con algunos por estos lares ;-)
    Aunque disiento, porque parece que ya empieza a haber algún estudio estadístico sobre el tema. Personalmente me encantó esta charla: http://www.infoq.com/presentations/measure-for-measure

    y viene a decir algo que estoy comprobando día a día en mi proyecto actual: a mayor complejidad ciclomática y menor cobertura de tests, la probabilidad de que aparezca un bug en determinado código tiende a uno.

    Como toda buena estadística, una probabilidad del 99% NO quiere decir que el bug exista o que aparezca, pero a la hora de entregar el proyecto, uno como que se queda más tranquilo.

    De la misma forma, he encontrado en el libro "Clean Code" un montón de medidas cualitativas que comprobadas en el día a día, me demuestran que es el "buen" código. Y alguna de ellas era contraria a lo que yo pensaba que era bueno ;-)

    Creo que estamos viviendo un buen momento: después de tantos y tantos fracasos, empezamos a vislumbrar que funciona y que no funciona a la hora de tirar líneas de código. Como bien dice Daniel, las indicaciones positivas son difíciles, pero chicos, que bien detectan los "WTF!" ;-)

    Salu2

  11. @jcesarperez
    En nuestro caso somos 11 y un único proyecto, es verdad, pero quería recalcar el efecto PSICOLÓGICO en los programadores (aparte del cuantitativo de métricas): empiezan con reticencia, incluso con sonrisillas de sabelotodos ;-), pero cuando tienen un árbitro "objetivo" del nivel de "ñapismo" del código del que antes estaban tan orgullosos, ceden y aprenden buenas prácticas. Y cuando ven que se mide TODOS los días, no hay día que no se preocupen de que sus commits no sean los causantes de que la curva de sonar decrezca.

    Os lo prometo, está superando mis expectativas, y estamos logrando más de lo que pensaba: de gente que no había usado junit en su vida (viva las empresas de software de españa!) a tener una cobertura media de teses unitarios de código del 15% en dos meses, sin contar las decenas de teses de integración; de tener unos beta testers a mano y papel, a pedirnos que les enseñemos a usar selenium; de código infumable, a leer TODOS los días "Effective Java" y "Clean Code" antes de cagarla.

    Y creo que haber puesto Sonar en un lugar tan eminente, privilegiado e importante en nuestra metodología, ha ayudado mucho: aunque me importen una mierda los números exactos que nos de cada día, lo alucinante es que TODAS las tendencias son positivas, y hemos empezado por el caso de uso MÁS complejo de nuestra herramienta!.

    Pues nada, simplemente deciros que creo que se puede hacer... me ha costado muchas horas, paciencia y mano derecha, pero los resultados me parece que van a ser muy buenos.

    Salu2

    PD: efectivamente, es una putada que Sonar sólo tire con ant... pero tal vez sea una señal para pasarse a maven ;-)

  12. Lo importante no es el número de tests sino la cobertura de los mismos.
    "Pal" caso, lo mismo :). La idea es que el mismo codigo, con un 100% de cobertura o con un 0% es igual de bueno. El código.
    A mi personalmente me gusta el FindBugs para encontrar los WTF! que dice Ibon y las pruebas funcionales y tests de regresion que correspondan a los requerimientos y permitan no tener que retestear todo cada vez desde cero. Si además de gustarme me dejaran usarlos, ya sería la caña de España!! :D

    En cuanto a valoración de la profesión... pues no es nada nuevo bajo el sol. Desde fuera, igual valoramos nosotros como clientes finales a los que montan/diseñan las piezas internas de los coches, interior de las casas etc. Si no se rompe, ni nos acordamos que existen.
    Internamente en las empresas, como en muchas cosas uno "sólo se acuerda de Santa Barbara cuando truena".
    Yo para no darle vueltas empiezo por el amor propio, es decir lo intento hacer bien por satisfacción personal, y luego intento disfrutar los pequeños detalles indirectos, como que en caso de problemas acudan a tí por que eres de fiar, jejeje. En mi caso, como funcionario, económicamente no me lo valorarán nunca. Eso si, cuando hago de consultor independiente me lo cobro y al que le parezca caro, a mi me parece bien, que busque otro ;).

  13. @Ibon: estoy contigo 100%. Ni los mejores discursos habrían hecho tanto bien como las estadisticas diarias de análisis de código. No sólo ha mejorado el código de cada programador, también su actitud, ganas de ser mejor y el sentimiento de equipo.

    @Daniel: Tu mismo has dado en la tecla. El código podrá ser igual de bueno, pero la cobertura te garantiza un % de regresión y eso no tiene precio. Te recomiendo que prediques con el ejemplo a la hora de usar testing. Antes o después te copiarán y reconocerán su valor.

    Leí una vez a alguién que decía que si no podías convencer a alguien del valor del testing, simplemente le obligaras a usarlo y ya se daría cuenta él sólo. En tu caso parece que no estás en esa posición, pero tampoco creo que te prohiban subir tests a CVS.

    Respecto a lo de Santa Barbara, tienes razón en parte, pero debes pensar que desgraciadamente una aplicación falla mucho más que un coche. Como tu bien dices al final se aprende quién hace aplicaciones más estables. El objetivo (IMHO) es acelerar ese aprendizaje o predecir mediante números (métricas y testing).

  14. El código podrá ser igual de bueno, pero la cobertura te garantiza un % de regresión y eso no tiene precio.
    Eso mismo, no es tanto lo que dice sobre el código como el valor que te dan los tests. Por eso el objetivo es hacer tests que te den valor, no "cubrir al máximo el código" en si mismo, ya que no mejora o empeora el propio código.

    En cuanto a predicar con el ejemplo... claro, y luego le explico amablemente a mi jefe que en vez de desarrollar "mas funcionalidad", para la que ya nos falta tiempo, hago esto "extra"... de momento mejor me guardo la munición para cuando tenga una batalla que pueda ganar :).

  15. Estoy contigo. Siempre hay que tener en mente la regla del 80-20. Entonces un 60% de cobertura en realidad no dice mucho, porque no sabes la importancia de ese código.
    Lo que si te da es que antes de modificar unas clases, puedes mirar la cobertura que tienen esas clases concretas y así saber el grado de fiabilidad que tendrá la regresión.

    Yo es que los tests unitarios lo veo como parte del desarrollo y no como una fase de pruebas independiente. Intenta verlo del siguiente modo: tu pruebas tu código, pero seguramente ahora lo que harás será desplegar la aplicación y hacer las pruebas sobre la aplicación de forma manual. Con tests unitarios lo pruebas sin perder el tiempo en despliegues y con las ventajas que te ofrece la automatización.

  16. No puedo estar más de acuerdo contigo.

    http://garciagonzalezdavid.wordpress.com/2009/04/18/7-razones-por-las-que-considero-que-un-buen-programador-es-mas-eficiente-que-10-no-tan-buenos/

  17. Intenta verlo del siguiente modo: tu pruebas tu código, pero seguramente ahora lo que harás será desplegar la aplicación y hacer las pruebas sobre la aplicación de forma manual.
    Suponiendo que pudiera hacer tests, el despliegue y los tests de integración se harían de forma automática, sobre esto tenía una charla propuesta la conferencia de Sun pero no fue aceptada. Aun así, entiendo el punto de vista de los tests unitarios pero en mi caso, no les veo tanta ganancia por que a lo que yo me dedico, tendría que hacer tanto "mock" que en realidad casi estaría probando lo fiable que son los mocks. Y para eso...

  18. Dejando a un lado las métricas del código en mi opinión el problema, como comentas, es que nadie sabe la diferencia entre un programador bueno y uno malo.

    Sin embargo el resolverlo no está en que los demás se den cuenta si no en hacer que se den cuenta y bien sabido es que los programadores no son precisamente el ejemplo de comunicadores.

  19. @javi santana: en mi opinión el problema, como comentas, es que nadie sabe la diferencia entre un programador bueno y uno malo.

    Bueno te podría dar unas pocas ideas desde mi opinión personal:

    Un buen programador

    * Considera que la programación orientada a objetos es uno de las mejores inventos de la Historia del software.

    * No repite código.

    * Busca analogías entre partes del código similares e intenta generalizar en lo posible.

    * Le encanta la simetría.

    * Le encantan las jerarquías (de código).

    * No atribuye demasiadas responsabilidades a una parte del código, cada parte es un servicio a otros.

    * Le gusta particionar, divide para vencer, divide para controlar mejor.

    * Es muy ordenado.

    * Es muy cuidadoso.

    * Es muy sistemático y coherente (aplica las mismas reglas, el mismo estilo).

    * No se fía de sí mismo, siempre son posibles los errores, testea pensando no sólo en funcionalidad sino también en su código.

    * La gestión de la complejidad no es un problema, el problema es la escasez del tiempo necesario para gestionarla, el problema son las prisas.

    * Pone las herramientas y las librerías en su justo lugar, sabe que ninguna herramienta puede substituir un buen trabajo, desconfía de las herramientas/librerías que dejan poco espacio al programador.

    * Considera el compilador uno de sus mejores amigos.

    * Desmitifica el lenguaje concreto, valora más la riqueza y la calidad del ecosistema que lo rodea.

    * No se le caen los anillos al admitir que su código no está preparado para asumir nuevas características y siempre está abierto a refactorizar cuando sea necesario. Detesta la chapuza cuando sabe que con algo más de trabajo el resultado sería mucho mejor.

    * Acepta con resignación que le consideren como un peon y no como una de las "piezas" más críticas y valiosas de cualquier empresa moderna.

    * Acepta con resignación que su trabajo (código, conocimiento, información) se valore a precio de saldo porque no tiene una manufactura, una fábrica detrás.

    * Acepta con resignación que lo mejor y más difícil de su trabajo, la gestión de la complejidad y el modelado en software del conocimiento humano, no tiene colorines y nadie le dirá "qué bonito".

    Etc, etc.

  20. @jmarranz tus puntos que empiezan con "Acepta con resignación que ..." no considero que estén dentro de las características de un programador.

    Un buen programador no se resigna, hace valer lo que hace y sabe hacer entender las complejidades de su trabajo.

Publicar un comentario