Jun 22

Visita a Paradigma tecnológico

Hace ya casi un mes, me tocó una visita a Paradigma Tecnológico.

El tema es que un departamento de nuestra empresa, no el mío, tiene un proyecto en el que está como requisito el uso de algunas tecnologías modernas, entre otras, BigData. Puesto que en los departamentos de nuestros alrededores nadie tiene experiencia con estas tecnologías, se ha decidido subcontratar desarrollo y asesoría a alguien que sepa del tema, para sacar el proyecto adelante y para aprender nosotros sobre ello. La empresa elegida ha sido Paradigma Tecnológico.

Esta compañía ágil, como reza en su página web, hace nuestro proyecto con Scrum y finalizado el primer Sprint, llega el momento de hacer la "demo" al cliente, es decir, al departamento de mi empresa. Teniendo yo fama de friki, este departamento y  mi propia jefa, decidieron que yo debía acudir también a ese sprint, para enterarme lo más posible de este tipo de nuevas tecnologías y ver si son aplicables a otros proyectos. Así que allí fuí.

Lo que más me llamó la atención, en lo que se puede ver dando un paseo por las instalaciones de Paradigma, es que sí tiene toda la pinta de que usen Scrum realmente en todos los proyectos. Según se pasea, se ven tableros de Scrum y paquetes de postit de colores por todos lados. Según se podía ver y me contaba una de las personas que trabaja allí, los desarrolladores trabajan en una sala diáfana con mesas agrupadas de 6 en 6, creo recordar. Los programadores de un proyecto trabajan juntos en un grupo de mesas y en la pared al lado de su grupo de mesas tienen el tablero Scrum. Nos enseñaron también el product backlog de nuestro proyecto, un tablero enorme con miles de postit pegados con celo y nos enseañaron el gráfico "burn down" correspondiente a nuestro primer sprint.

En cuanto al Sprint que nos hicieron, era un poco extraño, posiblemente por ser el primer Sprint. Básicamente consistía en explicarnos la arquitectura decidida, una demo real sencilla viendo funcionar esa arquitectura y un "mono" de la interfaz de usuario para que nos hicieramos una idea de cómo iba a ser. Como es de rigor en un sprint, insistieron mucho en que hicieramos comentarios y diéramos nuestras opiniones, ahí creo que nos quedamos un poco "cojos", culpa nuestra.

Hay algunos detalles del Scrum que no me cuadran con lo que pensaba, por ejemplo, para el segundo Sprint se indicaron las tareas que se iban a hacer, imagino que previamente acordadas con el Product Manager que es una pesona de nuestra empresa. Lo que no me cuadra es que en ese segundo Sprint no se llegaba a una funcionalidad útil para el cliente, sino que las tareas eran pequeños (o grandes) trozos de código que evidentemente hay que hacer, pero que no constituyen en sí un producto, aunque sea muy básico, que se pueda entregar de alguna forma, salvo quizás, como un conjunto de liberías. Quizás yo soy demasiado teórico. Quizás un segundo sprint (de 3 semanas) sea también muy pronto para obtener ese primer producto básico. En cualquier caso, no le he dado demasiada importancia, ya que en mis intentos de hacer Scrum con mi grupo de trabajo, sé lo complejo que es entregar un pequeño producto en los primeros Sprint, donde hacer cualquier cosa completa que vaya desde un extremo del sistema (la interfaz de usuario) hasta el otro (el equipo hardware que se quiere controlar), pasando por todos los pasos intermedios (base de datos, lógica de negocio, …) requiere hacer mucho código de la arquitectura del sistema. Pero me deja ese mal regustillo de que quizás Scrum es demasiado teórico, excesivamente complejo, o no aplicable a cualquier proyecto …

Resumiendo, la impresión en general ha sido buena y me voy confirmando cada vez más en que hacer un Scrum que cumpla al 100% con la teoría de Scrum es muy complejo.

May 20

Cambio de tercio

analizador de espectrosHace ya un mes largo me llamaron a una reunión en la que íbamos los posibles candidatos para hacer un nuevo proyecto, previsiblemente en java. El proyecto consiste en hacer unos bancos automáticos de prueba para unos equipos electrónicos que se van a empezar a fabricar en serie. ¿Adivináis a quién le ha tocado el fregado de entre todos los candidatos?.

