Estos dias se ha celebrado en Madrid la SpringIo, y otra vez he tenido la oportunidad de dar una charla sobre mi experiencia con Grails dentro del Ayuntamiento de Vitoria-Gasteiz, titulada Fallando con Grails. Y esta es la descripción de la charla:

No me entendáis mal, no se falla todo el rato. Además, cuanto antes falles, antes lo arreglas. Diez cosas que no volvería a hacer si tuviera que impulsar el uso de Grails dentro de un organización como el Ayuntamiento de Vitoria-gasteiz. Desde el uso de pruebas o TDD, a la integración continua, pasando por la formación necesaria o como convencemos a la dirección. Siempre una vez pasado un proceso como este, se cambiarías cosas, incorporarías otras o simplemente, las eliminarías. Desde la experiencia de participar en la adopción de Grails dentro del Ayuntamiento de Vitoria-Gasteiz, los 10 errores que no volvería a cometer si empezáramos de nuevo.

Un buen momento para comentar experiencias, técnicas y visiones con viejos y nuevos amigos, y una oportunidad de hablar directamente con algunos de los desarrolladores más importantes de Grails y Spring en este país y en el mundo. Felicidades a la organización por el trabajo realizado, y gracias también a todos los que me aguantaron ;)

Ayer asistí a una nueva edición del WebDevBilbao. Esta ocasión contabamos con la presencia de la gente de PlainConcepts, que como ellos mismos explicaron, son una empresa que da muchos servicios como consultoria, formación, coaching y desarrollo de aplicaciones a medida.

En la parte de desarrollo a medida utilizan metodologias agiles, como no podía ser menos con la gente que cuentan: Rodrigo Corral, Ibon Landa, Vicenç García-Altés... Al final de todo lo que cuentan me quedo con lo que valoran la excelencia en todos los terrenos, con especial incidencia el terrreno técnico. Pruebas unitarias a tope, integración continua tope... Todo esto cuesta dinero y atraer al personal necesario para poder hacerlo es difícil, y uno de los retos es el crecimiento sostenido manteniendo la calidad. Y motor o todo esto es... "el egoísmo" porque cuanto mejores sean, más y mejor trabajarán y el producto obtenido estará en consonancia con este esfuerzo, y por eso se empuja al personal a buscar esa excelencia.

Se comento también cuanto más produce un buen programador con respecto a uno normal, o uno malo. ¿El malo resta? Yo creo que sí, que el malo resta y además produce sensación de frustración en el resto, al tener la sensación de que no avanzamos porque tenemos un lastre con el que cargar.

A nivel personal me quedo con la duda de como lo haría yo en una empresa de este tipo, si podría seguir el ritmo. Hace mucho tiempo que estoy seguro de que hay que ser "el peor saxofonista de la banda", como dice Chad Fowler, porque así aprenderás más y seguirás progresando. Igual tengo que buscar otra banda.

Ayer se celebró en todo el mundo mundial, y por supuesto también en Bilbao, el Global Code Retreat 2011. Por si no sabes lo que es: Explicación de lo qué es un Code Retreat. Básicamente, practicar programando el Juego de la Vida de Conway, para hacer algo así:

Aunque luego no te da tiempo, son iteraciones de 45 minutos, haciendo TDD por parejas, experimentando distintos enfoques, restricciones y técnicas para afrontar el problema.

Hace casi un año asistí a uno celebrado en Donosti, y hoy ha sido el segundo, distinto pero siempre aprendes cosas... tengo que hacer una retrospectiva personal al respecto, ¡qué diablos! aquí va:

• Siempre hay algo que recuerdas correctamente, lo que te recuerda lo mal programador que eres. En este caso no sabía motar un interface en Groovy ¿¿??
• También siempre aprendes algo nuevo, no importa las veces que lo hagas. En mi caso, sigo depurando mi técnica top-down, down-top o whatever.
• Es curioso lo estupenda que nos parece la programación en pares en esto eventos, y lo difícil que es hacerlo luego realidad en el día a día. Tengo que estudiar el fenomeno.
• Está claro que una diferencia fundamental es la motivación. Un sábado a un Code Retreat solo va gente motivada, y eso se nota a todos los niveles, aunque o hagamos nada productivo.
• ¡Nunca me da tiempo ha terminar! Así que depués de esta voy a intentar hacerlo, o por lo menos hasta un grado usable.

Refactorizar es modificar tu código cubierto por pruebas, la reingeniería es modificar tu código y rezar. Más o menos esto es lo que dijo Hamlet D'Arcy en el Greach 2011 en Madrid. Y no puedo estar más de acuerdo, Una de las grandes cosas de tener tu código cubierto por pruebas, es que puede refactorizar ese código que no escribiste tan bien ( directamente lo escribiste mal, a mi me pasa mucho), sin tener que preocuparte de si va a seguir funcionando o no, porque sabes que funciona. Vale, esto es una verdad a medias, porque:

