Conclusiones del Code Retreat

Un poco más descansados después del fin de semana "corto" vamos a contar algunas conclusiones del Code Retreat del sábado.

El grupo En primer lugar queremos decir que fue un placer programar y discutir con todos los participantes del evento. Se dice que vale más un voluntario que cinco mercenarios y claramente las personas que participan de un evento que arranca a las 8:30 de un sábado entran en la categorías de voluntario.

Además todo el grupo tenía un nivel técnico muy interesante y mucha energía para participar. Los Code Retreat son eventos cuya calidad depende casi exclusivamente de los participantes (como el desarrollo!...) y creo que tuvimos mucha suerte en ese sentido.

Lo - Estuvimos pidiendo feedback a los participantes y por el lado de lo negativo todos estuvieron de acuerdo con que el horario fue medio cruel. La verdad es que no sabíamos como se iba a desarrollar el evento y teníamos miedo de que se estirara hasta muy tarde si no empezábamos temprano pero cuando lo repitamos vamos a empezar más tarde (a las 9 menos cuarto ;) ).

Lo + Por el lado positivo a muchos les gustó la rotación de los pares. Creemos que eso es una parte fundamental del ejercicio ya que así es como se van diseminando las buenas ideas entre todo el grupo. No es casualidad que este mismo efecto se menciona como una de las ventajas de usar Pair Programming en un proyecto de desarrollo.

Alguién mencionó que le había gustado el consenso al que se llegaba en la solución usando Pair Programming. Esta es otra característica interesante de PP, no hay decisiones tomadas por una sola persona.

También recibió varias menciones positivas el hecho de borrar el código entre las iteraciones. Esto es muy interesante porque fue una de las cosas que más resistencia generaba al principio del evento. Ser capaces de eliminar y escribir de nuevo código con el que no estamos conformes es una habilidad importante, permite encontrar soluciones mejores y no quedar atados a la primera que se nos ocurre. Fue muy bueno haberla podido ensayar en el Retreat.

La práctica de TDD fue bien recibida. Llamó la atención como la elección de los tests lleva a distintas soluciones y también como los tests sirven como indicadores de la calidad del código (si nos cuesta escribir tests probablemente tenemos un problema de diseño en el código que queremos testear).

Sugerencias Hubo varias sugerencias para próximas versiones, con las que estamos totalmente de acuerdo:

• Hacer más corto el evento (creemos que probablemente la demo final estuvo de más),
• No borrar el código si no que en cada iteración una pareja toma el código dejado por otra y sigue desde ahí (es otro tipo de ejercicio pero parece muy interesante)
• Hacer una retrospectiva final (la verdad es que esto estaba previsto pero nos olvidamos!!!. De todas maneras se había hecho un poco largo y ya estábamos todos muy cansados).

Agradecimientos Para terminar queremos decir que estamos muy contentos por haber podido llevar a cabo esta iniciativa. Queremos agradecer a Pragma por el sponsoreo y muy especialmente a todos los participantes que fueron los que realmente llevaron adelante el evento.

Primer Code Retreat Argentina

Este sábado 24/04 organizamos el primer Code Retreat de Argentina, en Buenos Aires. Fue una experiencia muy interesante que nos dejó muy conformes!

El objetivo de este Code Retreat fue familiarizarse con prácticas de Extreme Programming como Pair Programming y Test Driven Development (TDD).

Lo que hicimos fue trabajar en sesiones de 40 minutos, cada una de los cuales consistió en que los participantes intentaran resolver un problema de programación, trabajando de a pares y utilizando TDD. Una vez terminada cada sesión hicimos una retrospectiva de 15 minutos para reflexionar sobre los problemas encontrados y los distintos formas en que cada par había encarado su solución del problema. Después de la retrospectiva se cambiaban los pares, se borraba el código y se iniciaba una nueva sesión atacando el mismo problema.

De esta manera se realizaron 5 iteraciones y por ultimo, una 6ta iteración, en la que realizamos una demostración de un intento de solución del mismo ejercicio del Retreat.

Un punto aparte a destacar es la buena onda y el esfuerzo de todos los concurrentes en participar de un evento un dia no laboral. La integración y la comunicación crecieron en conjunto, iteración tras iteracion.

Los Participantes del primer Code Retreat fueron:
Claudio Meschini
Mario Del Lago
Hernan Vitto
Alejandro Miralles
Fernando Claverino
Gabriel Naiman
Damian Aberbuj
Emanual Teodoro
Amit Stein
Javier Andres Cengia
Matias Nicolas Blanch
Juan andres Knebel
Nicolas Bases
Augusto Bellucci
Claudio Vidau