Así que nada, he cambiado totalmente de tercio. He pasado de hacer ventanas Swing en java a controlar equipos de instrumentación electrónica (analizador vectorial, fuente de alimentación, generador de señal….) y llevo más de un mes en ello, junto con algunos de mi grupo.

Por un lado estaba la posibilidad de tener que controlar un puerto RS-485, (similar a un puerto serie RS-232 pero de otra manera). La librería a usar RXTXcomm, pero después de unas pruebas y ver que funciona correctamente, me comentan que vamos a comprar un conversor de serie a lan, de forma que podemos hablar con el equipo con puerto serie a través de un socket normal de lan.

Por otro lado, los otros equipos de instrumentación tiene conexión lan directamente y el protocolo de mensajería para controlarlos es estándar, SCPI. La verdad es que es muy tonto, se abre un socket normalito y se mandan comandos de texto terminados en un retorno de carro. El equipo devuelve también comandos de texto terminados en retorno de carro. De hecho, hay posibilidad de conectarse con un vulgar "telnet", escribir los comandos a mano y leer en el mismo terminal las respuestas.

Lo curioso del caso es que hace algo más de 15 años, cuando empecé a trabajar, empecé precisamente controlando instrumentación electrónica para bancos automáticos de pruebas (de aquella en BASIC y con una versión primitiva de LabWindows), Y estoy alucinado de los cambios que ha habido en este mundillo. Antes un osciloscopio era una cosa con botones gordos, pantalla de fósforo verde y un tubo de rayos catódicos. Ahora un analizador de espectros tienen un display LCD, con un Windows XP metido y una aplicación que arranca al encenderlo. Por supuesto, viene con conexión lan y un pequeño servidor web, de forma que desde tu PC y con un navegador "vulgaris" puedes acceder al equipo y controlarlo.

En fin, me lo estoy pasando como los indios (aunque diga que me aburro al programar según las buenas costumbres) y siempre viene bien un cambio de actividad para renovar los ánimos (aunque siga siendo java).

Apr 25

¿Elegancia o sencillez?

 

En el trabajo llevamos varios días peleándonos con la instalación de una versión de nuestro software en uno de nuestros sistemas. El sistema consta de unas diez estaciones de trabajo solaris y unos veinte PCs con Windows. En todos ellos corren aplicaciones nuestras, en su mayoría java. Estas aplicaciones tienen algunas partes comunes, pero son distintas en cada una de las estaciones y de los PCs (cada uno está especializado en diversas funciones, algunas comunes, otras no y comparten mucha información entre ellos). En las estaciones hay bases de datos Oracle, con muchas tablas comunes, pero otras distintas en cada estación. Y en todo esto reside el problema de la instalación.

La gente está dividida en dos posibles tipos de instalación.

Junto con algunos, yo soy partidario de implementar las distintas funcionalidades del sistema en jar distintos e instalar en cada estacion/PC sólo aquellos jar que son necesarios, de forma que ninguna estación/PC lleve más jar o ficheros de configuración que no va a usar. Esta es la solución que considero elegante, pero es más compleja. Requiere generar instaladores/zips disintos para cada estación/PC, así como ser mucho más cuidadoso en esta generación de instaladores/zips, muchos jar, muchos grupos de ficheros de configuración, partes comunes y partes específicas.

Otros piensan que es mejor hacer un único mega-jar, o unos pocos jar grandes, un único mega-grupo de ficheros de configuración e instalar todo en todos lados. De esta forma, un único instalador o un único zip vale para todas las estaciones/PCs. Luego es el propio software el que mirando el nombre de la estación/PC en el que corre, sabe qué fichero concreto de configuración leer, de qué clase principal hacer el new y actuar como lo que le toca. Esta instalación es, desde mi punto de vista, más chapuza, pero es innegable que es infinitamente más sencilla.

Y después de la pelea de estos días atrás para la instalación según mi punto de vista (disintos zips/instaladores que instalan en cada estación/PC sólo lo necesario), creo que estoy empezando a cambiar de opinión. Los instaladores/zips, desde luego, se hacen con procesos automáticos, pero alguien tiene que decirle a ese proceso qué debe meter. Según evoluciona el software y va llevando más funcionalidades y ficheros, hay que tocar la configuración de la herramienta que genera los instaladores/zips (izpack, maven assembly,…) y hay que hacerlo con cuidado. Este proceso es manual y está sujeto a errores humanos, por lo que a nuestros instaladores siempre les acaba faltando alguna cosa y necesitan su proceso de "depuración".

