Colaboración real: lo que más cuesta lograr en los equipos

Trabajando con equipos que están adoptando Scrum (o algún otro framework ágil) suelo encontrarme escenarios como el siguiente:

• Trabajan en iteraciones (o sprints)
• Planifican al inicio
• Revisan al final
• Hacen retrospectivas (a veces) y tratan de mejorar

En muchos casos también tienen su reunión diaria (la daily standup o Scrum diario) y esos momentos suelen ser reveladores sobre qué están logrando como colaboración.

Antipatrón 1: cascada iterativa

Se nota al sincronizar que los miembros del equipo tienden a esperarse entre sí. Por ejemplo, alguien menciona que está terminando de diseñar X, que otro persona necesita para poder empezar a programar, para que finalmente otro pruebe...

Es frecuente en ese caso que algunos de los que no pueden continuar un item, inicien cualquier otra tarea (usualmente de menor prioridad) en la que no tengan trabas.

Obviamente, cuando se libera el ítem de más prioridad, es común que quede en espera hasta que se termine alguna de esas tareas menos prioritarias.

Antipatrón 2: sobre-especialización

También podemos notar que en diferentes momentos ciertos ítems se acumulan y quedan pendientes para un especialista en particular, dependiendo del momento en que estamos del proyecto. En algún momento puede ser que haya mucho por hacer en la interfaz de usuario, y la persona a cargo queda desbordada, mientras los demás, nuevamente, comienzan a trabajar en lo que puedan.

En el extremo, se nota en ciertas iteraciones que algunos de los miembros del equipo están llenos de trabajo, mientras que otros no tienen mucho que hacer.

La magia de trabajar de a pares

Es problema de estos escenarios es que ese grupo no está colaborando realmente. De hecho, no es un equipo ágil, sino un grupo con apenas un objetivo común, por más sincronización diaria que hagan.

Un equipo ágil se enfoca en la prioridad; en el valor de negocio. Por lo tanto, antes que iniciar ítems de menos prioridad, cada persona busca oportunidades de colaborar con quien ya inició un ítem más prioritario, con varios objetivos:

• Tratar de terminar cuanto antes lo que tiene más valor
• Ayudar a mantener el foco y evitar bloqueos mentales frecuentes cuando trabajamos solos
• Aprender lo básico de las especialidades del resto del equipo, para que poco a poco muchas tareas triviales (que estadísticamente son la mayor parte de un proyecto) puedan ser resueltas por cualquiera.
• Lograr mayor integridad conceptual en el producto, al compartir con todo el equipo una visión holística, donde el equipo entero es responsable por el total, y no por diferentes componentes o aspectos.

¿Todo hay que hacerlo de a dos?

No necesariamente. De hecho, aunque suena raro, si un equipo empieza a trabajar de a pares más frecuentemente, va aumentando la capacidad de cada miembro de encarar solo cualquier tarea. Pero a la vez aumenta la facilidad con que cualquiera puede pedir ayuda (cosa que para mucha gente es una enorme barrera) a otros.

Lo que suele ocurrir es que las personas tienden a trabajar solas en las tareas más sencillas y triviales (con un poco de aprendizaje, incluso las que están fuera de su especialidad) y les resulta casi natural reunirse y dividirse de manera fluida según sus necesidades.

Colaboración real en equipos

Dentro de los equipos ágiles, en definitiva, se busca que a través del aprendizaje colectivo podamos extender las capacidades de cada persona más allá de su especialidad. Esto no significa que ignoramos el estudio y experiencia acumulada de cada uno, ni que queremos que todos sean absolutamente expertos en todo.

Lo que busca un equipo ágil es aplicar el principio de Pareto a las capacidades individuales, es decir que cada persona aprenda aproximadamente el 20% de las especialidades del resto del equipo, que suelen resolver el 80% de su trabajo.

En definitiva, buscamos poder distribuir más uniformemente el trabajo, aprovechando al máximo los conocimientos muy específicos solamente en esos pocos casos en que se plantean problemas tan complejos que requerimos todo el poder del "experto".

Finalmente, esta forma de trabajo es la que apoya el principio ágil de enfocarnos en la entrega de valor, ya que nadie necesita estar haciendo nada que no sea de la mayor prioridad.

Espacios de Trabajo para Equipos Ágiles

Este es un tema recurrente con muchas organizaciones a las que ayudo. Como el foco principal del paradigma ágil es la colaboración, muchas veces llega un momento en que ellos notan que sus espacio de trabajo no son ideales para lo que intentan lograr.

 

Espacios frágiles

Los espacios de trabajo más nocivos que me encuentro suelen incluir desde cubículos hasta oficinas individuales a puerta cerrada. Y aclaro que he trabajado en lugares así, aunque nunca fue mi preferencia. Durante un tiempo -hace muchos años- me tocó una oficina privada, alejada por un pasillo largo del equipo que me tocaba liderar. Al principio me sentí inocentemente importante, pero pronto me di cuenta de que esa distancia no nos beneficiaba en nada.

Algunas variantes de los cubículos son los espacios semi-abiertos con escritorios con divisiones más bajas, que permiten verle los ojos a la persona de enfrente, aunque no alientan una colaboración más allá e una pregunta o conversación esporádica.

Y no sólo los espacios físicos generan fricción. Muchos espacios virtuales también lo son. Muchas de las llamadas "herramientas de colaboración" me resultan consistentemente un impedimento a la conversación cara a cara. A riesgo de controversia, no he visto nunca un equipo que mejore su comunicación (pero si montones que definitivamente empeoraron) por usar Jira, Sharepoint u otras monstruosidades que están más diseñadas para calmar al management que para que la gente se auto-organice.

 

