miércoles, 16 de octubre de 2013

Muchos caciques y pocos desarrolladores

Hace poco alguien me decía que había evolucionado bastante, que ya no desarrollaba y que dirige proyectos, que es todo un PMP. Casi me pega cuando le mencioné que yo siempre voy a ser un desarrollador, aunque lamentablemente cada vez lo hago menos. 

No me creía cuando le conté que cuando trabajé en unos proyectos en Brasil, el que más ganaba era el tester. Varios se han reído de esa anécdota, pues de inmediato me recuerdan que ese "recurso" debe ser un practicante o un bachiller ávido de conocimiento que ejecute checklists. Falso, el tester no solo hace pruebas, afina y recomienda refactorizaciones, evalúa el comportamiento en ejecución a través de telemetrías, en general tiene cicatrices de guerra, no come cuentos.


En otros escenarios me he enfrentado a discursos acerca del recurso, de fábricas de software, de métricas sofisticadas, de planes tipo bola de cristal, de látigo, como si los desarrolladores de software fueran unos chimpancés que se pueden llevar a alta mar para reducir tributos para que entreguen piezas de software similares a chaquetas o camisas. Que hacemos, el software es arte, lo demás son enfoques comerciales que buscan demostrar teorías de modelos de madurez o medir cuantas veces un "recurso" entra al baño para ser más productivo o contabilizar las líneas de código generadas.

En otros escenarios se muestra a super expertos que se muestran así por certificaciones alcanzadas, expertos de un año de experiencia y 6 meses de manejo de una herramienta. ¿Qué pasará si cambian la herramienta? ¿Si cambian las tácticas, las estrategias, los patrones a aplicar? ¿Será que es mejor tener criterio que un discurso acartonado y poco original? Bien dice el antipatrón de dependencia del vendedor que si su arquitectura son herramientas implicará que no tienes arquitectura.

Otras cosas del hoy, bueno y del ayer es el fastidio a ensuciarse las manos con código miserable. Se buscan más niveles de abstracción olvidándose de niveles subyacentes. Por ejemplo: uso JSF según san X vendedor como MVC, uso como ORM  a hibernate, etc. ¿Qué pasa si ocurre un error en estas APIS? ¿Cómo lo resolvemos? ¿Cómo afinamos las consultas?  ¿Cómo evitamos introspecciones innecesarias? ..... otro ejemplo es el uso de flujitos, dibujitos con herramientas que generan código; ¿y si fallan, y si el desempeño no es el esperado?

Hace unos meses un desarrollador tuvo un problema elaborando un servicio Web (mal llamado servicio). La afirmación del personaje era, "no funciona", sin entrar en detalles. El problema consistía en que no seguía un estándar simple de JavaBeans acerca de gets y sets para un bean, ¿Qué pasó? Simple, nos volvimos herramienta dependientes, framework dependientes y nos olvidamos de los fundamentos.

Creemos por ejemplo que un ESB es una herramienta o que un servicio es un servicio Web; simple, los fabricantes necesitan vender y ese es un discurso fácil de mostrar y de aprender por figuras comerciales. Por ejemplo, el ESB es un concepto, una estrategia,  una capa de integración, una guía de arquitectura compuesta de patrones de integración siguiendo un manejo stateless con gestión de recursos orientados a la conectividad, que puede ser implementado a conveniencia y a la medida, no es la super herramienta que centraliza todo el procesamiento de transformaciones o adaptaciones. 

Bueno, y ¿los arquitectos qué? En mi opinión son necesarios. Éstos deben proporcionar decisiones de arquitectura teniendo como base pruebas de concepto PoC, decisiones de diseño de alto nivel HLD que impliquen su desarrollo así como el cumplimiento de restricciones y de los principales aspectos no funcionales. Sin embargo, no creo en arquitecturas de marfil o  BDUF, pues muchas decisiones de diseño detallado se determinan en  el día a día, en el tablero no en modelos que desencadenen generadores de código. Es necesario un dueño de la arquitectura, un Architect Owner.

Otro punto clave es que conozco muchos casos de empresas de ciudad gótica en donde a las personas de negocio les molesta trabajar con personas de áreas de tecnología. Lo anterior porque ven que no les ofrecen implementaciones que realmente produzcan valor para el negocio, prácticas, sencillas, en tiempos cortos y que den solución a su problemática.

En conclusión, nos preocupamos por el cuidado de la caja, del tiempo, del presupuesto y del alcance, pero no en la generación de valor hacia el cliente quien es finalmente el más interesado en el software, si este le proporciona beneficios. En resumen, es necesario buenos desarrolladores con amplia experiencia, con criterio, que en  muchos casos son conocidos como arquitectos de aplicaciones.

Creo que en países hispano parlantes todos quieren ser abogados, gerentes de proyectos, médicos, pero pocos quieren ser maestros en una actividad específica. De igual manera pasa con los desarrolladores, pues todos quieren ser directores de proyectos o arquitectos en pocos meses.

Espero no herir susceptibilidades ni establecer opiniones fanáticas, es una opinión muy personal: mucho cacique y poco desarrollador.

26 comentarios:

  1. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  2. Primero, muy bien por el blog, deberías darlo a conocer un poco más, segundo y ya tocando el tema puntual, el punto de vista es totalmente válido, y estoy totalmente de acuerdo, solo que el origen de esta situación está basado en lo que el mercado ofrece, y lastimosamente pocos desarrolladores son remunerados de igual manera como lo es un gerente de proyecto, abogado, etc, pero eso ya es otro tema a tratar. Felicitaciones Garbriel

    ResponderEliminar
    Respuestas
    1. Hola Victor, gracias por tus comentarios. Creo que la remuneración debe estar relacionada proporcionalmente por el valor que generas, pero es cierto que la realidad es esa, así que ayudemos para que se produzca el cambio.

      Eliminar
  3. Compa.. esto es material de estudio para mis estudisntes de gerencia de proyectos...que gran post...

    insisto hay que escribir..dejar evidencia y cambiar nosotros.. cambiar el mundo

    gracias por este aporte

    ResponderEliminar
    Respuestas
    1. Gracias a ti por tus comentarios. Espero no desanimar a tus estudiantes de gerencia de proyectos.....jajajajajaa

      Eliminar
  4. Gracias por herir susceptibilidades...es de la única manera que reflexionamos

    ResponderEliminar
    Respuestas
    1. Creo que debemos opinar y reflexionar sobre convicciones, ser sinceros y evitar fanatismos.

      Eliminar
  5. TODA LA RAZON para mandar primero se debe aprender a obedecer, para ser un buen maestro se debe ser un gran obrero, nunca debemos olvidar que antes de aprender a correr aprendimos a caminar y sobretodo que jamas debemos dejar de ser desarrolladores pues porque entonces pa que estudiamos.

    ResponderEliminar
  6. Excelente post... se ha perdido la esencia..

    ResponderEliminar
  7. Lo leí un par de veces, más allá de decir que es un buen post, es un tema de estudia que nos dice la realidad de las cosas
    Podría tambien comentarte que es un tema generalizado, y no solo eso, creeme que he conocido muchachos que, luego de estudiar un lenguage tres meses, consideran es suficiente para hacer programas, esto ha concluido, al menos en mi país, que hacer un programa de software sea muy devaluado, es más los profesionales han devaluado mucho su trabajo por estos escritores de código ( solo saben usar la herramienta ), quienes ofertan su trabajo a muy bajos salarios, malogrando el trabajo de verdaderos programadores.
    También se enuentra frases como "¿Testing? no creo que sea necesario" o la siempre muy concida "¿análisis? eso esta para los que no saben programar".
    Para terminar, tengo el mismo deseo que tu, poder programar hasta cuando pueda hacerlo de manera correcta, pues es lo que más me apasiona ( hasta como pasatiempo )

    ResponderEliminar
    Respuestas
    1. Hola Eduardo, creo que es fundamental diferenciar un ingeniero de software (desarrollador) que un programador no estructurado. En sí, considero que que hay que darle dignidad total a algo tan serio como habilitar capacidades de negocio o de apoyo a través de software a las Organizaciones.

      En cuanto a lo de tester, pues ..... lo podemos mirar en modelos clásicos en los cuales basta "desarrollar" y luego probar a punta de checklist, no en casos dónde hay orientación a TDD, o BTDD, etc.... en los modelos en los cuales se hacen cosas por hacerlas y no porque sean consideradas importantes o que generen realmente el valor que pretende.

      Eliminar
  8. Yo diría, muchos desarrolladores de conferencia y pocos desarrolladores de verdad, en alguna ocasión trabaje con una de las personas que más se mueve en Medellín en los temas de desarrollo ágil, asiste a cuanta conferencia hay, pero a la hora de la verdad, no sabe que es una clase, que es polimorfismo, herencia, se dedican a repetir lo que escuchan en las conferencias, pero no tienen la capacidad de aplicar el conocimiento, de hacer un algoritmo, de leer documentación. Les sobra conferencias y les falta calle y estudio

    Buen post, saludos

    ResponderEliminar
    Respuestas
    1. Si, fundamentos. Conocimiento más allá de 2 metros de profundidad, no higiénico o paisajista. Bueno, de ahí tener claro principios de diseño, prácticas, GoF, etc, etc. Código limpio, etc, etc, etc.... ahhh y al laboratorio...a desarrollar...

      Eliminar
  9. Me pareció interesante esta frase "En conclusión, nos preocupamos por el cuidado de la caja, del tiempo, del presupuesto y del alcance, pero no en la generación de valor hacia el cliente quien es finalmente el más interesado en el software, si este le proporciona beneficios."

    Del resto del artículo creo que es una opinión interesante pero hay que estudiarla desde varias perspectivas aunque si tenemos un problema de cultura con respecto a la valorización de la mano de obra

    ResponderEliminar
    Respuestas
    1. Creo que el articulo no esta hablando de la valorización de la mano de obra, de eso esta hablando el gobierno en este momento mirando cuanto va a ser el porcentaje de aumento para el salario minimo el otro año.

      El articulo a lo que se refiere, es que no sabemos en que momento nuestra hermosa profesión que es todo un arte, se volvio un monton de certificaciones en herramientas, con desarrolladores que luego de un año conociendo de una herramienta ya se creen arquitectos de soluciones, de personajes que luego de certificarse PMI consideran que ya pueden ser gerentes de proyectos de software como si se tratara de una obra civil con un presupuesto y una cantidad de obreros y olvidaron que el software es una pieza de arte.

      Las discusiones acerca de la mano de obra mal valorada dejemoslo a los economistas.

      Eliminar
  10. Buen Post, llegue a él por pura casualidad. Lo republicare! Saludos

    ResponderEliminar
    Respuestas
    1. Hola Carlos. Gracias, por tu comentario.
      Increible que nos contactemos por un post ..... saludos...

      Eliminar
  11. Muy buen post.

    El panorama de mucho cacique y poco indio hace que:

    - Los caciques monopolicen la toma de decisiones, provocando paralisis por inaccion. Pues para cualquier decision hay que reunirse a discutir.

    - Los indios no participen pues cualquier idea que propongan sera robada, bloqueada o recharazada por un cacique.

    ResponderEliminar
  12. Burocracia absurda, en la cual el centro no es la generación de valor al negocio sino la medición de egos y fuerzas de poder......

    ResponderEliminar
  13. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  14. Hola Gabriel.

    Muy buen post, estoy totalmente de acuerdo con tus afirmaciones. Me alegro encontrarme con un post como éste, no soy desarrolladora pero si analista de calidad, y lo que afirmas aplica para las dos labores. El desarrollo de software desafortunadamente se ha desenvuelto en países como el nuestro de manera muy atípica, además de tener muchos vicios. Por ejemplo se concibe la calidad y el desarrollo del software como dos "procesos" distintos con equipos separados, cuando en realidad son dos actividades que hacen parte de un solo proceso: el de desarrollar software, Lisa Crispin lo menciona de manera elemental pero clara "Pruebas + Codificación = proceso de desarrollo". Por otro lado así como se tiene muchos arquitectos y gerentes de proyecto PPT o power point (como se les llama mordazmente a quienes olvidan la esencia y el concepto y se concentran en la herramientas) también tenemos analistas y líderes de calidad a los que podemos definir bajo esta misma sigla, como anécdota relacionada a este término podría contar muchas, pero tengo dos que creo difícilmente olvidaré: La primera se relaciona con una líder de proyecto que cuestionó mi deseo de conocer la arquitectura del proyecto al que en breve yo le haría QA, me dijo "un QA no necesita saber nada de desarrollo solo necesitamos tener el punto de vista del usuario final", por demás está decir que es líder de proyectos de QA de una empresa de QA, que tiene como clientes a grandes empresas. Por otro lado está la afirmación de una "analista de QA" a la que le estaba haciendo entrega de un proyecto que afirmó con vehemencia que las reglas de negocio y las validaciones del proyecto eran lo mismo o.O.

    Nuevamente mil gracias por tu aporte, publicaré tu post tantas veces como pueda, con la esperanza de que cada vez seamos más los que nos unamos a la noble causa de considerar el desarrollo de software como bien lo dices tú "un arte" y no "una maquila de hacer camisas"


    Saludos.

    ResponderEliminar
  15. Gracias a ti. Si, creo que hacemos software ..... y a veces nos preocupamos tanto por hacer un bendito cronograma, que a la larga ni aplica. Nos preocupa más decir... en que porcentaje vamos....cuanto es el valor ganado... en vez de enfocarnos en el valor real al negocio...

    ResponderEliminar