Diario de Programación

Uno de los valores del manifiesto ágil es valorar "Individuos e interacciones sobre procesos y herramientas". Este es posiblemente el más importante de todos ellos y quizás, el que menos en cuenta se tiene cuando se intenta implantar una metodología ágil. No por la parte de "interacciones", ya que cosas como programación en parejas, los daily scrum meeting, y demás tipos de interacciones sí se tienen muy en cuenta, sino por la parte de "individuos".

Según mi experiencia, precisamente la parte de "individuos" es la más importante de todas y sin ella, todo lo demás se va al garete.

Con la parte de individuos se quiere decir gente preparada y adecuadamente motivada, es decir, gente que sabe hacer bien su trabajo y que tiene ganas de hacerlo. Y eso es lo realmente importante. Si la gente no es técnicamente adecuada o no tiene ganas de hacer las cosas, da igual que hagan o no reuniones diarias, que trabajen en parejas, que se les den herramientas o que interaccionen con el cliente: el trabajo no sale bien.

Y eso es algo que estoy viendo continuamente en el trabajo. Según qué personas caigan en qué proyectos, estos pueden ir bien o mal, incluso aplicando la misma metodología con las mismas herramientas.

Así, hay proyectos que cuando llegan a los programadores están totalmente sin definir, no se sabe muy bien qué es lo que hay que hacer en ese proyecto, qué es lo que quiere el cliente y ni siquiera se sabe cuales son los requisitos. Mientras, otros proyectos llegan a los programadores bastante bien definidos, con una idea clara de lo que hay que hacer (aunque luego cambie) y llega con algo de documentación en condiciones, al menos, para las partes con más incertidumbre. Casualmente, las personas responsables de proyecto suelen coincidir en los casos que llega o no llega el proyecto definido. Si el responsable es "Fulanito", su proyecto llega bien definido. Si es "Menganito", no se sabe qué hay que hacer en ese proyecto.

Luego, entre los programadores, siempre hay módulos que llegan en plazo más o menos bien y sin demasiados problemas, incluso aunque esa parte no esté bien definida. Otros módulos, llegan mal y con muchos problemas, aunque estén bien definidas. Casualmente, las partes que llegan bien suelen estar hechas siempre por las mismas personas y las que dan muchos problemas, por otras. Un programador bueno técnicamente, con iniciativa y bien motivado, cuando le llega un algo para hacer mal definido, empieza a dar la paliza al responsable del proyecto para enterarse qué tiene que hacer, hace sus propias propuestas si no lo consigue, hace su código bien hecho y fácilmente modificable y finalmente entrega algo que funciona y que sirve para lo que quiere el jefe, incluso aunque el jefe no sabía qué quería. Un mal programador, sin iniciativa y sin motivación, cuando le llega una cosa sin definir, no hace nada salvo protestar y se entretiene con internet o con otra cosa. Al final, cuando la cosa corre prisa, hace lo que le puede deprisa y corriendo, lo hace mal porque técnicamente tampoco es bueno y el proyecto tiene problemas y se retrasa.

Obviamente, no debería llegar a los programadores cosas sin definir, pero aquí puedes ver que aunque el procedimiento y las herramientas sean las mismas, si se junta un mal jefe de proyecto con malos programadores, el proyecto va de culo, mientras que si se junta un buen jefe de proyecto con buenos programadores, ese proyecto suele ir de cine.

Cuando fallan las personas en una de las dos partes, la otra puede "arreglar" la situación. Ante un jefe de proyecto incompetente, los buenos programadores acaban prácticamente definiendo y llevando ellos el proyecto. Ante unos programadores incompetentes, un buen jefe de proyecto lleva mucha supervisión, define mucho las cosas, prueba mucho y sabe sacar lo máximo posible de los programadores que le han tocado.

Y todo esto es real, es lo que voy viendo en varios años de trabajar en proyectos con bastante gente, tanto de currito como llevando programadores.

En su día, para nuestros proyectos grandes, teníamos muchas librerías y módulos separados. Cada programador solía ser responsable de uno de los módulos y tenía su proyecto independiente, con sus programas de prueba, simuladores y todo lo que le hiciera falta.

Eso estaba bien, pero tenía una ligera pega. No usábamos algo como maven y no teníamos control ninguno de dependencias cruzadas. Cada programador ponía sus dependencias de otros módulos según lo necesitaba. El problema, al final, es que no había forma de compilar eso desde cero, ya que era fácil que un módulo necesitara del jar de otro módulo, que a su vez necesitaba de un tercero y tras una cadena más o menos larga, había un módulo que necesitaba del jar del que estamos compilando. Sí, ya sé que es una falta grave de diseño y debería haberse pensado al principio y dejar claras esas dependencias, pero también es cierto que entre lo que lo pensado antes y la realidad después hay muchas diferencias.

Al usar maven, decidimos hacer un proyecto grande con subproyectos debajo (uno por módulo). Así maven comprueba las dependencias y si un programador pone una dependencia que no debe, maven le protesta. Sin embargo, esto también tiene una gran pega. El compilado desde cero se hace desde arriba del todo y el fallo de un módulo hace que los demás ni siquiera intenten compilar. Además, la dependencia se hace entre fuentes, por lo que para estar a la última, necesitas hacer update de todos los fuentes. Eso, en un proyecto grande, puede ser un buen rato casi todos los días.

Al descubrir que se puede usar el core de Spring Framework, aunque sean aplicaciones de escritorio, para instanciar los módulos y usar los eventos de Spring Framework para comunicarlos entre sí, me da la impresión de que se puede hacer relativamente fácil que los módulos hablen entre ellos y se pasen datos sin necesidad de que tengan dependencias entre ellos. Los primeros mini-proyectos en la que hemos usado este framework y hemos hecho módulos indpendientes totalmente, comunicados a través del framework y de código de transformación de tipos de datos de un módulo a los tipos del otro en el main, están resultando una pequeña maravilla en cuanto a organización.

Así que me estoy planteando el volver a módulos separados, en proyectos independientes, y con prohibición de poner dependencias de otros módulos, salvo algunos muy concretos pensados más como librerías comunes que como módulos a instanciar como beans de Spring Framework.

La pega es la de siempre, la paliza de mover todos los repositorios de CVS para que tengan otra estructura y el retocar todo el código, sobre todo quitando dependencias de unos módulos con otros. Todo se andará, poco a poco.

Una pequeña aclaración sobre las dependencias entre módulos. Suponamos que tenemos modulo1.jar y modulo2.jar y que modulo1.jar necesita llamar a cosas de modulo2.jar. Para no meter la dependencia a lo bestia, normalmente hacemos una InterfaceModulo2 con las llamadas a las cosas del módulo2 que sean de interés desde fuera. Por supuesto, esa interface está en modulo2.jar. Y por supuesto, los parámetros y retornos de los métodos de la interface son tipos primitivos de java o bien tipos que están en modulo2.jar. Pues bien, eso hace que modulo1 dependa de modulo2, ya que ve al menos a la interface y a los tipos de parámetros y retornos. Por supuesto, una opción es hacer un tercer módulo InterfaceModulo2.jar con la interface y los tipos, pero me parece multiplicar el número de jars a lo tonto.

La opción que estamos planteando ahora es que modulo1 no vea en absoluto a modulo2. Cuando necesite algo de módulo2 (en realidad, cuando necesite algo, lo que sea), debe lanzar un "evento" indicándolo. Es el código del main el encargado de recoger ese evento y hacer la petición a modulo2, para pasar luego los resultados a módulo1. Esto puede parecer costoso, sobre todo si hay mucha necesidad de cosas de modulo2 por parte de modulo1, pero… si hay tanta necesidad de cosas ¿no estará mal pensado hacer dos modulos? ¿no estará mal pensada la funcionalidad de cada módulo?.

En fin, un pequeño rollo, pero como indico en el título, son símplemente "pensamientos".

Hace unos días comentaba si la habría cagado al aceptar un puesto un poco más de "jefecillo" que antes. Y efectivamente, compruebo que la he cagado. La prueba de ello es que en vez de hacer código, me estoy dedicando a mirar cosas como statcvs, una herramienta que mira el log de todos los commits que se han hecho en un proyecto en CVS y luego saca un montón de gráficos molones, inútiles, pero molones.

