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