En fin, no me gustan las chapuzas y tengo que pensar seriamente la forma de mejorar el proceso de generar los zips/instaladores, pero desde luego, es difícil resistirse a la facilidad de instalación de "todo va en todos sitios, aunque no se use". Es mucho más fácil instalar un solo mega-jar en todos lados que instalar varios jar distintos en cada estación/PC.

Aug 10

Manifiesto ágil: Personas sobre procedimientos

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.

Jul 23

Pensamientos sobre proyectos grandes y Spring Framework

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".

Jul 12

Sí, definitivamente la he cagado.

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.

Jul 08

¿La habré cagado?

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.

Apr 30

Pequeño éxito … ¡Y más trabajo!

Como comenté hace unos días, terminé mi pequeña aplicación en python que permite recoger de la gente los tiempos que han dedicado a cada uno de los proyectos y luego genera automáticamente un Excel para entregar al encargado de guardar todo esto oportunamente.

Pues bien, esa aplicación tonta ahorra a mi jefa un trabajo de un par de días de andar preguntando a cada uno a qué se ha dedicado y generar el excel a mano, así que le ha encantado. Tanto, que ha empezado a comentárselo a los demás jefes con el mismo problema y también les ha encantado. ¡¡ Todos quieren !!.

Y claro, cada uno quiere mejoras, añadidos y cosas variadas. Lo que era una aplicación cutre, que básicamente es un script capaz de admitir los datos de la gente desde el navegador y generar un excel, tiene pinta de que se va a convertir con el tiempo en una señora aplicación.

Los jefes que tienen gente, quieren usarla, así que en principio les vale tal cual. La única pega es que cada uno luego querrá el excel de su gente en concreto y no un excel general con todos. Eso me hará meter una nueva columna en la tabla "gente", para indicar quién es su jefe. Y me obligará en la parte de obtener resultados a poner un pequeño combobox que diga "elige al jefe cuya gente quieres convertir en excel".

Por otra parte, están los jefes responsables de los proyectos, con poca gente a su cargo, pero si con un proyecto con muchas contraseñas y muchos dineros. Para ellos el excel es lo de menos, pero lo que si están pidiendo es que quieren una forma de ver cuánta gente carga a su proyecto e incluso un histórico, para saber en cada una de las contraseñas del proyecto, cuánto llevan gastado. Tendré que poner una nueva consulta en la que seleccionando un proyecto salga un listado de toda la gente que se ha dedicado a él.

En fin, tiene pinta de que va a ir creciendo. Lo que generaba un excel con unas veintitantas personas dedicadas a unos siete u otro proyectos, van a ser ahora cerca de sesenta personas dedicadas a una veintena de proyectos. Lo que era una consulta simple, se va a convertir en un par de consultas con cláusula where pedida desde la web.

Y hablando de pequeños éxitos por tareas hechas de motu propio. Hace ya un par de años se me ocurrió que una wiki podía ser buena idea y la instalé. Dentro del departamento se va usando, como siempre, unos pocos más que otros muchos. Pero el caso es que se ha ido corriendo la voz por la empresa. El otro día tuve que mostrarle la wiki a uno de los jefazos (cosa que ha sido bastante comentada entre mis compañeros con su parte de coña 😉 ). Parece que quieren poner una a nivel de la empresa.

Todo esto me recuerda mucho al artículo que leí de Joel Spolsky "Logrando resultados cuande se es un peón". Cuando ves una necesidad que tus jefes no resuelven, una buena opción es perder un poco de tiempo en resolverla tú y si se hace bien, se acaba aceptando por todos. También me da un poco de pena comprobar que muchos de los problemas se resuelven o algunas cosas salen adelante porque algún "currito" tiene la iniciativa de resolver el problema o tirar del carro, sin que nadie se lo pida y sin que ningún jefe, teóricamente responsable del tema, tome cartas en el asunto y organice o apoye la iniciativa desde el principio (y, por supuesto, ponga los medios).