Aquí van unos cuantos ejemplos. El siguiente es un gráfico que muestra los commits como puntitos de varios desarrolladores a lo largo de cerca de cuatro años. Me he cargado el nombre del proyecto y de los desarrolladores, por  aquello de la discrección. En cada gráfico, el eje y son las horas del día, de 0 a 24. En el eje x son los días a lo largo de los años. El primer gráfico, de puntitos azules, muestra el total de commits del proyecto. Los siguientes, con puntitos rojos, cada uno de los desarrolladores.

Llama la atención el tercer desarrollador, que se fue a teletrabajar hace un año. Se nota claramente que desde ese día NO tiene horarios. Antes hacía commits de 8 a 6, horario de oficina. Ahora es habitual que haga commits a la una de la madrugada.

También llama la atención el último, con una densidad de commits especialmente alta. Se ve que es amigo de CVS. Curiosamente, se ve una pequeña franja horizontal sin commits, correspondiente a la hora de comer.

En el sexto desarrollador, hacia el principio del gráfico, también se ven unos días de agobio. con un commit pasada la media noche.

También se ve, gracias a Dios, que en mi empresa tenemos un horario en general normal. Son raros los commits más allá de las seis de la tarde.

y en este otro gráfico, se ve cómo han ido añdiendo líneas de ćodigo en otro proyecto distintos desarrolladores. Las grandes subidas se deben posiblemente a copy-paste de otros proyectos (vergüenza) o bien a "refactoring" intensivo, a base de mover grandes fuentes bloques de fuente de un sitio a otro (espero que sea eso). En la parte baja estaba el nombre de los desarrolladores, asociado a cada una de las líneas de color, pero me los he cargado.

y aunque no he puesto ejemplos, también hay gráficos para cada desarrollador indicando en qué horas del día mete más en CVS o en que días de la semana. Aunque en general este tipo de gráficos si es más o menos aleatorio, a veces se ve gente que tiende a meter en CVS los viernes, o bien justo antes de comer o de irse a casa por la tarde. Supongo que eso también es una mala costumbre, da la impresión de que no meten el código cuando lo han probado bien, sino como una especie de "backup" de su trabajo diario, metiendo en CVS cosas que quizás no están lo suficientemente probadas.

Aquí puedes ver un ejemplo completo de los gráficos estadíscos generados por statcvs.

Hace un año me pusieron algo así como de "asesor" en java, herramientas y forma de hacer las cosas de un montón de gente. No tenía responsabilidad directa en los proyectos ni tampoco en la gente. Debía encargarme de que unos y otros no hicieran las mismas cosas por duplicado, que todos usaran herramientas similares, formas de hacer las cosas similares, etc. Sin embargo, la decisión final era de cada grupo.

En esas condiciones era dificil conseguir grandes cosas, pero tenía cierto tiempo libre para ver cosas nuevas, experimentar y en definitiva, jugar con java y todo lo que hay alrededor.

Sin embargo, hace unos meses me ofrecieron llevar un grupo más reducido de gente, esta vez sí, totalmente responsable de ellos y de su trabajo. Me tocaría hablar con los responsables de proyectos para ver qué tenemos que hacer, organizar el trabajo de la gente y hacerlo. Y lo cogí.

Ahora mi trabajo consiste en repartir marrones, perseguir a la gente para ver si los hacen o no, probar lo que hacen y lo peor de todo, con agobios y prisas, muchos proyectos, todos para ayer y con poca gente. No tengo tiempo en absoluto no solo para jugar con java, sino ni siquiera para codificar algo, lo que sea.

Así que sólo me queda esperar un tiempo a ver si la situación se alivia para poder intentar hacer todas esas cosas nuevas que tengo pendiente de probar. O bien la otra opción, pedir que me hagan responsable de un proyecto con todo lo que eso lleva: trato con el cliente, hacer un montón de documentación y olvidarme de java totalmente, aunque al menos sólo me dedicaré a un proyecto y podré (supongo) organizarlo a mi gusto (no a nivel de código). Me sigo resistiendo a olvidarme de programar, pero veo que el tiempo me lleva inexorablemente a ello.