Espacios con "Onda Ágil"

Muchas organizaciones, al sentir que la gente se entusiasma con la agilidad, quieren crear lugares atractivos para atraer talento que espera determinadas características laborales que no son tan fáciles de transmitir a simple vista. Así que recurren al folklore y no muy extrañamente, atraen a los estereotipos a los que se dirigen, lo que no siempre da resultado.

Clásicos de ese estilo son las metegoles (o futbolines, según la región), las paredes ploteadas con íconos y slogans sobre creatividad, innovación y talento, aunque frecuentemente esos y otros valores están en las paredes pero no se sienten en el día a día. En algunos extremos (que creo bien intencionados) se ven exaltaciones a los super-héroes, los rock-stars o ninjas. Como si colaborar fuese tratar de ir solo contra todo, inmolándose por alguna causa esquiva.

 

¿Espacios realmente ágiles?

Mis consejos para quienes quieren realmente generar un ambiente de colaboración y dinamismo van siempre en el mismo sentido: empezar por no definir todo, sino dejar lo máximo posible a criterio de los equipos que usarán el lugar.

Para eso, realmente suele ser preferible contar con espacios abiertos, pero como pueden ser ruidosos, se puede recurrir a elementos que la gente pueda usar para crear sub-espacios flexibles y reconfigurables.

Algunos de los elementos que prefiero (por experiencia, como materia mínima para que los equipos decidan después):

• Mesas pequeñas, con patas no intrusivas, donde al menos se pueda trabajar de a dos. O livianas o con rueditas.
  
  
• Tomas de corriente a granel, sobre las paredes. Y que los equipos puedan poner sus (inevitables) extensiones por donde quieran. Si los cables se tornan molestos o peligrosos, ellos deberían encontrar la mejor solución, no un "arquitecto".
  
  
• Pizarras o bastidores fáciles de mover (con rueditas o livianos) pueden servir como separadores, aislantes acústicos y también como soporte para radiadores visuales.
  
  
• Paredes libres (también pueden ser ventanas o paneles de vidrio), sin inscripciones, emblemas ni slogans previos. El uso de las paredes para pegar tableros, indicadores, información necesaria para el equipo, es vital para la comunicación osmótica. Los pizarrones de diferente tipo, sobre todo si son móviles, son un buen recurso para discusiones y diagramas efímeros.
  
  
• Buenas sillas. Pensando que los trabajadores del conocimiento usamos sobre todos nuestro cerebro y nuestro trasero, tener buenas sillas (de nuevo, móviles) es una excelente inversión para cuidar la salud y comodidad de los equipos.

Sobre todo, si queremos promover un ambiente de autonomía y creatividad, demos los elementos básicos y dejemos que los equipos se apropien. Lo que no significa dejarlos a la deriva. Se puede explícitamente pedirles que determinen un plan, tal vez con un presupuesto básico y posibles extensiones iterativas.

Varias veces vi que se diseñan espacios incluyendo áreas de "esparcimiento" para los equipos, donde se incluyen equipos de videojuegos, mesas de ping-pong o instrumentos musicales. Pero este nuevamente es per-determinar qué es lo que ellos querrán, en lugar de preguntarles. Tal vez terminen poniendo la consola de juegos, pero ellos elegirán cuál prefieren y cómo instalarla. O tal vez prefieran otra cosa, como un espacio para cocinar o para hacer yoga.

En definitiva, al pensar espacios ágiles, tenemos que mantener sus principios: flexibilidad, transparencia, diversidad.

Si alguno tiene interés en compartir los espacios que generaron, pueden mandarme fotos, y veo cómo compartirlas.

 

Imperdible: cócteles para programadores

Todos los años se festeja el Día del Programador, el día número 256 del año. Esta vez pasó el 13 de septiembre, y para festejarlo, un colega ruso publicó una serie de cócteles para programadores, publicada en GitHub, traducida a varios lenguajes, incluido el español, y con varias fotos muy buenas, algunas de las que reproduzco a continuación para abrirles el apetito (o la sed, en este caso).

Gracias a los amigos de Surculus Fructum por el dato.

Debajo, los cócteles para Ruby, Python y Assembler, respectivamente. En el post hay varios más, incluyendo las recetas. ¡Salud!

  

Agile Solo: Manejando el backlog personal

Continuando con la serie Agile Solo, hoy quería comentar algunas ideas para manejar el backlog de tareas y mejorar el nivel de compromiso de uno mismo hacia sus clientes o usuarios.

Una buena práctica para no dejarse tentar por la procrastinación es utilizar alguna herramienta para hacer público nuestro backlog. Como siempre, desde la agilidad le damos prioridad a la interacción entre las personas, por lo que prefiero concentrarme en cómo me comunico, y usar las herramientas más sencillas posibles (en particular me gusta Trello por que es liviano y su funcionalidad es mínima).

Lo importante para mi del backlog es tener donde volcar las clásicas tres columnas: pendiente, en marcha y terminado. Y lo bueno de tener una manera de hacerlo público es que podemos mostrar a las personas involucradas qué planificamos (por ejemplo, para la semana) y cómo vamos. Es posible que tengamos que unificar temas de varios clientes, y puede haber algunos relativamente confidenciales, para lo que prefiero usar nombres de código para los proyectos. De esta manera, cada cliente sabe el nombre de código, y puedo usarlo como “etiqueta” en mi backlog, sin divulgar identidades, preservando su confidencialidad. De la misma manera, no necesito poner detalles demasiado específicos de la tarea pendiente; alcanza con que ponga algo que mi cliente comprenda. Veamos un ejemplo:

Algunos tips sobre los nombre de código que me resultan útiles:

• No hacen falta para cosas no-confidenciales (en mi ejemplo, C&B para este blog, MUG, nombres de amigos)
• Conviene usar nombres que no signifiquen nada y que no tengan ninguna connotación. 
• Es bueno tener a mano una serie de muchos nombres disponibles. Yo elijo, por ejemplo, nombres astronómicos (estrellas, planetas o satélites) porque hay miles y usualmente no acarrean ningún significado especial. En otros casos utilicé nombres de ríos, pájaros, flores o plantas, frutas, etc. Google utiliza nombres de dulces para Android, Ubuntu animales más un adjetivo, etc.
• Lo importante es que el cliente reconozca SU proyecto (en el ejemplo, Fobos y Deimos son proyectos de clientes diferentes).

Obviamente exponer nuestro backlog plantea desafíos, pero yo creo que son sanos. Por ejemplo, el cliente de mi proyecto Fobos podría reclamarme prioridad sobre Deimos, aunque no sepa quien es. Eso nos obliga a ser transparentes, pero también a poder explicar racionalmente nuestra priorización, y el problema se termina si al final de cada iteración todos están conformes. También, aunque no hayan gran nivel de detalle en cada item del backlog, lo que hacemos para un proyecto puede inspirar ideas a otros clientes, y no está mal que esto pase.

Hay otras alternativas, por supuesto, como tener backlogs separados por cliente, donde cada uno vea su parte. En mi experiencia esto nos complica más de lo que nos ayuda, porque oculta la complejidad de nuestras actividades, y hace sentir a cada cliente que trabajamos solamente para él (lo que no está mal si es real).

Como siempre, hay cosas que dependen del nivel de madurez, pero en general yo prefiero que quien actúa de Product Owner en mi cliente tenga acceso a mi backlog y pueda poner todo lo que quiera. ¿Me arriesgo a que cambien prioridades? Si, pero prefiero siempre brindar más libertad y pedir responsabilidad que tratar de controlar. :)

Espero que algunas de estas ideas sirvan aunque sea para cuestionarlas y generar prácticas alternativas.

PragPub de septiembre: revista gratuita y en varios formatos

Comenté sobre PragPub hace un par de años, pero para quienes no estaban por ahí todavía, vuelvo a recomendarla.

Se trata de una revista publicada mensualmente por The Pragmatic Programmers, la editorial de Andy Hunt y Dave Thomas, autores, entre otros, de éste clásico libro que todo programador debería haber leído.

La revista en si tiene unas 60 páginas (en su edición PDF) y cubre temas generales (en inglés) de programación y sobre el perfil profesional de los desarrolladores de software. Se edita mensualmente y en formato HTML (para leer en el navegador), PDF, epub y mobi (estos últimos para lectores electrónicos como Sony Reader y Kindle, respectivamente).

 Los temas de este mes son:

• Thinking Functionally with Haskell, por Paul Callaghan. Una exploración al sistema de tipos de Haskel y sus consecuencias en la validación de aplicaciones.
• Tales from the Ops Side, por Michael Nygard. Aquí el author del libro "Release it!" cuenta algunas escenas comunes en un escenario de operaciones.
• US Visa: My First iPhone App, por Alexander Demin. Cuenta la experiencia de construir la primer aplicación para iOS, incluyendo código.
• Threads, por Michael Swaine. Es una nota donde el editor de la revista cuenta la historia de Chris Espinosa, miembro del equipo de desarrollo de Apple desde la primer etapa de la compañía.

Y como siempre incluye las seccione Up Front (la editorial), Choice Bits (el ranking de los libros más vendidos de la editorial), Calendar (conferencia, charlas interesantes en varias partes del mundo, y otros eventos) y Shady Illuminations (la columna de opinión de John Shade).

 

En el caso de la revista, que es gratuita, tal vez no llaman tanto la atención la variedad de formatos y el hecho de que los archivos estén libres de toda protección, pero es interesante que lo mismo sucede con los libros de la editorial, que publica muchos títulos de nicho como Deploying Rails, Programming Your Home, The Cucumber Book y otros que los programadores difícilmente consigamos en otro lado, con el agregado de que en general el nivel es muy bueno, tanto o más que en las principales editoriales técnicas.

Código en colores: temas para programar

Hace tiempo que no publicaba nada, ocupado con muchos temas laborales y personales, pero estoy organizándome nuevamente y vuelvo a la carga. Ojalá pueda ir subiendo la frecuencia y llegar de nuevo al ritmo diario dentro de poco.

Todos los que programamos tenemos una serie de hábitos que son bastante personales y que nos ayudan a mantener el foco y la comodidad en la tarea. Muchas veces no podemos elegir de manera directa cosas como el lenguaje, la plataforma o ciertas herramientas, pero en la mayoría de los casos si podemos personalizar sus configuraciones.

Una de las personalizaciones más comunes y variables son los colores de nuestros editores o IDEs. Algunos preferimos fondos oscuros, otros claros, a veces tonos medios. En mi caso prefiero los primeros, y siempre estoy buscando variantes de "temas" de colores que pueda usar en diferentes ambientes. No es una búsqueda activa, sino que en general me llama la atención cuando alguien menciona nuevos temas en algún blog o artículo, y cuando puedo le dedico unos minutos a mirarlos.

Esta mañana mientras leía otra cosa llegué de causalidad a la página de temas en la Wiki de TextMate, uno de los editores que uso frecuentemente, y echando una mirada me llamó la atención un tema mencionado como 2morrow Night (muestra a la derecha).

Lo interesante es que siguiendo el link de descarga en GitHub descubrí que Chris Kempson, el autor, se tomó el trabajo de brindar este mismo tema (y sus variantes) en muchísimas plataformas, como BBEdit, Coda, Eclipse, Expresso, GEdit, Emacs, editores de JetBrains, la terminal de OS X, Visual Studio y muchos otros. Una labor obsesiva e invaluable. Empecé a bajar algunos de ellos, y después me di cuenta que era más fácil tenerlos todos, así que fui a mi consola y:

> git clone https://github.com/ChrisKempson/Tomorrow-Theme.git
Cloning into Tomorrow-Theme...
remote: Counting objects: 445, done.
remote: Compressing objects: 100% (228/228), done.
remote: Total 445 (delta 225), reused 425 (delta 208)
Receiving objects: 100% (445/445), 940.89 KiB | 332 KiB/s, done.
Resolving deltas: 100% (225/225), done.

…y en 10 segundos tenía todos a mi alcance. Me sigue maravillando la cantidad de cosas que quedan cada vez más a nuestro alcance desde GitHub u otros recursos en la nube.

Como dije, Chris se tomó el trabajo en serio y todas las variantes por plataforma están en el formato correcto, con lo que al hacer doble clic sobre los archivos, en la mayoría de los casos, el editor los agrega directamente (en mi caso, TextMate y Terminal lo hicieron, en Vim lo abre y hay que ejecutarlo, ya que es un script completo).

Si les gusta probar temas, pueden tomar esto como mi regalo de navidad.

Si no, aprovecho igualmente para desearle felicidades a todos los lectores.

 

Global Day of Coderetreat

El pasado sábado 3 tuvo lugar el Global Day of Coderetreat, un evento que aglutinó a 2200 desarrolladores en 90 locaciones alrededor del mundo. El raid comenzó en la costa este de Australia y culminó en la costa oeste de América.

Coderetreat

Un coderetreat es un evento en el que programadores realizan una práctica intensiva, generalmente de un día de duración, focalizando en los fundamentos del diseño y desarrollo. Suelen resolverse problemas sencillos (un clásico es el Juego de la vida de Conway) en un entorno en el que solo es importante aprender, sin las presiones día a día. Mas información aquí [inglés].

Por supuesto, cualquiera que lo desee puede organizar un coderetreat, mas información aquí y aquí, ambos en inglés.

Mas allá de la lectura de libros, papers, listas de discusión y artículos especializados, el verdadero aprendizaje en el que el desarrollador mejora sus habilidades esta en la práctica. Esto es lo que motiva el coderetreat (o coding katas y coding dojos).

En Buenos Aires

La edición de Buenos Aires tuvo lugar en las oficinas de Kleer, organizada por el anfitrión con la colaboración y apoyo de Kinetica Solutions y 10Pines.

El resultado fue muy interesante. Participaron desarrolladores de distintas tecnologías (Cobol entre ellas) y los asistentes intercambiaron entornos de programación: Ruby, .NET, Java y hasta Transact-SQL. Este último caso (en la imagen que ilustra este post) fue el mas llamativo no solo por el entorno inusual de desarrollo, también porque fue el único que logro llegar a una implementación funcional.

Todos los presentes, invariablemente y en cada una de las iteraciones de trabajo, reportan haber aprendido algo nuevo. Esto es característico de la práctica relajada, libre de presiones.

A quien este interesado en este tipo de eventos recomendamos asistir a los Yoseki Coding Dojos gratuitos organizados por Kleer el primer miércoles de cada mes.

 

Novedades de SADIO

Como cada tanto tiempo, compilo las últimas novedades de la Sociedad Argentina de Informática, algunas de las cuales pueden ser de interés en el resto de Latinoamérica ya que algunos eventos son de alcance regional o internacional.

Homenaje a Clementina

Exactas y la Fundación Sadosky celebrarán los 50 años de la primera computadora científica argentina.

Con el fin de conmemorar los cincuenta años de la puesta en funcionamiento de la primera computadora científica argentina, conocida como “Clementina”, el Departamento de Computación de la Facultad de Ciencias Exactas y Naturales (FCEN) de la UBA y la Fundación Sadosky, organizarán un amplio programa de actividades.

La Clementina era una computadora a válvulas, que medía 18 metros de largo y que requería de un gran equipo de refrigeración. La entrada de datos y programas se hacía a través de cintas de papel perforadas parecidas a las de los teletipos de la época. Inicialmente no tenía impresora. La memoria de trabajo era de 1K (si, "un" K) y tenía 4 "tambores" de memoria (el equivalente al disco duro) de 8K cada uno. Esa computadora, sin embargo, fue el sostén de un proyecto de vanguardia: el Instituto de Cálculo de la FCEN que, encabezado por Sadosky, se convirtió durante la década del ’60 en un programa innovador para nuestro país, con una triple misión: investigación, docencia y servicio.

El 12 y 13 de mayo se llevarán a cabo las Jornadas “Manuel Sadosky”, con los pioneros de la computación científica nacional. En las jornadas participarán investigadores, ingenieros, programadores, usuarios y referentes de la época, los cuales expondrán en diversos paneles temáticos:

• El Instituto de Cálculo como proyecto de la Universidad de los años 60 - Pablo Jacovkis (Profesor de la FCEN).
• ¿Cómo era esa primera computadora?: hardware, software, operación - Ernesto García Camarero (Jefe de Programación y Profesos de los
• Cursos de Formación 1961/63) y Jonás Paiuk (Jefe del Grupo de Ingeniería Electrónica).
• El Instituto de Cálculo y su misión de servicio - Julián Araoz (Responsable del Grupo de Investigación Operativa).
• La aventura de programar a Clementina. Trucos, trampas y complicaciones de esos primeros lenguajes: del Autocode al Comic - Wilfred Durán (Responsable del desarrollo del lenguaje COMIC), Violna Eandi, Victoria Bajar y Cristina Zoltan (Programadores).
• Cometas y Telefonía: Cómo se calculó la órbita del cometa Halley y se armaron protocolos de comunicaciones con la vieja máquina. - Víctor Pereyra (Investigador del Instituto de Cálculo –Mecánica Celeste) y Juan Carlos Angio (Encargado del Proyecto de la telefónica ENTEL con el Instituto de Cálculo).
• Modelar la sociedad argentina. Modelos macroeconómicos y experimentación numérica: los proyectos de Oscar Varsavsky. - Arturo O’Connell (Economista e investigador del Instituto de Cálculo).
• Otras miradas: el Instituto de Cálculo visto desde otras empresas e instituciones de la época. - Alfredo Perez (Profesional de UNIVAC) y Horacio Reggini (Fundador de la Sociedad Argentina de Informática e Investigación Operativa -SADIO-).

Al mismo tiempo se inaugurará un museo interactivo que reunirá la escenografía con mobiliario de la época, partes originales del equipo y documentos que testimonian la llegada de la computadora al país.

Las Jornadas tendrán lugar el jueves 12 de mayo a partir de las 17 hs. y el viernes 13 de mayo desde las 15 hs. en el Departamento de Computación de Exactas, Pabellón I de Ciudad Universitaria, C.A.B.A.

40 JAIIO - Extensión de fecha límite para el envío de trabajos

Como comenté en un post anterior, SADIO organiza la edición 40 (si, llevan cuarenta años) de las Jornadas Argentinas de Informática.

La fecha límite de recepción de trabajos se ha extendido según el siguiente cronograma:

• 13 de Mayo: fecha límite de presentación para ASAI, ASSE, CAI, HPC, JII, JSL, JUI, SID, SIE, SIO, SSI, WSegI, EST.
• 16 de Mayo: fecha límite de presentación de trabajos para AST
• 30 de Mayo: fecha límite de presentación de trabajos para CAIS

Ya está disponible el Open Conference System para comenzar con el envío de trabajos.

Las 40 JAIIO se realizarán en la Ciudad de Córdoba, del 29 de Agosto al 02 de Septiembre de 2011, en la UTN - Facultad Regional de Córdoba. La información completa en el sitio de las jornadas.

Día Mundial de Internet

El 17 de mayo es el Día Mundial de Internet, y por eso SADIO y otras organizaciones realizarán en forma virtual las Jornadas Día de Internet y se darán a conocer los ganadores de la edición 2011 del premio mate.ar que, consolidado como el máximo reconocimiento a lo mejor de la web de nuestro país, refleja desde hace más de una década la evolución de internet en Argentina.

Mi pequeño homenaje

Tal vez notaron que los últimos días hubo pocos posts en este blog, en el que en general publico algo diariamente, de lunes a viernes.

El hueco se debe a que mi padre falleció la semana pasada, y obviamente mis prioridades no pasaron por aquí. Pero hoy retomo con un post que pretende ser mi pequeño homenaje para él, que fue quien incluyó en mi carrera técnica, y me acercó, de alguna manera, al mundo del software. Más allá del homenaje, espero que algunos lectores se sientan identificados, tal vez, con alguna anécdota que les recuerde su propio camino.

Mi padre fue tripulante de vuelo en Aerolíneas Argentinas por décadas. Mientras estudiaba para piloto, empezó a trabajar como auxiliar de vuelo, más tarde comisario de a bordo, hasta que logró pasar a un puesto de cabina con un puesto que hoy ya no existe: navegador / radio-operador (navro, en la vieja jerga aeronáutica).

Algunas de las primeras cosas que cautivaron mi imaginación por la tecnología fueron verlo trazando rutas sobre mapas gigantescos (desplegados eran como una sábana de dos plazas) utilizando compases y transportadores muy complejos, o revisar los enormes manuales de vuelo de los aviones, que en esa época los tripulantes llevaban encarpetados en pesadas valijas junto con sus instrumentos.

Pero el primer empujón real a lo que se convertiría en mi carrera fue cuando me regaló, traído en uno de sus viajes a EEUU, un kit de electrónica con componentes pre-armados, para usar sin soldador, mordiendo el extremo de los cables en pequeños resortes que conectaban a las patas de los diodos, transistores, resistencias, y demás componentes.

Hace mucho que perdí el rastro de aquel kit, y no conservo ninguna foto, pero encontré esta foto de un kit que es prácticamente idéntico al mio:

La caja de madera tenía una lamparita, capacitores, resistencias, diodos y transistores, un ferrite con bovina (para captar radio), algunas celdas solares, un potenciometro, un display de leds (para un único dígito), un parlante, y zócalos para baterías de distinto voltaje, entre otras cosas.

