Un desarrollador no es su código de hace tres años (o no debería serlo)

Cualquier desarrollador que revise su código de un año de antigüedad debería no estar satisfecho con el, debería ver algo que le gustaría cambiar o rehacer directamente. Si no es así es que no ha aprendido nada en el último año.

Esta profesión es dura, siempre tienes que estar aprendiendo, madurando, no solo en las cuestiones técnicas, si no como trabajar en equipo y mantener una comunicación efectiva con clientes y jefes. Mantener una mente abierta a nuevas ideas, saber cuando hacer concesiones y cuando no, evaluar riesgos, tomar decisiones y aprender de los errores.

Aprovechar las oportunidades de mejorar

Cuando se comete un error en una aplicación, ya sea de planteamiento, uso de tecnologías, de gestión o de cualquier otra cosa, no hay que verlo como un fracaso, si no como una posibilidad de mejora. No se trata de buscar un culpables, lo que hay que hacer es un profundo análisis y saber en qué se ha fallado, como se hubiese podido evitar y qué acciones se deben tomar para que no se vuelva a repetir.

Si no se aprende y se de continúan defendiendo malas decisiones la experiencia no sea útil.

¿Cuanta gente hay con diez o veinte años de experiencia que llevan haciendo lo mismo durante esos años? Repitiendo lo mismo una y otra vez, evitando continuamente salir de esa zona de confort. Defendiendo decisiones tomadas hace años, sin innovar sin evolucionar. Que cada vez que se pide el cambio en un sistema, el cambio requiere más y más tiempo. Pero mientras va funcionando, nadie se preocupa.

Por un lado tenemos a un desarrollador que tiene veinte años de experiencia, pero en el fondo solamente uno. Si esa persona cambia de proyecto o sele saca de la zona de confort ¿qué pasaría con él?

Evitar la quiebra técnica del proyecto

Por otro lado tenemos el producto. Con el paso del tiempo todos los sistemas informáticos generan deuda técnica. Cuando resulta difícil explicar porqué un cambio aparentemente sencillo lleva mucho más de lo esperado, es que la deuda técnica comienza a ser difícil de pagar.

En proyectos a largo plazo hay que tener en cuenta que no solo hay que evolucionar funcionalmente un producto, hay que refactorizar, revisar las decisiones tomadas, etc.

Es difícil explicar al cliente que debe pagar por cambios que no le van a aportar mejoras de negocio visibles, ahí está el reto en gestionar al cliente. Hay que tenerlo contento, gestionar sus expectativas y ganarse su confianza.

Si no se toman medidas, la deuda técnica irá creciendo, las solicitudes de cambio serán cada vez más costosas, el coste de mantenimiento se disparará, la satisfacción del cliente disminuirá, la confianza en el equipo de desarrollo se perderá. Y llegaremos a la quiebra técnica del proyecto. Es decir cuando se dice “yo lo tiraba todo y lo volvía a hacer desde cero”.

Así que lo mejor es tener un plan de revisión y mejora continua, no siempre se pueden acometer las mejoras en el momento, pero no se deberían aplazar en demasía.

Y recordad: los experimentos, con gaseosa. Una cosa es que los desarrolladores jueguen e investiguen con nuevas tecnologías y otra cosa es sacar una aplicación a producción una librería en estado alpha.

En resumidas cuentas, usar las herramientas adecuadas para cada trabajo, aprendizaje constante aprendiendo de los errores.
Y es que un desarrollador no es su código de hace tres años (o no debería serlo)