Sprint en Londres, segunda parte

El jueves fue un día distinto, porque en lugar de ir a la sala de conferencia del hotel como hasta ahora, pasamos el día trabajando en las oficinas de Canonical de Londres.

Canonical tiene todo el piso 27 en la torre Millbank, lo que hace que la vista sea interesante....

Vista desde la oficina

Durante el día nos dividimos en tres grupos, y la actividad fue más de aprovechar la oportunidad de que estábamos todos cara a cara para atacar algunas situaciones y decidir qué íbamos a hacer con determinados temas. Laburar distribuidos está bueno, pero estar en la misma habitación y poder utilizar un pizarrón facilita muchísimo algunas charlas.

Mi grupo en particular terminamos de ajustar algunos detalles en un cambio importante que se viene para el cliente de Ubuntu One (Generations), y a la tarde estuvimos entendiendo Cassandra y tratando de ver si nos sirve, y cómo nos sirve.

A la noche el plan era ir a comer pizza a un lugar que estaba al ladito del hotel, pero nos dijeron que la calidad no era la mejor, y nos recomendaron una pizzería estilo italiana que estaba (como ya era costumbre), a más de media hora de paseo. Como a esta altura ya no nos importaba si caminábamos mucho o poco, decidimos ir igual, y la decisión fue acertada, la pizza estaba rica, y el lugar era interesante, con mozas italianas, y un estilo sencillo y sin pretensiones.

Pasear por el soho de Londres un jueves a la tarde no era sencillo: había mucha gente. Especialmente en los bares, y no precisamente adentro de los mismos, porque es costumbre que la gente compre la cerveza y salga a la calle a tomarla. Incluso esto es favorecido porque los bares arman pequeñas barritas donde la gente puede apoyar los vasos, así que cada vez que uno pasaba por un pub (¡y no es que haya pocos!), había una marea de personas tomando y charlando en toda la calle.

Vida nocturna

Incluso después de cenar, cuando volvimos caminando al hotel (con un par de vueltas incluidas porque algunos querían tomar un helado), siendo alrededor de las once de la noche, las calles estaban bastante llenas y activas. Esto fue una grata sorpresa, especialmente luego de pasear en Bélgica y ver que te cierran todo tempranísimo.

El viernes era el último día, y ya se notaba demasiado el cansancio general. La mañana fue de charlas normales, así como parte de la tarde. Completamos el día con un ejercicio de qué nos había gustado (y qué no) durante la semana, como para mejorar la organización a futuro, y volvimos al hotel ya que seis y media partíamos para una cena grupal de todo el equipo. Esto era en un lugar también estilo italiano, pero de comidas varias, las cuales estaban muy bien (pedí un vitello tonello de entrada, y unos spaghettis con almejas de primer plato, sin segundo plato, y sólo un limoncello de postre), aunque realmente el lugar en sí no era piola: no estaba preparado para que vayamos alrededor de treinta personas, estábamos todos demasiado amontonados, y el nivel de ruido era muy alto.

Así que aunque no puedo decir que no lo disfruté, cuando el primer grupo decidió arrancar de vuelta, me sumé al mismo. Volvimos en taxi Lucio, Rodrigo, Naty y yo. Muy locos los taxis ingleses, porque tienen mucho espacio atrás, con el asiento mirando para adelante puesto sobre el espacio del baúl, y asientos mirando para atrás contra el conductor, con lo cual van cinco personas cómodas sentadas unas frente a otras.

Cena grupal

Lucio se tenía que ir a lo de su hermana, porque a la madrugada partían de vacaciones, así que estuvimos charlando en nuestra habitación mientras él preparaba las cosas. Luego me fui a la habitación de Naty, que se sentía súper mal del estómago y le hice el aguante porque estaba viniendo una amiga de ella desde Madrid, la cual debía llegar tipo once de la noche, pero le fueron retrasando el vuelo y terminó llegando a Londres pasadas las tres de la mañana. Así que mientras Naty trataba de dormir y aguantar los retorcijones, yo me quedé atento a su celular para ver cuando llegaba la amiga y programando algo que había empezado esa misma tarde y quería terminar pronto: recorrí el directorio de Canonical (en donde están listadas las personas con datos como nombre, foto, equipo, posición, etc.), y armé un organigrama gráfico. Para esto me tuve que autenticar por OpenID al sitio interno de Canonical, ir bajando todas las páginas HTML, extraerles la data, armar un archivo DOT a mano el que luego se usa para generar el organigrama en sí en formato SVG, y al que luego abro y le meto las fotos de las personas sobre la cajita con nombre y posición. Todo hecho desde Python, por supuesto, :)

Finalmente esta chica llegó, así que cerca de las cuatro de la mañana nos tomamos un taxi con Naty para irla a buscar a la estación de tren. La esperamos un par de minutos y volvimos al hotel, en donde me encontré con Guillo fumando afuera del hotel. Las chicas subieron a acostarse, y yo me quedé contándole a Guillermo lo del organigrama (ya le había comentado algo a la tarde porque le había pedido ayuda con lo de OpenID). A los cinco minutos subimos, y al sobre.

Pensé que el sábado me iba a costar horrores levantarme, pero no. Puse la alarma a las diez, pero a las nueve ya estaba despierto. Acomodé algunas cosas, bajé a desayunar, volví a la habitación y terminé de armar las valijas y me pegué un baño. Llevé las cosas a la habitación de beuno (después verán por qué) y bajé a hacer el checkout.

Enseguidita partí hacia el London Eye al que Naty y amiga habían ido más temprano, y de ahí nos fuimos a pasear por la zona del Tower Bridge, uno de los puentes más famosos del río Támesis. Naty se seguía sintiendo mal pero pudimos pasear sin drama, hasta que volvimos al hotel que era la hora del partido.

Puente de la Torre

Nos juntamos un grupito de cinco o seis en la habitación de beuno, donde comimos algo, tomamos unos mates, y vimos el partido (perdimos, bú). También seguí laburando con eso del organigrama, hasta que se hizo la hora de partir. Alecu y yo dejamos a los chicos convenciendo a Naty que tenía que llamar a un médico, y arrancamos hacia el subte, luego hicimos combinación con el tren, y llegamos bien cómodos en tiempo al aeropuerto.

Esperas habituales, controles de seguridad, vuelo muy largo (¡qué bien que se come en British Airways!), pero dormí bastante, y llegué a casita con la familia, a la que extrañé un montón.

Las fotos de todo el sprint, acá.

Comentarios Imprimir

Sprint en Londres, primera parte

Con motivo de una reunión de equipo (¡toda la gente de Online Services de Canonical!) arranqué para Londres el sábado a la mañana.

El avión salía al mediodía, así que preparé todo la noche anterior, de manera de levantarnos y salir, ya que Mónica y Felipe me llevaban al aeropuerto. Parte de la preparación de la valija fue más complicada... quise llevarme a Felu, pero al final me hicieron desistir...

Felipe en la valija

El vuelo estuvo muy bien, viajé con Martín y Alecu. Fue largo (16 horas en total), pero Martín (beuno) se cambió de asiento y nos charlamos todo hasta que el avión hizo la escala en San Pablo, donde se acercó Alecu y seguimos charlando. El segundo tramo, considerablemente más largo, lo distribuí entre charla, ver una peli, programar algo, y dormir algunas horas.

Aterrizamos el domingo tempranito, y mediante tren y subte llegamos al hotel un rato antes de las diez de la mañana. Hicimos el check-in, pero no teníamos habitación disponible todavía, así que nos fuimos a la habitación de Naty (que había llegado la noche anterior) y nos bañamos ahí.

Enseguida arrancamos con Naty y Alecu para Camden, una zona de Londres que es un mercado callejero grande, y estuvimos paseando como cuatro horas, viendo cosas, comprando algunos souvenirs, almorzando, etc.

Camden

A media tarde nos tomamos un bondi y nos acercamos a la zona de Picadilly Circus, donde nos encontramos con más gente. Entramos a un negocio de ropa deportiva porque Naty y Alecu querían comprar un par de cosas, pero me terminé comprando unas medias y un pantalón largo para jugar al tenis. Luego fuimos a una librería, y finalmente a una juguetería inmensa, de tres pisos, donde tenían absolutamente de todo.

Volvimos al hotel con el tiempo exacto como para organizarnos para ver el partido de Argentina con México. La idea era cenar mientras mirábamos el partido, pero al final se juntó tanta gente en la habitación que sólo nos tomamos unas cervezas, y comimos después.

El lunes arrancamos bien temprano, y a las nueve estábamos en el piso -4 de otro hotel cercano, donde teníamos las salas para trabajar. Era un día sin laptops, con presentaciones y charlas toda la mañana. Después del almuerzo participamos en un juego en el que varios equipos recorrían la ciudad tratando de encontrar respuestas a unos acertijos. Mi equipo (y otro más) fallamos totalmente, porque leímos mal las instrucciones y arrancamos en otro punto y no donde debíamos, lo que hacía que la primer adivinanza fuese imposible de resolver. Igual nos divertimos, y caminamos como tres horas.

El juego terminaba en un bar, donde tomamos algo, y volvimos al hotel a eso de las siete de la tarde. Laburamos un rato en distintas cosas, mientras tomábamos unos mates, y luego partimos (¡caminando!) a un restaurant chino que quedaba como a 30 cuadras, pero lo valía: comí cosas raras y ricas. Volvimos caminando (sí, de nuevo) al hotel, pero en el medio paramos para tomar un helado, :)

Cenando chino

Al otro día también fuimos al otro hotel a trabajar, pero en esta oportunidad llevamos las laptops, y laburamos en distintos proyectitos de dos horas de duración cada una. La idea era meterle mano a distintas tecnologías para que todos las conozcamos más allá de la teoría (aunque no todos vayamos a laburar en ellas todo el tiempo). Lo que más me gustó fue usar CouchDB desde Python, y también trabajar con AMQP.

Luego de las seis volvimos al hotel pero en seguida partimos hacia un picnic donde iba a estar mucha gente de la empresa. Paramos en el medio a comprar algo de morfi en un supermercado, y llegamos luego de caminar como una hora (sí, seguimos caminando...). El picnic estuvo bien, y hasta jugamos un rato al fútbol en algo súper caótico que incluía a más o menos veinte varones y cuatro mujeres de los cuales un 4% sabía algo de fútbol, en una canchita provisoria armada entre los árboles...

Luego volvimos (nuevamente caminando) al hotel, me pegué un baño y me fui a la habitación de Naty, donde nos pusimos a armar una presentación que teníamos que dar al otro día. Pensamos que iba a ser sencillo y rápido, pero terminamos trabajando hasta las dos y media de la mañana :(, así que al otro día no podía despertarme para nada.

Encima el miércoles también era día sin laptops, así que eran todas presentaciones y charlas, y aunque había algunas interesantes, en otras no podía evitar cabecear del sueño. Con Naty dimos la lightning talk de Magicicada que habíamos armado, y también yo dí una cortita de Logs.

El día no ofreció mucho más, laburamos hasta tarde, cenamos, y a dormir!

Comentarios Imprimir

Todo roto, todo

Consejo: Nunca traten de upgradear el sistema operativo de un VPS que tienen contratado.

No funciona, por cosas que van más allá del OS en cuestión (uno de los detalles que ví en el mío, es que el /boot está vacío... nunca puede andar, :p).

¿Cómo lo sé? Porque lo intenté, e hice crema mi server.

Tenía backup, pero sólo de los datos. Esto significa que aunque tenía copias de lo más importante y realmente valioso, volver a hacer funcionar todo me llevó varias (varias) horas de trabajo de instalar y configurar cosas.

Lo último que acabo de arreglar: la posibilidad de dejar comentarios aquí en el blog. Con esto creo que ya está todo al 100% como antes.

Si encuentran algún otro detalle, me chiflan. ¡Gracias!

Comentarios Imprimir

Comiendo zapallo con Felipe

Un momento con el hijo, que me encantó (click en la foto para ver el video).

Comiendo zapallo con el hijo
Comentarios Imprimir

Experimento Cirujano-Copiloto

(Note: There's an English version of this article here )

Los últimos meses en el equipo Ubuntu One Foundations, en Canonical, estuvimos experimentando con la metodología cirujano-copiloto.

¿Qué es eso de cirujano-copiloto? El concepto viene de un libro de los setentas, The Mythical Man Month, donde Frederick Brooks describe un provocativo esquema (propuesto primero por Harlan Mills) para un equipo de desarrollo de diez personas. En el libro, Brooks intenta manejar el hecho de que proyectos grandes de software no pueden ser escritos por una persona, o por un equipo chico, por lo que propone partir el proyecto en partes más pequeñas, prestando especial atención a la optimización de las comunicaciones dentro y entre los equipos.

En el libro, la organización propuesta es poner a un desarrollador Cirujano rodeado de un gran equipo de ayudantes. Hoy en día el entorno de desarrollo es otro; tenemos herramientas como lenguajes de alto nivel, y repositorios de software, y versionado de código, etc. Seguramente no necesitamos a alguien para que nos clasifique las tarjetas perforadas, :)

Sin embargo, este es un concepto que podemos usar hoy, pero achicando el equipo a sólo dos personas: el cirujano, y el copiloto. Traducido del libro...

(el copiloto) es el alter ego del cirujano, capaz de hacer cualquier parte del trabajo, pero menos experimentado. Su función principal es compartir la etapa de diseño, pensando y discutiendo, y evaluando. El cirujano intenta ideas con él, pero no está atado a sus recomendaciones. El copiloto frecuentemente representa a su equipo en discusiones con otros equipos sobre funcionalidades e interfaces. Conoce todo el código íntimamente. Investiga estrategias alternativas de diseño.

Nuestra experiencia

Este experimento fue valioso para nosotros, ya que generó un equipo de dos que al ejecutar el experimento probó ser más eficiente que las dos personas por separado.

Alguno de los casos donde esto fue evidente durante el experimento fue que al discutir problemas o nuevas características, el cirujano (teniendo un conocimiento más profundo del sistema) podía prever fácilmente situaciones, cómo podría diseñarse la característica, resolverse el problema, etc. Entonces el cirujano discutía eso con el copiloto, necesitando explicar el razonamiento lo suficiente como para que se entienda (pero a alguien con experiencia en el sistema), lo que provocaba algunos buenos efectos secundarios:

  • Tener que poner el razonamiento en palabras lo hace más claro tanto para el cirujano como para el copiloto; sin embargo esto no es un gasto notable, ya que ambos conocen el sistema, lo que hace más sencillo la transferencia de conocimientos.
  • Se descubren temprano posibles fallas en el razonamiento, y también se pueden incorporar en este momento ideas frescas del copiloto.
  • Luego que el copiloto entendió la idea, él o ella pueden ayudar al cirujano a implementarla (o directamente hacerlo todo, liberando al cirujano para otras tareas).

Quiero dejar en claro que esto no implica que el copiloto dependa siempre del cirujano para el trabajo diario. Normalmente el copiloto trabaja creativamente y trae nuevas ideas y conocimiento al equipo; sin embargo discutir esta nueva información con el cirujano, de manera de integrarla mejor al sistema actual, hace más eficientes estas contribuciones.

Esto está muy relacionado con otro beneficio interesante del dúo dinámico cirujano/copiloto: entrenamiento. Cuando el copiloto es nuevo al equipo y al sistema, tener a alguien que sabe exactamente los avances que está haciendo al ganar velocidad, revisando y guiando el trabajo, hace más fácil y disfrutable esta etapa inicial (lo que se traduce a una mayor eficiencia y mejores resultados).

Más aún, este equipo altamente acoplado es especialmente bueno para atacar problemas complejos. Esto se debe principalmente a tener cuatro ojos en lugar de dos, pero con la ventaja que ambas personas tienen baja impedancia entre ellas. Sin embargo, ser explícitos sobre quien es responsable de tomar las decisiones es algo muy bueno en la interacción entre el equipo y otros jugadores externos (jefes, líderes técnicos, usuarios): queda claro que el cirujano es responsable por las decisiones tomadas, de una manera u otra.

Una ventaja adicional de formar el par cirujano/copiloto es que si el equipo prueba ser exitoso (lo cual depende de muchos otros factores más allá de esta configuración en particular, somos mayormente humanos) se puede mantener a futuro, sabiendo que esas dos personas trabajando juntas son buenas para determinadas tareas, y usarse de esa manera (lo cual concuerda con el concepto de desarrollo ágil de asignar trabajo a equipos, no personas a tareas).

Un caso real

Quiero explicar uno de los casos donde trabajamos como cirujano/copiloto durante estos meses, sólo como una muestra que quizás ayude a entender mejor los conceptos anteriores.

Este fue uno de los problemas más grandes encontrados en el Ubuntu One Syncdaemon luego de la liberación de Karmic, generando de los usuarios un quintillón de reportes de bugs: el States de Syncdaemon. Era un pedazo de código que arrancó chico y creció orgánicamente mientras aprendíamos qué debía hacer para manejar todas las complejidades de Syncdaemon. Al final, era un módulo grande, construido de una manera que no permitía realmente ser probado, y difícil de leer y entender, que generó un montón de problemas muy visibles (normalmente, hacía que Syncdaemon se trabara y no trabajara más hasta que se lo reiniciase).

El objetivo para el equipo era simplemente "arreglarlo". Sin embargo, un análisis simple probó que se necesitaba reescribir desde cero, y el reemplazo debía estar literalmente libre de problemas (no podíamos darnos el lujo de perder dos meses encontrando detalles en el nuevo código estando tan cerca de Lucid).

Ejecutamos el proceso de "arreglar States" en varios pasos bien definidos:

Análisis: Acá estudiamos el código anterior, encontrando los casos explícitos e implícitos que manejaba. Definimos qué necesitábamos cambiar, y qué necesitábamos escribir de nuevo (notablemente, encontramos acá algo inesperado: debíamos rehacer el cómo Syncdaemon manejaba las conexiones de red a través de Twisted).

En esta etapa, el tener un equipo altamente acoplado funcionó muy, muy bien. La misma tarea no podría haber sido ejecutada tan eficientemente si la hacía una sola persona, o si un equipo se involucraba en profundas discusiones. Debo mencionar que este trabajo se hizo cara a cara durante un sprint (difícilmente se podría haber hecho remotamente y tener el mismo resultado).

(click para ver la imagen en una resolución entendible)

Diseño: También durante el sprint diseñamos un nuevo modelo para la bestia, tratamos de simplificar y generalizarlo, y discutimos todo esto con los autor(es) anterior(es) del módulo.

El tener un cirujano con más experiencia en esta fase, mezclado con las nuevas ideas del copiloto, provocaron un buen diseño, simple y poderoso. Una sola persona o dos trabajando por separado no podrían haber diseñado el nuevo States de forma tan limpia como sucedió en este caso.

Implementación: esto se hizo completamente en paralelo y remotamente, en las semanas siguientes al sprint. Sin embargo también incluyeron largas conversaciones por teléfono donde se discutieron detalles específicos o nuevas ideas.

En esta etapa también notamos que el equipo tenía el tamaño ideal: un sólo par de ojos seguramente no habrían visto los detalles más complicados, y más gente no podría haber trabajado en paralelo en la misma implementación como lo hicieron dos personas.

(click para descargar los tres .SVG actualizados del diseño)

Puesta en funcionamiento: realmente no fue un paso, ya que no hubo ningún problema... fue sólo un tema de hacer el commit a trunk, y hacer un seguimiento los próximos días.

El resultado de esta experiencia fue muy satisfactorio: reemplazamos algo que era muy doloroso para usuarios y desarrolladores en favor de algo que fue invisible luego de la instalación: funcionó tan bien que nadie lo notó más.

Conclusiones

Estoy muy contento con el resultado de este experimento, y con los objetivos que logramos mientras lo hacíamos. El trabajo producido durante esos meses fue muy bueno, considerando especialmente que venía Lucid.

Sin embargo, es mucho más valioso encontrar dos personas que trabajen tan bien juntos, incluso si no hay una diferencia de experiencia entre ellos para que califique dentro de la estructura cirujano/copiloto. No siempre se tiene que un equipo de dos desarrolladores produce más que los dos desarrolladores por separado... entonces cuando se encuentra, es buena idea mantenerlo.

Recomiendo hacer experimentos similares en Canonical, especialmente como una oportunidad de aprendizaje para personas que recién entraron en la compañía, o al hacer rotaciones entre equipos. En estos casos, el tener un entrenador que tiene más experiencia al menos en lo que está haciendo el departamento, ayuda mucho al desarrollador nuevo, y al final mejora el rendimiento de todo el equipo.

Comentarios Imprimir