Con este kit aprendí, a fines de los '70, a hacer un flip-flop, algunas compuertas lógicas, y cosas más triviales como una radio, un sensor de luz y otros proyectos básicos. Pero bastó para mostrarme la base de la electrónica analógica y poner un tímido pie en la digital.

Como yo estaba en la escuela primaria y mi inglés era muy precario, mi viejo se tomó el trabajo de traducir todo el manual que se ve en la foto, con los 160 proyectos mencionados (algunos de más de una página) escribiéndolos en una máquina Olivetti portátil que llevaba y traía en cada vuelo durante un mes o dos, dedicando todo su tiempo libre a mi curiosidad.

Este juego me decidió a entrar en un colegio secundario con especialidad en electrónica, donde aunque no aprendí mucho del tema realmente, conocí a otros proto-hackers de los que me hice amigo y con quienes empezamos a molestar en los primeros negocios que traían computadoras personales al país (mucho antes de la IBM PC), convenciéndolos de que nos dejaran usarlas un poco a cambio de hacer demostraciones para los clientes interesados, ya que usualmente nadie sabía como usarlas.

La primer computadora que fue mía (al menos un tercio) también la financió mi papá. La compramos con otros dos amigos y la teníamos una semana cada uno, pero él nos desafió a que teníamos que mostrarle lo que aprendíamos a nuestros padres, más allá de los juegos, para asegurar que no perdiéramos oportunidad de aprender.

También fue el viejo quien me heredó su colección de revistas Mas Allá (la primer revista argentina de ciencia ficción, editada a mediados de los '50 y que él guardó -sin saberlo- para encender otra llamita en mi cabeza, que entró con estos tomos en el mundo de la ciencia ficción, que es también responsable de gran parte de las ideas que me llevaron a dedicarme a la programación.

El resto es historia, pero todo empezó con esos empujones iniciales de mi querido viejo, con quien ya no voy a poder charlar de nuestros interés comunes, y a quien sólo me queda extrañar.

SADIO organiza la 40va edición de las JAIIO

(luego de un receso vacacional, este blog vuelve a la carga)

En estos días me llegó el boletín de SADIO, la sociedad decana de nuestra área en Argentina, con más de 50 años de trayectoria. Me parece una buena ocasión para hacer eco de una de sus principales actividades.

Este año volverán como siempre las jornadas argentinas de informática. La edición número 40 (arrancaron en 1961) se llevará a cabo del 29 de agosto al 2 de septiembre en la UTN de Córdoba, Argentina.

La descripción de las jornadas, según los organizadores mismos, es:

En sesiones paralelas se presentan trabajos que se publican en Anales, se discuten resultados de investigaciones y actividades sobre diferentes topicos, desarrollandose también conferencias y reuniones con la asistencia de profesionales argentinos y extranjeros. Las JAIIOs se organizan como un conjunto de simposios separados, cada uno dedicado a un tema específico, de uno o dos días de duración, de tal forma de permitir la interacción de sus participantes.

Como siempre hay amplia variedad de simposios, incluyendo:

• ASAI 2011 - Simposio Argentino de Inteligencia Artificial
• ASSE 2011 - Simposio Argentino de Ingeniería de Software
• AST 2011 - Simposio Argentino de Tecnología
• CAI 2011 - Congreso Argentino de AgroInformática
• CAIS 2011 - Congreso Argentino de Informática y Salud
• HPC 2011 - High Performance Computing
• JII 2011 - Jornadas de Informática Industrial
• JSL 2011 - Jornadas Argentinas de Software Libre
• JUI 2011 - Jornadas de Vinculación Universidad-Industria
• SID 2011 - Simposio Argentino de Informática y Derecho
• SIE 2011 - Simposio de Informática en el Estado
• SIO 2011 - Simposio Argentino de Investigación Operativa
• SSI 2011 - Simposio sobre la Sociedad de la Información
• WSegI 2011 - Workshop de Seguridad Informática
• EST 2011 - Concurso de Trabajos Estudiantiles

Para los interesados en proponer trabajos para cualquiera de estos simposios, ya está abierta la recepción, que cierra el 2 de mayo. Para comprender bien el proceso de presentación (necesario por el enorme volumen de presentaciones), lo ideal es seguir las instrucciones detalladas en la página de cada simposio (por ejemplo, la del de Ingeniería de Software). Implica crear primero credenciales individuales (si no se presentó un trabajo previamente en otras JAIIO), y luego hacer la presentación de la o las propuestas.

Dejo un breve video mostrando el mecanismo para la edición pasada, ya que el proceso sigue siendo igual.

 

 

Meditación programática: Koans

Los Köan (pronunciación japonesa del chino 公案) o Koan, son ejercicios mentales de la meditación Zen, consistentes en diálogos o preguntas que plantean un problema que muchas veces no tiene respuesta directa. El objetivo de un Koan es el aprendizaje durante el proceso de elaboración de la respuesta, más que la respuesta en sí.

Un ejemplo clásico es la pregunta: "Cuando dos manos aplauden hay un sonido. ¿Cuál es el sonido de una sola mano?".

Tomando esta idea como base, de manera similar a la idea de los Code Katas que comentaba en un post reciente, diferentes personas empezaron a generar Code Koans para diferentes lenguajes. Como siempre, la adaptación es libre y no sigue exactamente los mismos principios, sino que e inspira en la idea motora.

Los Koans dentro del campo de la programación parten del objetivo de comenzar con conceptos sumamente básicos y realizar ejercicios generalmente abiertos, pero que frecuentemente llevan a la necesidad de experimentar o investigar un poco más allá del alcance mismo del planteo.

Hay colecciones de Koans para varios lenguajes, entre ellos Ruby Koans (Jim Weirich y Joe O'Brien), JavaScript Koans (Liam McLennan), .NET Koans (Cory Foy) y los Clojure Koans (Aaron Bedra).

La mayoría de estos proyectos están inspirados en el primero, los Ruby Koans, de los que incluyo algunos ejemplos para que se entienda el concepto general.

Los Koan suelen estar agrupados por temas, por ejemplo en los de Ruby, hay series para arrays, blocks, clases, excepciones, módulos, strings, y muchas más.

Los Koans se basan siempre en la práctica de Test-Driven Development (curso gratuito en español disponible), donde las "preguntas" están formuladas como tests, que el aprendiz debe implementar y pasar. La diferencia con TDD tradicional es que el test principal ya está escrito (lo que no significa que no podamos agregar más).

Lo primero a ejecutar en los Ruby Koans es (desde la línea de comandos):

$ ruby path_to_enlightenment.rb

y el resultado es algo como:

AboutAsserts#test_assert_truth has damaged your karma.

The Master says:
  You have not yet reached enlightenment.
  Do not lose hope.

The answers you seek...
  Failed assertion, no message given.

Please meditate on the following code:
  /Users/ . . . /koans/about_asserts.rb:10:in `test_assert_truth'

mountains are merely mountains
your path thus far [X_________________________________________________] 0/274

El mensaje juega con el estereotipo del Maestro Zen y el estilo de los consejos, pero más allá de eso, nos da un indicio: nos dice que meditemos en el método test_assert_truth dentro del archivo about_asserts.rb. Si abrimos este archivo y lo miramos, encontramos este test donde el motivo de la falla es más que obvio:

  # We shall contemplate truth by testing reality, via asserts.
  def test_assert_truth
    assert false                # This should be true
  end

Al cambiar a assert true y ejecutar de nuevo, obtenemos un mensaje similar sobre el siguiente test que falla, y otra frase Zen diferente para inspirarnos. Por supuesto, a medida que avanzamos la respuesta es menos evidente que cambiar un false a true. El primer ejercicio solamente sirve para que entendamos el procedimiento.

En varios casos, la manera de resolver el test no es evidente y tenemos que buscar más información en libros o en la web, pero esto es lo que buscan los Koans: forzarnos a aprender algo, pero siguiendo baby steps.

Code Katas - la práctica hace al Maestro (videos)

Tomando como inspiración la forma en que los músicos ensayan para mejorar su técnica, o más directamente la manera en que se realizan las prácticas en las artes marciales, efectuando ejercicios repetitivos hasta dominar por completo ciertos movimientos, lo que permite empezar a componerlos, Dave Thomas (uno de los Pragmatic Programmers), comenzó a popularizar el concepto de Code Katas. Para quienes quieran saber la historia completa de la génesis Dave la cuenta completa en este post.

Con el tiempo, el concepto de Code Kata trascendió a Dave y fue adoptado por mucha gente dentro de la comunidad, con variantes en la manera de encararlo, pero compartiendo una intención común.

En forma simplificada, la idea de un Kata de código es similar a su predecesor en Karate (y no es exactamente lo mismo, pero Dave tomó la idea general, no intentó que sea un calco de las artes marciales). Se trata de realizar prácticas frecuentemente sobre una serie de movimientos (en código, ejercicios determinados).

Esta idea de la práctica constante tiene que ver con ideas como las de Peter Norvig en su clásico "Aprende a programar en 10 años" (traducción al español de Carlos Rueda).

Uno de los más clásicos es la calculadora de strings. La idea es hacer un programa que resuelva expresiones como "42 * 8" o "(66 / 3) -7". El ejercicio implica un mínimo de parsing para separar los operadores y operandos, y manejar un stack para los paréntesis. Obviamente no hay una respuesta única, e incluso la resolución puede variar mucho si el ejercicio se resuelve en Java, en Haskell o en Cobol.

La diferencia con realizar el ejercicio una sola vez, es que en los Katas vamos a resolver ese mismo ejercicio (y otros) muchas veces. Es realmente como ensayar un tema musical. Cada vez sale mejor, pero todas las veces la experiencia es levemente diferente. También podemos aprovechar la familiaridad con el ejercicio en si para probar diferentes técnicas.

Por ejemplo, podemos tomar otro Kata, como el clásico FizzBuzz, que en varios lados utilizan como primer filtro en las entrevistas a programadores, y realizarlo la primera vez a los tumbos, luego utilizando pruebas unitarias, luego con TDD, luego sin usar el mouse, luego cambiar de lenguaje, etc. Este es un ejercicio bastante corto que permite incluso ser resuelto varias veces seguidas durante el lapso de una hora o dos.

Extrañamente, mucha gente no encuentra sentido a este tipo de práctica, y sin embargo puede pasar horas y horas tratando de tocar Escalera al Cielo de Led Zeppelin (sin ser buen guitarrista, para empezar). Lo importante es poner el mismo tipo de intención en estos ejercicios, tratar de mejorar nuestra técnica, optimizar el flujo de trabajo de nuestra IDE o editor, la legibilidad del código, etc.

Definitivamente, quienes trabajamos en esta industria bastante tiempo sabemos que los años pasados de experiencia no equivalen a "experiencia valiosa". Este tipo de actividades nos mantiene afinados. Y afortunadamente hay entusiastas que nos acompañan, como en CodingKata.org o la reciente iniciativa en español 12 meses, 12 katas.

Casualmente de este último les comparto un ejemplo en video, de la calculadora de strings en Ruby (utilizando RSpec para las especificaciones/pruebas) por Eric Minio. Recuerden, la solución de Eric no es más que una de muchas posibles. La gracia es ver cómo lo hace él y hacerlo nosotros con nuestras propias ideas, técnicas y herramientas.

Noten que los katas no necesitan ser ejercicios menores y simples. Como comprobación de la hipótesis del título de este post, baste ver como el Maestro Angel "Java" López se ejercita continuamente con sus particulares katas (compiladores, intérpretes, utilitarios), todos disponibles en su repositorio de katas en Google Code.

Como comparación final, les dejo otra versión del Kata de la calculadora de Strings, pero escrita en Clojure por Tom Crayford.

String Calculator Kata from Tom Crayford on Vimeo.

La campaña Anti-IF

 

Francesco Cirillo, de Italia, conocido por muchos como el creador de la Técnica Pomodoro para manejar el tiempo personal, inició tiempo atrás una campaña más específicamente orientada a los programadores:

El objetivo de esta campaña iniciada en 2007 es captar la atención en la comunidad de desarrollo sobre el abuso de técnicas procedurales en detrimento de las capacidades de orientación a objetos que los lenguajes que en general utilizamos tienen. El apuntar específicamente en contra del IF (y por extensión su derivado extremista, SWITCH/CASE) implica hacer foco en el valor del polimorfismo en lugar del abuso de condiciones que pueden expresarse en forma más clara y mantenible de otra manera.

El ejemplo canónico que presenta el sitio de la campaña es:

// Bond class
   double calculateValue() {
      if(_type == BTP) { 
         return calculateBTPValue();
      } else if(_type == BOT) { 
         return calculateBOTValue();    
      } else {
         return calculateEUBValue();
      }
   }

 

¿Cuántas veces vemos código como éste? Peor aún, es probable que nosotros mismos seamos los culpables, tiempo atrás, o no tanto...

Entre otros problema, este código viola el principio Abierto/Cerrado (Open/Close) popularizado por el tío Bob Martin, ya que cada vez que un nuevo tipo de bono aparezca tendremos que "abrir" nuevamente esta clase para ampliar el tipo de cálculo. La solución es obvia, aunque no la vemos aplicada tan frecuentemente: utilizar polimorfismo basándonos herencia (aunque pronto puede que la herencia no se tan conveniente y cambiemos a composición). Veamos la respuesta propuesta en el sitio:

// Bond class
   double calculateValue() {
       _bondProfile.calculate();
   }
// AbstractBondProfile class
   abstract double calculate()

// BTPBondProfile class >> AbstractBondProfile
   double calculate() {
       ...
   }
// BOTBondProfile class >> AbstractBondProfile
   double calculate() {
       ...
   }
// EUBondProfile class >> AbstractBondProfile
   double calculate() {
       ...
   }

 

A partir de crear una clase base con un método abstracto, respetamos el principio Abierto/Cerrado porque podemos agregar más tipos de bono simplemente agregando nuevas subclases, sin tener que tocar (necesariamente) la base.

Es interesante ver la lista de gente que apoya la campaña, entre los que se encuentran nombres conocidos como David Laribee (conocido miembro de la comunidad Alt.NET), Kent Beck (el "padre" de Extreme Programming y JNunit), Dave Nicolette (otro reconocido agilista), y muchos otros.

 

 

 

 

13 cosas que todo Programador debería saber

A principio de este año O'Reilly publicó este libro que compila 97 cosas que todos en esta profesión deberíamos saber, expresadas por una serie de profesionales de diferentes orígenes, algunos muy famosos, otros no tanto.

Lo que no me había enterado es que el libro completo surgió de un proyecto colaborativo y abierto, y que todo el contenido está disponible en línea en forma gratuita, además de muchos otros consejos que quedaron fuera del libro, pero pueden ser leído y evaluados.

En la Wiki pública del proyecto puede accederse todo este contenido, proponer colaboraciones y muchos más.

Aunque el contenido principal está en inglés, creo que es un material interesante para revisar.

Una de las preguntas más frecuentes alrededor del proyecto es ¿por qué 97? La respuesta es que apuntaban a alrededor de 100 consejos, pero no querían caer en los obvios 99 o 101, por lo que decidieron tomar el número primo más cercano: 97. Toda una muestra del espíritu nerd detrás del proyecto.

Siguiendo ese tono, traduzco los primeros 13 puntos, con sus respectivos links a la wiki (cuyos textos siguen en inglés, lamentablemente; si alguien conoce alguna iniciativa para traducir el contenido, por favor, avísenme).

1. Actúa con Prudencia por Seb Rose
   
   
2. Aplica Principios de Programación Funcional por Edward Garson
   
   
3. Pregúntate: "¿que haría el usuario?" (tu no eres el usuario) por Giles Colborne
   
   
4. Automatiza tus estándares de código por Filip van Laenen
   
   
5. La belleza está en la simplicidad por Jørn Ølmheim
   
   
6. Antes de refactorizar por Rajith Attapattu
   
   
7. Cuidado al compartir por Udi Dahan
   
   
8. La regla de los Niños Exploradores por Uncle Bob
   
   
9. Verifica tu código antes de buscar otro a quien culpar por Allan Kelly
   
   
10. Elige tus herramientas con cautela por Giovanni Asproni
    
    
11. Programa en el lenguaje del dominio por Dan North
    
    
12. Codificar es Diseñar por Ryan Brush
    
    
13. El formato del código importa por Steve Freeman