La Coctelera

Quiero ser Bruce Springsteen

No es un secreto. Me encanta Bruce. Además de su música, sus letras, el inglés que me ha enseñado, que tiene una canción para todos los momentos y que me he hecho mayor escuchándole, lo cual me devuelve a la adolescencia cada vez que escucho sus canciones, resulta que es un profesional como la copa de un pino.

Me lo recordado esta entrada, aunque en realidad no me hacía falta. Hace poco ha estado en Donosti, con más de tres horas de concierto inolvidable (como todos). Pero la semana siguiente bate su record en Milán, y lugo en Madrid... tiene 62 años, supongo que más pasta de la que voy a ver nunca, pero tiene un problema. Resulta que le gusta tocar, le gusta su trabajo (por algo lo eligió) y no se cansa.

Eso es lo que quiero. Disfrutar con mi trabajo ya que voy a pasar con él muchas horas. Como Bruce. Supongo que el secreto está en trabajar en lo que te gusta, y no al revés.

Algunas veces me dicen en la oficina "es que a ti esto te gusta" como si fuera hacer trampas. Hacerte trampas es escoger un trabajo que no te gusta y pasarte con el 40 años. Eso es hacerte trampas. Haz algo que te guste y no trabajarás más. Bueno algún día seguro que si, todos tenemos días mejores y peores, pero será distinto. Si tu empresa no cumple los requisitos, cámbiala. Si no es posible (que lo dudo), cambia de empresa. Si es el campo al que te dedicas, cambia de campo. Es fácil de decir, y difícil de hacer, pero creo que te merecerá la pena.

En realidad todo esto me lo estoy escribiendo a mi mismo. Piénsatelo, y si no merece la pena, cambia. Igual ganas menos, trabajas más horas, pero seremos más felices. Prueba y a ver que pasa ;)

BilboStack 2012

Los chicos de webDevBilbao, junto con PlainConceptsSimettric y la colaboración de la Universidad de Deusto se han liado la manta a la cabeza y ahn organizo el BilboStack Developers Conference. En una mañana, 10 charlas en dos tracks con lo mejor de los desarrolladores de por aquí. Además me han dejado hablar a mi sobre "Programación Extrema". Un montón de gente conocida, intercambio de opiniones y puntos de vista, y en mi caso una huida temprana por compromisos familiares.

Este tipo de eventos siempre son bienvenidos, y si es al lado de casa, más. Aunque creo que el nivel de los ponentes era muy alto, resulta que a algunos les a parecido que mi charla estuvo bien (ya ves, hay gente para todo). Es curioso que preparé una presentación, pero como veía que no aportaba nada más que un guión para mi, la deseché, y salí a hablar con un puñado de tarjetas en la mano. A algunos eso les ha parecido "vintage", mientras que otros me dan un diez e incluso creen que lo hice "como los machos". Simplemente creo que era lo mejor, lo malo es que ahora no tengo presentación para poner aquí (jaja),  aunque creo que si que se publicará un video, y tengo unas notas que escribí por si quieres saber más sobre la programación extrema.

Un asistente me preguntó cuanto de lo que había contado aplicaba en el día a día. La respuesta es todo, auqnue con matices. Evidentemente no todas las técnicas las domino perfectamente, y siempre no se puede conseguir todos los medios deseados, pero en cierta medida lo aplico todo: Tdd, integración continua, diseño simple, pruebas automaticas, historias de usuario... pero la idea principal no es esa, sino que revises como lo haces, pruebes cosas nuevas y te quedes con lo que te funciona, siempre con espíritu de mejora continua, que es lo que te llevará a hacer mejor software.

PD: A este le gusto, y este otro me pone un diez.

Actualización: Ya está disponible el video gracias a Fran Mosteiro:

Spring I/O 2012

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 ;)

Actualización 05/06/2012: Se ha publicado el video

Plain concepts en el WebDevBilbao

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.

Global Code Retreat 2011

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.
Gracias a Plain Concepts por el local, a Vicenç García Altés por organizarlo y a Jorge Uriarte por facilitarlo.
Actualización: No he mencionado apenas que era a nivel mundial, en 90 ciudades, con más de 2000 personas participando... supongo que Corey Haines estará encantado...

Refactoring Vs Reengineering

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.
Pero aún así, es mucho mejor que la certeza de que no tienes ni idea de si funciona como antes sin hacer una prueba manual. O mejor dicho, tienes la certeza de que algo irá mal, por eso lo pruebas, porque no eres perfecto y cometes errores. Y además esas pruebas estarán ahí en el futuro para seguir haciendo tu código más robusto.

Waste

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

Katayuno en Bilbao

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: