No, no voy a hablar de nada relacionado con los principios de desarrollo S.O.L.I.D., que, en cualquier caso, recomiendo a cualquier programador conocer en profundidad y, sobre todo, poner en práctica.
En los últimos meses he tenido que leer bastante documentación sobre licitaciones y también he estado inmerso en propuestas de nuevos proyectos en colaboración con otras compañías.
En esas licitaciones, algunas para gobiernos autonómicos de mi país, llama la atención la falta de rigor en las especificaciones. Es más, concretamente en alguna se indicaba que “las tareas a realizar se plantearán con exactitud cuando el proyecto sea adjudicado al licitante”. En otra, se decía que el licitante debía adaptarse a las metodologías de trabajo más comunes y se mencionaban CMMI, Métrica 3, etc. En fin…
Al mismo tiempo, la mayoría de esos proyectos consisten en evolucionar aplicaciones que ya están funcionando en consejerías o departamentos de esas regiones.
¿Cómo se puede estimar el esfuerzo para evolucionar algo sin ver su estado actual? ¿Estará la solución hecha unos zorros? ¿Será el típico proyecto espagueti o, en cambio, se habrá trabajado con cuidado, mejorando continuamente y limpiando el código, etc.?
Miedo me da encontrarme con algo así.
En esos proyectos se hablaba de tecnologías que ya existían hace quince años y que siguen muy presentes, aunque bajo revisiones más recientes.
En otro proyecto, que no tiene nada que ver con los anteriores, se hablaba de trabajar a muy bajo nivel con cierto tipo de dispositivos, empleando el protocolo DLMS.
Y, para variar, estoy trabajando como colaborador externo para una magnífica compañía nacional, líder en su sector, llamada Altafonte. Utilizan un sistema basado en PHP, una base de datos MemSQL, etc. Considero héroes a sus desarrolladores por haber sabido hacer avanzar la solución, la base y el core de su negocio mientras éste crece y recibe continuamente multitud de nuevos requisitos.
Pensando en todos esos proyectos, ¿qué pueden tener en común?
En realidad, desde el punto de vista tecnológico, puede parecer que nada: son completamente diferentes. Y, sin embargo, desde un punto de vista más integral (holístico, dirían en otros contextos), el éxito en todos esos proyectos tan dispares sólo depende de principios comunes y antiguos que, además, no son exclusivos de nuestro sector del desarrollo de software.
¿Qué sería de todos esos proyectos sin una correcta organización y planificación?
Para cualquier tarea —escribir un libro, ahorrar a largo plazo o realizar un proyecto de software cuya solución va a durar años—, todo lo que tenga cierta complejidad y se extienda en el tiempo requiere organización y planificación.
Y eso es un trabajo en sí mismo. Lo he visto muchas veces, me temo: se organiza al principio, pero después las cosas van cayendo en el olvido.
Cualquier esfuerzo de organización debe ser continuo y hay que dedicarle tiempo de manera recurrente; es una tarea más que hay que incluir entre nuestras actividades.
El proyecto puede terminarse incluso sin la mejor organización, claro, pero con toda seguridad habrá requerido un esfuerzo mucho mayor y la gente habrá soportado niveles de estrés más altos.
¿Se podrían enfocar todos esos proyectos de la misma manera sin una mejora continua?
En cualquier proyecto largo, sobre todo si lo actual depende de lo anterior, hay que mantener una actitud de mejora continua sobre todo lo que ya se ha realizado. De no ser así, el tema va creciendo sobre bases que no están bien, hasta que llega el momento en que todo se desmorona.
Hay que realizar retrospectivas cada cierto tiempo; las lecciones que nos ofrecen tienen muchísimo valor para seguir avanzando con pasos seguros.
En software, ¿se mejoran todos los tipos de assets?
Se tiende a pensar que las técnicas de refactorización sólo afectan al código de producción.
Pues no, de ningún modo. Aunque refactorizar es un término que se aplica al código, el resto de los assets pueden y deben mejorarse al mismo ritmo, sin olvidar que la calidad de las pruebas debe ser la misma que la del código de producción.
A medida que un proyecto crece, hay que mejorar su estructura, su diseño, la documentación, etc.
Estoy hablando de proyectos de software que deben evolucionar durante un periodo muy largo: años.
Todo, absolutamente todo, influye para que el resultado final sea mejor.
¿Y qué hay de los flujos de trabajo?
Me encuentro con que las organizaciones hacen las cosas de un modo determinado, que puede funcionar mejor o peor, sí, pero no existe la conciencia de establecer claramente un flujo de trabajo para cada proceso que necesita emplear la compañía. Basta con poner por escrito de algún modo cómo se debe hacer esto o aquello y consensuarlo con la gente implicada.
De ese modo, con el tiempo podemos comprobar las deficiencias, identificarlas y mejorar esos mismos flujos de trabajo.
Podemos estar usando tecnologías de hace diez años u otras más recientes; podemos diseñar una nueva solución orientada desde un principio a alguna infraestructura cloud, una nueva aplicación móvil con la última API de Android, entornos como Xamarin o PhoneGap, o bien actualizar una solución de Node.js basada en la versión 0.12.x al nuevo salto de nivel de la versión 5.x.x, etc.
Sin embargo, cada vez estoy más convencido de que todas esas tecnologías, que evolucionan, van y vienen, son parte de un puzle mayor. Aplicando correctamente estos principios sólidos a la hora de afrontar tu trabajo, podrás usar una tecnología casi obsoleta o el stack más de moda en la actualidad, pero tendrás muchas más posibilidades de éxito y de adaptación a nuevos escenarios.