Principios sólidos

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, ponerlos 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, decía que el licitante debía adaptarse a las metodologías de trabajo más comunes, y mencionaba 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 poder 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 todo se habrá hecho con conciencia, mejoras continuas, limpieza de código, etc.?

Miedo me da encontrarme con algo así. 

En esos proyectos se hablaban de tecnologías que ya existían hacer quince años y que siguen muy presentes aunque bajo revisiones más recientes.

En otro, que no tiene nada que ver con los anteriores, se hablaba de trabajar a muy bajo nivel con cierto tipo de dispositivos, empleando el protoloco DLMS.

Y para variedad, estoy trabajando como colaborador externo para una magnífica compañía nacional, líder en su sector, y de nombre Altafonte. Utilizan un sistema basado en PHP, base de datos MemSQL, etc. A sus desarrolladores los considero unos héroes, por haber sabido avanzar en la solución, la base y el core de su negocio, mientras éste crece con multitud de nuevos requerimientos continuamente.

Pensando en todos esos proyectos, ¿qué es lo que pueden tener en común?

En realidad, tecnológicamente hablando, 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 que son comunes y antiguos, y que además no son exclusivos de nuestro sector de desarrollo de software.

¿Qué sería de todos esos proyectos sin una correcta organización y planificación?

Para cualquier cosa que haya que hacer, escribir un libro, ahorrar a largo plazo, realizar un proyecto software cuya solución va a durar años, todo medianamente complejo y que se expande en el tiempo, requiere de organizar y planificar.

Y eso es un trabajo en sí mismo. Lo he visto muchas veces, me temo, se organiza al principio, pero ya después las cosas van cayendo en el olvido. 

Cualquier esfuerzo de organización debe ser continuo y hay que dedicarle un tiempo recurrente, es una tarea más que hay que meter entre nuestras actividades.

El proyecto, aún sin la mejor organización, se puede terminar, claro, pero con toda seguridad se habrá tenido que dedicar un esfuerzo mucho mayor y la gente habrá soportado mayores niveles de estrés.

Todos esos proyectos, ¿se podrían enfocar igual sin una mejora continua?

En cualquier proyecto largo, sobre todo si lo actual depende de lo anterior, hay que tener una actitud de mejora continua sobre todo lo que ya se ha realizado. De no ser así, el tema va creciendo y creciendo sobre bases que no están bien, y llegará el momento en que todo se desmorone.

Hay que realizar restrospectivas cada cierto tiempo; las lecciones que nos dan tienen muchísimo valor para seguir avanzando con pasos seguros.

En software, ¿se mejoran todos 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 assets pueden y deben ser mejorados al mismo ritmo, sin olvidar que la calidad de las pruebas debe ser la misma que la calidad 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 software que deben ser evolucionados en un periodo de tiempo muy largo, años.

Todo, absolutamente todo, influye para el resultado final sea mejor.

¿Y qué hay de los flujos de trabajo?

Me encuentro que las organizaciones se 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 cómo se debe hacer esto o aquello y consensuarlo con la gente implicada.

De ese modo, con el tiempo podemos comprobar las deficiencas, trazarlas 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 úlima API de Android, o entornos como Xamarin o PhoneGap, o bien actualizar una solución de NodeJS basada en la versión 0.12.x al nuevo salto de nivel con 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 la 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 así muchas más posibilidades de éxito y adaptación a nuevos escenarios.