Tambien agradecemos a Pragma, el Sponsor del evento.

Les dejamos algunas fotos del encuentro y vamos a realizar un post más completo cuando tengamos más feedback de los participantes y escribamos nuestras conclusiones.

Code Kata

Es un hecho conocido que hay grandes diferencias de productividad entre un programador y otro.  Según algunos estudios los mejores programadores son entre 10 y 20 veces más productivos que los peores. Otros estudios hablan incluso de una diferencia mayor, sobre todo teniendo en cuenta que hay programadores que tienen productividad negativa
(ver http://www.pyxisinc.com/NNPP_Article.pdf).

Si esta diferencia se debiera solo a motivos de talento personal no podríamos hacer nada al respecto. Sin embargo, todos los buenosprogramadores atribuyen buena parte de su éxito a ciertas habilidades y hábitos que fueron adquiridos por ellos en algún momento y que les permitieron potenciar su talento natural.  Kent Beck (el autor de jUnit) afirma "Yo no soy un programador sobresaliente, soy un buen programador con hábitos sobresalientes".

Se tiende a pensar que estos hábitos se adquieren a través de la experiencia en el trabajo diario. Sin embargo las presiones y conflictos de un proyecto de software hacen que sea un pésimo lugar para aprender cosas nuevas. Para que un entorno facilite el aprendizaje es necesario que sea aceptable cometer errores, y esto no es así cuando estamos desarrollando software para alguien que nos paga por eso. Cuando tenemos presiones, tendemos a ser cautelosos y hacer las cosas como las hemos hecho antes, lo que causa que no aprendamos nada.

Además sería injusto para nuestros clientes utilizarlos de conejitos de India para probar nuevas técnicas o metodologías.  Dave Thomas dice al respecto: "En desarrollo de software aprendemos en el trabajo y por lo tanto nos equivocamos en el trabajo. Hay que buscar una manera de separar el aprendizaje del trabajo profesional. Necesitamos ensayos".
Por lo tanto, si queremos mejorar nuestras habilidades, hay que encontrar un espacio distinto al trabajo diario para hacerlo.

Esta idea es el origen de los Code Kata. Este concepto fue copiado de las artes marciales en las cuales una kata es un conjunto de movimientos que los estudiantes repiten hasta internalizarlos y lograr realizarlos de manera automática.  Las katas se hacen sin oponentes y su único objetivo es mejorar la técnica.  Es algo asi como, si recuerdan la pelicula Karate Kid,  cuando el señor Miyagi mandaba a Daniel-san a pulir los autos para mejorar su técnica de defensa...

Como es un Code Kata? Es un ejercicio corto (entre 30 minutos y una hora), que se intenta resolver tantas veces como sea necesario. Lo importante no es encontrar una solución sino la forma en que la buscamos. Esto es exactamente lo contrario de lo que pasa en el trabajo diario, donde lo fundamental es lograr una solución.

Después de cada intento buscamos feedback y analizamos posibles mejoras en nuestra forma de resolverlo. No buscamos solo mejores soluciones al problema sino mejoras en nuestro método de resolución. La manera óptima de conseguir feedback sería que otra persona nos observara y nos indicara las cosas que le parece que podríamos mejorar (este es el rol del sensei en las katas de artes marciales). Como esto es dificil de conseguir, otra posibilidad es utilizar algún software que capture la pantalla mientras resolvemos el problema de manera de poder después nosotros mismos buscar oportunidades de mejora.

Hace un tiempo hice un experimento con esta técnica, tomando como ejercicio escribir de cero un ABM simple en Rails . Repetí 18 veces la kata y cada vez capturé la pantalla mientras lo hacía y busqué oportunidades de mejora. Fue un ejercicio fantástico y fui mejorando muchos aspectos, desde cuestiones de entorno y herramientas hasta aprendizaje de nuevas librerías, pasando por profundizar el conocimiento del framework. En definitiva pude hacer una instrospección de como estaba haciendo mi trabajo y mejorar las cosas que no me gustaban.

Para tener una idea de cuanto fui mejorando, la primera vez que hice el ejercicio me llevó 45 minutos, mientras que la última pude hacerlo en menos de 15, comenzando desde cero cada vez,  logrando al mismo tiempo mejores resultados.

En definitiva, creo que es una técnica muy importante. Para aquellos que quieran probarla les recomiendo esta página de Dave Thomas donde
hay una lista de 21 ejercicios propuestos: