Muchos Caciques y Pocos Desarrolladores

28 October 2013



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 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 chinpances 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 olvidansose 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 intronspecciones 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 seguia 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 súper 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 paises 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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Ricardo Gabriel Martinez Zorrero, CSP,CSM, 10/28/2013 7:44:47 PM
Desde mi experiencia personal, ser desarrollador te da muchas de las satisfacciones más importantes en tu vida profesional.

Sin embargo, la falta de metodología de administración de proyectos provoca que el entusiasmo por ser desarrollador se apague pronto entre sobretrabajo, retrabajo y todo tipo de malas prácticas. Tal vez algunos desarrolladores busquen llevar su experiencia desde las trincheras a la administración de proyectos, otros probablemente lo vean como un cambio profesional lejos de una actividad que puede volverse muy estresante eventualmente.

You must Login or Signup to comment.