El código legacy no es solo un problema técnico. Es código que existe y se ejecuta en algún lugar, que se utiliza y que es mantenido y operado por un equipo, por personas reales. Personas que tienen que vivir con las consecuencias de decisiones pasadas, ya sean suyas, de su dirección o de antiguos compañeros externos. Personas que tendrán que asumir si surge un error o si se produce un problema de producción en mitad de la noche. No es una posición fácil, y con frecuencia se pasa por alto cuando se aborda la modernización del software.
Cuando se decide una migración o actualización del código, o cuando se implementa algún tipo de reescritura, el enfoque habitual es traer personas externas al equipo durante un período de tiempo para comenzar a liderar el uso de nuevas tecnologías. Esto puede ser en parte porque hay una falta de conocimiento interno, pero también porque el equipo ya está ocupado realizando sus tareas diarias. Por ejemplo, supongamos que estás cambiando la versión del lenguaje desde Java 8 hasta Java 21, o que estás migrando de una plataforma propietaria a una de código abierto, o que empiezas a utilizar nuevas bibliotecas y dependencias. En cualquier caso, es conocimiento que no se distribuye necesariamente dentro del equipo porque en general, no hay tiempo disponible para la formación y el aprendizaje continuo.
En otras palabras, es un problema a medio o largo plazo de estrategia de gestión del equipo: enfocarse en entregas a corto plazo, ignorando la fase de mantenimiento y el futuro del software.
Sea cual sea el motivo, puede existir una brecha de conocimientos entre las tecnologías más recientes y las habilidades que comparte el equipo. A menudo, los responsables de la toma de decisiones piensan que, al incorporar a personas con conocimientos técnicos y dejarlas trabajar con el equipo, estas habilidades se adquirirán por osmosis.
Aprender no es mágico
Sin embargo, hay varios problemas con esta lógica que he visto muchas veces en diferentes proyectos y organizaciones :
- El software no es solo “técnico”, sino que también abarca lógica empresarial que puede perderse o ignorarse por personas externas que solo están haciendo mejoras técnicas y no trabajando de manera cohesiva con el resto del equipo.
- Si no hay una estrategia clara para compartir conocimientos y dedicar tiempo a la formación activa, entonces eso solo agrega presión adicional al equipo para mantenerse actualizado mientras realizan sus tareas diarias. El conocimiento no se transfiere si no se trabaja por ello activamente.
- Después de algún tiempo, las personas externas dejarán y el equipo central tendrá que manejar, mantener y trabajar sobre los cambios en las tecnologías y en el código implementados por personas que ya no están allí, que no conocían la lógica empresarial ni estaban familiarizados con sus necesidades..
- Esto solo agrega frustración y presión al equipo central porque, al final, ellos serán los que tendrán que vivir las consecuencias de todos los cambios, quienes van a heredar un software que les sera ajeno, que dependerá de herramientas más recientes, pero con consecuencias similares a otros casos de softwares heredados.
Experiencias
Me vienen a la mente dos experiencias de las que he sido testigo. La primera fue una migración de un middleware de integración propietario a una reescritura en usando herramientas de código abierto, en la que, en lugar de permitir que algunas de las personas más competentes del equipo mejoraran sus habilidades en la nueva tecnología, la dirección decidió contratar a un consultor externo como desarrollador principal, alguien que conocía la tecnología objetivo, pero que no sabía nada sobre cómo funcionaba el negocio. Esto, por supuesto, provocó frustración a diferentes niveles, ya que el nuevo desarrollador principal tardó mucho más tiempo del que la dirección esperaba, con razón o no, en ser productivo. Esta estrategia tampoco ayudó a los miembros del equipo interno a desarrollar sus habilidades, ya que las directrices para el desarrollador externo eran solo producir código. Una alternativa mejor habría sido apoyar a uno de los miembros originales del equipo para que creciera como desarrollador principal, aprovechando sus conocimientos y experiencia y proporcionándole apoyo para dominar la nueva tecnología.
La segunda experiencia fue un proyecto de reescritura completa, donde se agregó una equipo de desarrolladores externos al equipo central para reconstruir una aplicación completamente. Esto se tradujo en tener una mala mezcla de personas que conocían la área de negocio de la empresa pero que estaban obligadas a trabajar con tecnologías que no conocían y personas que conocían la tecnología pero nada sobre el negocio, lo que introdujo problemas de errores y mantenibilidad. De nuevo, el problema era que la dirección creía que simplemente por agregar personas a un equipo operaría la magia y que el conocimiento se transmitiría sin problemas.
¿Qué debemos hacer?
Cree que es importante considerar el largo plazo y comprender que al introducir personas externas con conocimientos específicos en un proyecto, su objetivo principal no debe ser reemplazar al equipo central , sino apoyarlos a apropiarse las nuevas tecnologías. Debe haber al menos una persona cuyo objetivo sea programar junto al equipo, guiándolos y creando oportunidades de aprendizaje para que pueda realmente mejorar sus habilidades.
Sin embargo, para que funcione, hay una condición: el equipo debe tener el apoyo del o la líder, y la actualización de habilidades debe ser un objetivo claro. Si no hay confianza, entonces no habrá un espacio seguro para que el equipo se reconozca lo que necesita aprender, y esto será inalcanzable. Lo mismo ocurre si se impone entregar resultados con la misma velocidad que antes o incluso más rápido porque ahora tienen apoyo externo. Esto solo obstaculizará cualquier posibilidad de aprendizaje.
En otras palabras, planifica el aprendizaje como una estrategia. Es el futuro de tu equipo y el futuro de tu software. Esto no significa que no puedas pedir a personas externas que produzcan código o entreguen resultados, pero debe quedar claro para ellos qué hacer si tienen que elegir entre hacer algo rápidamente por su cuenta o hacerlo con otra persona para que se pueda compartir el conocimiento. Una vez más, el aprendizaje lleva tiempo, debes tenerlo en cuenta y planificarlo en consecuencia para que sea posible.
Y si quieres un equipo resiliente, preparado para el futuro, entonces necesitas un equipo que no se sienta frustrado por las decisiones tomadas por otros que no tienen que vivir con las consecuencias de sus actos. Y necesitas un equipo que haya sido parte del cambio. Que no se haya visto obligado a adaptarse sin poder opinar sobre el proceso.
El código también es las personas que lo poseen.