CodeRetreat en Bodegraven

Introducción

El otro día fui a un coderetreat en fort wierickerschans (no me preguntes como se pronuncia porque no tengo ni idea), en Bodegraven y la verdad es que me lo pasé fenomenal.
Como podéis ver en la foto de arriba, el sitio es precioso y toda la zona merece al menos un paseo para conocerla.

Qué es un coderetreat

Un coderetreat, como dicen en su página web, es un evento que dura todo el día y en el que desarrolladores se juntan para practicar sus habilidades.

El evento se divide en sesiones donde los desarrolladores se juntan en parejas para resolver un problema utilizando Test driven development* y en el lenguaje de programación que hallan decidido entre ambos.

Después de cada sesión hay una retrospectiva sobre cuales fueron los problemas que se han encontrado y como se han intentado solucionar.

El problema es siempre el mismo, el juego de la vida de Conway, pero en cada nueva sesión se van cambiando las restricciones, como por ejemplo, el no poder hablar con tu pareja o el hacer commits de menos de 2 minutos o el no poder retornar valores en los métodos (esta última tiene tela).

El creador y promotor de los coderetreat es Corey Haines y si no lo conocéis deberíais de hacerlo. Los facilitadores del evento nos comentaron al final que Corey quería poner su granito de arena en el evento y nos regaló su libro Understanding the Four Rules of Simple Design, que tiene muy buena pinta.

El evento

Este evento congregó a 45 desarrolladores, donde se encontraba gente de todos los niveles, desde gente veterana a jóvenes sin casi experiencia.

Los facilitadores del coderetreat fueron Stefan Hendriks y Bart Bakker. También creo que fueron los organizadores del mismo junto con Blue4IT.
Tuve que hacerles varias preguntas en las sesiones y me ayudaron mucho a encaminar las sesiones.
Stefan va a estar libre en Octubre a si que si necesitáis algún desarrollador Java o Ruby no dudéis en contactar con él.


La comida estuvo a cargo de Blue4IT y fue muy completa. Nada de pizzas para todos, sino que había todo tipo de comidas: hamburguesas, ensaladas, gambas, todo tipo de salsas y un largo etcetera.

También recibimos un regalo de ellos: un paraguas que aguanta fuertes vientos. Porque no debemos olvidemos que estamos en Holanda :-)

En cuanto a mí, en todas las sesiones programé en Java y en todas y en cada una de las sesiones me divertí y aprendí cosas nuevas.

Ideas

Algunas ideas que me surgieron a partir del evento:

• Todos en el evento hablaban en Holandés excepto yo. "Gracias" a mi el evento fue en inglés en vez de en holandés. Naturalmente, a nadie le molestó ni tuve ningún problema al respecto pero creo que a la larga es importante que aprenda holandés para estar mas metido en la comunidad.
• Me extrañó que con la cantidad de gente que había ninguno quería programar en Javascript conmigo. La mayoría eran desarrolladores principalmente en Java. Parece que si te gusta Java no te puede gustar Javascript.
• Unos cuantos me comentaron lo que mola Scala y la verdad es que entraron ganas de probarlo.
• No solo se aprende programando, sino que aprendí mucho en las conversaciones con la gente. Creo que la gente está más predispuesta a hablar de forma sincera en este tipo de eventos.

Retrospectiva

Al final hicimos un retrospectiva intentando responder a tres preguntas relativas al coderetreat, y estas fueron mis respuestas:

• ¿Qué es lo que me ha sorprendido?

Lo que más me ha sorprendido es lo divertido que es programar en pareja cuando tienes experiencia con TDD. La primera vez que fui a un coderetreat no la tenía y no fue ni la mitad de divertido.

• ¿Qué es lo que he aprendido?

He aprendido muchas cosas, pero creo que la más importante es lo importante que es que el test unitario sea fácil de entender.

Me dí cuenta de esto cuando estábamos en la sesión en la que no podíamos hablar con nuestra pareja.

• ¿Qué es lo que voy a hacer diferente el lunes?

Hacer commits más pequeños.

Algunas fotos del evento aquí y para finalizar una foto (gracias a Derk Dukker) en la que aparezco :-)

(*) No es necesario practicar o tener cierta experiencia con TDD para disfrutar del evento.

La primera foto es de Projectenbank Cultuurhistorie y las demás son de Michel van Dongen, el director de Blue4IT.

Por qué escribir test unitarios

El otro día leí un artículo de Gil Zilberfeld sobre la economía de los test unitarios.
En la siguiente dirección podéis encontrar un enlace a su blog:

http://www.gilzilberfeld.com/2014/09/the-economics-of-unit-testing.html

Básicamente lo que quiere decir el artículo es que:

Escribir test unitarios te permite ganar dinero

Así de simple.

¿Y cómo lo hacen? De la siguiente manera:

• Escribir test unitarios hace que el tiempo en liberar cada versión se reduzca
• Si el tiempo en cada versión se reduce, puedes vender tu producto y las nuevas funcionalidades antes. 
• Además el números de errores (bugs) se reduce por lo que podemos dedicar más tiempo a nuevas funcionalidades.

Pero, ¿cómo puede reducir el tiempo en liberar cada versión? Muy fácil, porque aunque el tiempo dedicado al desarrollo aumenta, el tiempo dedicado a pruebas (testing) se reduce drasticamente.

Tengo que decir que, en mi experiencia, escribiendo test unitario he reducido mucho el tiempo dedico a probar a pruebas. Además, también he comprado que el número de errores se han reduce considerablemente. Por lo que ambas afirmaciones son ciertas.

Claro que hay que dedicar tiempo al principio a aprender como escribir test unitario pero en cuanto el equipo aprende vamos a conseguir los beneficios que he comentado anteriormente.

En resumen y como dice el autor del blog:

Unit testing shortens the current and future release cycles at the expense of initial extra development work.

Los test unitarios reducen el actual y futuros ciclos de liberación de versiones, a costa de un trabajo extra inicial de desarrollo.

El por qué de este artículo

Como te debes haber dado cuenta, me he dedicado hasta aquí a resumir el artículo de Gil Zilberfeld, pero la idea de este artículo es otra.

Creo que si queremos "vender" a nuestros compañeros, jefes o amigos el por qué debemos utilizar test unitarios esta es la mejor forma de hacerlo.

Primero, porque estamos utilizando un lenguaje que todo el mundo entiendo. 

Y segundo, porque al fin y al cabo nosotros estamos trabajando por dinero y el dinero es un lenguaje que todo el mundo entiende.

Por otro lado, si sólo quieres empezar a escribir test unitarios no necesitas pedir permiso a nadie. Puedes empezar hoy mismo a hacerlo. A la larga verás como fue una buena decisión.

* Modificado 12-09-09: Corregidos algunos errores gramaticales

Comentando el libro "Sentimientos, pensamientos y realidades" de Koldo Saratxaga

Introducción

Estuve viendo los vídeos de la Conferencia Agile Spain del 2013 y me gustaron muchas charlas pero la que más me impactó fue la de Koldo Saratxaga.

Su charla fue especial porque aunque todo lo que decía tenía que ver con el mundo Agile él viene de sectores no relacionados con el desarrollo de software.
Así que empecé a buscar información sobre él hasta que llegué a K2K emocionando y a sus libros:

http://loslibrosdek2k.com/

Así que me descargué uno de ellos, empecé a leerlo y me ha encantado.

Sentimientos, pensamientos y realidades

El título del libro son los estados por los que pasa una persona que se mueve por la vida con pasión:

Primero siente (desde las tripas), luego piensa y finalmente actúa.


Cada capítulos del libro se divide en estos tres conceptos junto con realizaciones.
Así primero se explica una idea (sentimientos), luego se desarrolla (pensamientos), posteriormente las acciones (realidades) y finalmente un caso práctico (realizaciones).

Alguna ideas

Las principales ideas que he leído del libro y que para mí eran nuevos son:

• Todas las personas son diferentes => Campana de Gauss
• Las empresas tienen que pensar a largo plazo y para ello necesitan la innovación => Cultura de futuro
• Las personas son innovadoras ya que son las que tienen las ideas. Así que el mayor activo de una empresa son las personas que trabajan en ella
• Los números tienen un valor instrumental
• Todas las personas han de conocer la cuenta de resultados, los conceptos económicos y comprender lo que significan. Ejemplo del partido de baloncesto
• Hacer partícipes a las persona de la empresa: reparto de beneficios, reparto de pérdidas, toma de decisiones importantes en junta, rangos salariales planos (no mucha diferencia de sueldos entre jefes y empleados) y equipos auto organizados 
• Traducir la cuenta de resultados y el balance contable a un lenguaje comprensible para todas las personas y enseñar a todos lo básico de Economía
• Confianza en el líder: requiere comunicación y transparencia
• Hablar de sentimientos en las reuniones de gestión del cambio

A continuación voy a explicar algunas de las ideas, principalmente las que más me han gustado.

Campana de Gauss

Aunque la campana de Gauss es una función matemática el autor la utiliza como analogía para decir que en la empresa se trata a todas las personas de la misma manera aunque todas son diferentes.

Si todas las personas son diferentes e incluso cada día somos de una forma, según nos sintamos felices, tristes, cansados o con otro ánimo ¿por qué tratar a las persona de la misma manera?

Una de las frases que más se repite en el libro es que todas las personas son diferentes y creo que es parte fundamental del cambio de mentalidad que se propone en el libro.

El mayor activo de una empresa son las personas

Esto es algo que se suele decir en todas las empresas pero que no suele ser verdad.
Lo bueno en el libro es que explican el por qué y el cómo conseguir lo mejor de cada persona.

No se puede competir con otras empresas reduciendo costes, ya que los países emergentes tienen las mejores tecnologías y procesos ya que otros países los han introducido ahí para abaratar coste.
Así que la única manera de competir es a través de la innovación, y la innovación viene de ideas y las ideas las tienen la personas.

Por lo que necesitamos las personas para competir ya que son las que pueden innovar.

Según el autor: "sólo las personas libres de pensamientos y llenas de ilusiones pueden lograr las ansiadas innovaciones"

¿Y cómo se consiguen personas libres de pensamientos y llenas de ilusiones?
Creo que aquí no hay una única respuesta ya que como comenté al principio todas las personas somos diferentes por lo que cada persona puede ilusionarse por cosas diferentes y sentirse libre debido a hechos diferentes.

Personalmente todas las acciones que llevan a hacer partícipes a las personas de la empresa son las que me han conseguido ilusionar cuando las he leído. ¿A tí que te ilusionaría o ilusiona para darlo todo en tu empresa?

Todos deben conocer el estado actual de la empresa

Todos deben de conocer el estado de la empresa porque, como comentaré en la historia del equipo de baloncesto, necesitamos saber la relación entre el trabajo realizado y el resultado obtenido.

Y para que todos conozcan el estado de la empresa enseñan Economía a toda la gente de la empresa y traducen la cuenta de resultados.

Traducen la cuenta de resultados a un lenguaje simple para que cada persona pueda ver en que afecta su trabajo a la cuenta de resultados.

Equipo de Baloncesto

El equipo de baloncesto se utiliza como ejemplo de porque todos tienen que conocer la cuenta de resultados de la empresa y que esta tiene que estar visible durante el año.
El texto donde se explica es el siguiente:

"Imaginaos un partido de baloncesto en el que los equipos juegan todo el tiempo sin marcador y que sólo al final de partido se supiera el resultado.

Jugar en estas condiciones sería complicado y seguramente se resentiría la efectividad y la motivación de los jugadores, pues no sería posible encontrar la relación directa el juego realizado y el resultado obtenido.
Algo parecido pasa en las empresas tradicionales: el resultado del partido (la cuenta de resultados) sólo se conoce después de meses de finalizar el año"

Mis conclusiones

Si me tengo que quedar con una idea en el libro es: todas las personas son diferentes.
Otra idea que me ha encantado es que el mayor activo de una empresa son las personas porque son las que pueden innovar.

Todas las ideas y acciones que se comentan en el libro son buenas pero lo que las hace fantásticas es que salen de la experiencia ya que se han utilizado en muchas compañías, en diferentes sectores y en diferentes países.

Una cosa extraña que me ha pasado leyendo el libro es que me ha empezado a interesar la economía porque todo lo que se comenta sobre la cuenta de resultados. Si alguien tiene alguna recomendación de algún libro, curso o  recurso que me permita entender lo básico de economía soy todo oídos.