1. Igual el test no está bien escrito.
2. Igual lo tienes que probar a mano.
3. Igual algo en lo que no habías pensado va mal.

En la pasada CAS 2011, Xabier Quesada en su conferencia insistió bastante en lo ineficiente de algunas organizaciones, y lo costoso que esto resulta para el rendimiento general de la organización, cualquiera que sea el objetivo de esta. Eso es "Waste", lo que perdemos al no acertar con el producto deseado, el coste que tiene volver a hacerlo, o la perdida de satisfacción por renunciar a la calidad (por no volver a hacerlo)

En mi organización, o mejor dicho, en el subconjunto de la organización donde trabajo, el Departamento de Sistemas de Información, nos dedicamos a hacer software que solucione problemas al ciudadano, y muchas veces esto supone solucionar problemas también al personal municipal con el que los ciudadanos se relacionan.

Pero a veces se nos olvida cual es el fin último del trabajo propio. Últimamente he estado lidiando con un problema administrativo que me ha dejado claro, por si no lo tenía ya, lo ineficiente de la desconfianza, de las estructuras rígidas, y en último lugar, de los objetivos desalineados dentro de una organización.

Lo plantearemos como un caso de prueba:

When: Aitor necesita formación AND planea asistir al Greach en Madrid Then: Función Pública le tramita los viajes El tramite es indoloro y rápido. Given: Su jefatura, la Dirección y la Concejala responsables le han autorizado al respecto.

La prueba, como puedes suponer, da error. Analicemos las causas:

* Contexto de crisis. Se recortan los gastos, tanto que el transporte público es el transporte preferente. Parece que los aviones de líneas regulares no son transporte público, con lo que la alternativa desde Bilbao a Madrid es el tren (reseñado expresamente desde función pública). El problema es que el tren desde Bilbao tarda 5h. Sumando viajes y jornada el día no da de sí, con lo que hay que hacer noche, y si a esto le unes el hecho de que los horarios son limitados, resulta en dos noches en Madrid.

* El mecanismo de gestión no esta preparado para procesar esta entrada compleja; tan sólo sabe que el viaje TIENE que ser en tren. Amablemente le hago notar a la persona que me lo gestiona, que quizá el vuelo en el día sea hasta más barato que todo lo demás junto, por no hablar del número de horas que implica. (Nota: nunca sabré si todas esas horas de viaje se computan como horas trabajadas o similar; sospecho que no porque trabajo 7,5 al día y la jornada entre viajes y tal me supone de 6-23h).

Después del colapso que supone el intentar modificar el comportamiento por defecto de la administración (es totalmente Convention over Configuration y la configuración es difícilmente modificable), resulta que lo consigo. Me dan la razón, pero no se mueve "porque aún falta un més y sería una pena perder el billete". Vale, esperamos ese mes y resulta que el horario que tiene la agencia es salir a las 9 y volver a las 17. El evento es de 9:00 a 20:00, y ya que vamos procuremos asistir ¿no? Total, que me busco el billete (que me cuesta un poco más de la mitad que el oficial ¿WTF? ¿Para que hacemos los concursos?), y me conceden permiso para poder volar.

En resumen, horas perdidas y mucha bilis generada. ¿No podríamos eliminar este "waste"?

Conclusiones finales:

• Probablemente hace 20 años necesitábamos alguien que nos gestionase los viajes. Hoy en día son 5 minutos y google.
• Es necesario alinear los objetivos. El de Función Pública es no gastar dinero, el mío asistir. Seguramente algo como "Asistir gastando la mínima cantidad de dinero" valdría. Pero parece que eso no es posible, porque siempre se gasta la máxima cantidad. La desconfianza es ineficiente.
• Cualquier día de estos me borro. Y si no lo he hecho ya es porque soy un cobarde no muy eficiente. Quizá mi sino sea ser "funcionario". De momento soy desarrollador trabajando en la Administración Pública (o eso creo).

Hoy hemos celebrado el primer Katayuno itinerante (anteriormente habían sido sólo en Donosti-Hondarribia). Hemos tenido la suerte de disfrutar de las instalaciones de Eutokia, un sitio estupendo, y de la presencia de 18 katayuners dispuestos a todo por aprender un poco de TDD.

Tras una introducción sobre lo que se hace en Eutokia, nos hemos puesto manos a la obra. Primero una introducción sobre que son los Katayunos, las katas, el TDD. y después un par de iteraciones con la Kata StringCalculator, que es la que hemos considerado mejor para iniciarse. Finalmente hemos hecho una retrospectiva inspeccionando el código de uno de los participantes, y después del evento en general. En la parte positiva lo que hemos aprendido, el local y la cercanía. En la negativa, que no habíamos explicado bien los requisitos necesarios y algunos han perdido tiempo configurando el equipo, y que hemos aprovechado el tiempo "no muy bien", haciendo sólo dos iteraciones reales. Habrá que tomar nota para próximas ediciones. En fin, buen sabor de boca, y esperando al proximo.

Os dejo la presentación en slideShare:

En el año 2000, Joel Spolsky (fundador de Stackoverflow)escribió una entrada en su blog titulada "The Joel Test". Básicamente se hace 12 preguntas sobre cómo está tu proyecto de software. No es matemático, pero como el comenta, se hace en 3 minutos y te puedes hacer una idea (si no la tenias ya hecha). Hoy se me ha ocurrido hacerla con nuestros proyectos (la traducción es libre). Ahora que empezamos con los proyectos en Grails puede ser un buen momento para hacer este test, y ver la situación actual y a donde vamos:

• ¿Tienes sistema de control de versiones? Esta es fácil. La respuesta en nuestro caso es que si, antes CVS y ahora Subversion (pensando si no nos arrepentiremos de no pasar a Git). La cuestión es si lo usamos como es debido, porque no aprovechamos el potencial que nos da para hacer versiones y ramas como debiéramos .
• ¿Puedes construir tu proyecto en un paso? Va a ser que no. Es más, resolver las dependencias de un proyecto suele ser un proceso relativamente largo y manual, con lo que montar un proyecto en un puesto de desarrollo suele alargarse más de lo debido. Es algo que con los proyectos Grails solucionaremos, porque si tienen incorporada la construcción del proyecto.
• ¿Haces versiones diarias? Otra que tampoco cumplimos, en parte por no poder montar el proyecto en un paso. De nuevo con los proyectos desarrollados en Grails podríamos hacerlo más fácilmente, además el plan es montar un servidor de integración continua que nos permita desplegar automáticamente en el ambiente de prueba desde el repositorio.
• ¿Tienes una base de datos de errores? No es exactamente una base de datos de errores, pero tenemos un Redmine funcionando en el que se pueden reportar los errores, básicamente con toda la funcionalidad de un BugTracker tradicional. Como en otras ocasiones, la pregunta es si lo usamos tanto como debiéramos.
• ¿Arreglas los errores antes de escribir código nuevo? Depende de lo grave que sea. De todas maneras en este campo tenemos otros problemas, ya que no tenemos (habitualmente) baterías de pruebas automáticas. Con lo que introducir errores por regresión es algo relativamente fácil. Las razones de esto son culturales mayormente; la idea sería intentar potenciar las pruebas automáticas del software aprovechando las ventajas que Grails nos da, lo que nos proporcionaría mucho mayor control sobre nuestro software, apoyándonos de nuevo en el servidor de integración continua. La idea de todo esto es que cuanto antes detectes el error más fácil será de arreglar (recordaremos más detalles sobre el código en cuestión), con lo que ahorramos tiempo y dinero.
• ¿Tienes un plan puesto al día? Lo intentamos, aunque no es fácil. Esta claro que la planificación es importante, pero la adivinación no conduce a nada bueno. Lo interesante del asunto es tener clara una agenda y poder priorizar en función de los hitos previstos. Se supone que las metodologías ágiles te ayudan con esto, pero está por ver.
• ¿Tienes una especificación (escrita)? Solemos tener la especificación de las aplicaciones escrita, eso no es un problema para nosotros. El problema es cuanto se desvía el producto de esa especificación según va evolucionando el desarrollo, pero ese es otro problema.
• ¿Tienen los programadores condiciones de trabajo silenciosas? No mucho, la verdad. Vamos a dejarlo ahí.
• ¿Tienes las mejores herramientas que el dinero puede pagar? No, pero en esto Joel juega en otra división.
• ¿Tienes probadores? No tenemos probadores dedicados, más alla de otro miembro del equipo que hace esa labor.
• ¿Los candidatos escriben código durante su entrevista (de trabajo? No depende de nosotros, de nuevo Joel juega en otra división.
• ¿Tienes pruebas de usabilidad? No exactamente, pero si hay gente dedicada a mejorar la usabilidad sobre todo de la web corpotativa. Aún así, se puede mejorar mucho en ese terreno.

Se supone que con menos de diez respuestas afirmativas tienes problemas. Aunque eso ya lo sabíamos, y estamos trabajando para mejorar.

Si eres de los que te gusta el TDD, no te puedes perder los videos de Sebastian Hemida al respecto: holaTDD.com Y si eres de los que lo  les gusta el TDD ¿a que esperas para empezar? Porque seguro que no lo has probado... ;) http://www.holatdd.com/videos/minesweeper