Mes: junio 2021

Bootcamps, academias y demás iniciativas ante la falta de programadores

A partir del déficit de profesionales informáticos en Argentina, en los últimos años muchas organizaciones están apuntando a contratar gente más jóven, sin experiencia y formarlos «en casa». Los nombres que toman estas iniciativas son variados: bootcamp, training camp, escuelita, academia, etc, etc. En términos generales estas iniciativas consisten en conformar un grupo de jóvenes, generalmente con muy poca o nula experiencia y entrenarlos durante X semanas/meses antes de incluirlos en los equipos de desarrollo de la organización.

Tal es el auge de estas iniciativas que en lo que va del año me contactaron 3 organizaciones para que los ayude a armar sus bootcamps/academias. En los 3 casos las propuestas iniciales me parecieron desacertadas por diferentes cuestiones tanto desde el punto de vista didáctico como operativo. En los 3 casos hice una propuesta alternativa y a mi entender superadora.

Hasta el momento en solo un caso mi propuesta fue aceptada y puede implementarla. El resultado fue muy positivo tanto para los jóvenes participantes como también para organización contratante. Yo personalmente también quedé muy conforme, incluso cuando algunas cuestiones no fluyeron de la forma que yo esperaba. Meses después de haber completado el entrenamiento y estando los jóvenes ya incorporados a equipos de trabajo en la organización pude confirmar que el objetivo del entrenamiento se había cumplido.

En los otros dos casos ni siquiera llegué a enviar una propuesta económica, solo comenté como sería mi enfoque y me dijeron que mi propuesta les resultaba interesante, que la evaluarían internamente y me volverían a contactar.

Tengo varios reparos sobre este tipo de iniciativas, creo que bien direccionadas pueden resultar muy beneficiosas para las organizaciones y también para jóvenes profesionales. Pero también puede ocurrir que de no tomar ciertas precauciones en el diseño e implementación terminen resultando en un pérdida de dinero para organización y una frustración para los jóvenes.

Si alguien está trabajando en un iniciativa de este tipo y necesita ayuda, me puede invitar un cafecito y lo charlamos.

Los alumnos sobre Mob-Programming y TDD

En MeMo2 @ingenieriauba hacemos un primer TP grupal en el que los alumnos deben evolucionar una webapp existente siguiendo un proceso XP-like (iteraciones semanales, planning, review, retro, CI/CD, DDD, BDD/TDD, etc).

Entre las cosas que más énfasis hacemos y que más les cuesta (o que más resistencia le ponen) los alumnos está el desarrollar guiados por pruebas (bdd/tdd) y trabajar todo el tiempo haciendo Mob-Programming (o al menos pair-programming). También les pedimos que hagan Trunk-Based development.

TDD es algo que ya han visto en alguna materia anterior pero de una forma mucho menos profunda que lo que proponemos en MeMo2. En general los alumnos tiene una buena recepción porque nuestra propuesta de BDD+TDD ofrece una guía muy detallada de como transitar el proceso de construcción desde la intención del usuario hasta el código que implementa esa intención en un ambiente donde el usuario puede utilizar la pieza de software construida.

La propuesta de Mob/Pair-Programming les resulta más «rara», sobre todo a los que ya vienen con experiencia laboral. Posiblemente varios de los que ya trabajan en desarrollo no tendrían el visto bueno de sus jefes si pretendieran trabajar todo el tiempo (o la mayor parte) haciendo Mob/Pair Programming. Por esto es que insistimos tanto en que hagan Mob-Programming, si no lo prueban en nuestra materia, es posible que tampoco lo puedan probar en sus trabajos.

Algo similar ocurre con el uso de Trunk-Based development. Muchos de los que ya trabajan suelen utilizar feature-branches (como creo que hace gran parte de los desarrolladores actualmente) y entonces «temen» trabajar todos simultáneamente sobre el mismo branch. La clave aquí de nuestra propuesta es que al trabajar haciendo mob-programming solo hay un único branch de desarrollo activo, con lo cual resulta natural hacer trunk-based development. Al mismo tiempo y más allá de hacer mob-programming, nosotros insistimos en trabajar en pequeños incrementos haciendo commits al trunk/master cada 20 o 30 minutos como máximo, con lo cual las chances y el tamaño de divergencia al trabajar se reduce mucho, llevando casi a cero el tiempo requerido en arreglar conflictos de merge.

El jueves pasado al finalizar la segunda iteración del trabajo grupal hicimos una actividad con los alumnos para relevar cuanto habían usando las técnicas recomendadas y cuán útiles les habían resultado.

Los siguientes gráficos muestran el resultado de la actividad.

Mi sensación es que la mayoría de los alumnos «compra» nuestra propuesta. Veremos que opinan al finalizar el siguiente TP que reviste una complejidad mucho mayor y donde creo que estas técnicas suman aún más valor.

Hasta siempre @AJLopez

Hace un par de semanas nos dejó Angel «Java» Lopez (@ajlopez), quien es considerado por muchos (yo incluido) como un referente de la comunidad informática de Argentina.

A lo largo de mi carrera me crucé muchas veces con Ángel. La primera fue allá por los años 2000 cuando yo estaba aprendiendo programación web, me anoté en un curso de Php en el que Ángel era el docente.

Tiempo después, hacía 2004 cuando yo estaba metido de lleno en el mundo .net recuerdo haber tomando un curso con Ángel en el que explicaba Object-Relational Mapping con OBJ.NET.

Buceando en mi blog encuentro registros de distintos eventos y actividades en las que participé junto
Ángel. En algunos casos como oyente de alguna charla facilitada por él y en otros en los que compartí la grilla de oradores.

Recuerdo especialmente una charla en UNQui, no recuerdo el nombre de la charla pero recuerdo claramente que Ángel mostraba como había implementado un intérprete de Smalltalk con JavaScript.

Tuve la suerte de coincidir en con Ángel en mi paso por Southworks hace unos 10 años. Recuerdo verlo llegar a la oficina con una bolsa de libros y un cuaderno donde tomaba notas de lo que leía. Siempre vestido con camisa y jeans. Siempre colaborativo, dispuesto a dar una mano, a aprender y compartir.

Recuerdo también por aquella misma época de Southworks un meetup sobre TDD con un picante debate entre Ángel y Hernán Wilkinson, sobre el tamaño del paso al hacer TDD.

Una frase habitual en sus presentación era:

Don’t be canuto

@ajlopez

Ángel solía decir esta frase en referencia a compartir el conocimiento, algo que él hacia constantemente desde sus charlas, sus cursos, sus blog y sus redes. Gracias Ángel, ya te estamos extrañando.

Para quienes no tuvieron la suerte de conocerlo les recomiendo que se den una vuelta por espacios en la web:

Experimento: Fiuba meets Discord

Estamos promediando el cuatrimestre, completamos la novena semana de clases y con ello cerramos la primera parte de MeMo2. Hasta aquí los alumnos estuvieron trabajando de forma individual estudiando, aprendiendo y practicando diversas técnicas para poder trabajar en equipo durante la segunda parte de la materia.

Es aquí donde entra Discord, este cuatrimestre hemos decido habilitar un servidor Discord para que los equipos de alumnos puedan trabajar sincrónicamente haciendo mob programming. Discord es una plataforma de colaboración similar a Slack, Microsoft Teams y otras tantas. Ofrece salas de video y de audio que emulan de forma virtual a salas físicas. El usuario puede estar en una sala de audio a la vez. Al mismo tiempo las salas de audio no tiene espacio de texto sino que los usuario «entran» con cámara y video y tienen la posibilidad de compartir pantalla.

El trabajo en equipo es un proyecto de desarrollo con alcance variable y esfuerzo fijo. Pedimos a los alumnos trabajar 6 horas semanales (extra clase) pero haciendo (dentro de lo posible) mob-programming todo el tiempo. En las próximas semanas veremos si también probamos Discord para las clases en vivo pero sabemos que esto puede resultar más complejo ya que tenemos colegas que han reportado inestabilidades en la suscripción gratuita de la plataforma. De todas formas, como nosotros tenemos pocos alumnos creemos que podría andar bien.

El mayor impedimento para una iniciativa DevOps

Si bien el término DevOps no lo explicita, toda iniciativa DevOps requiere del apoyo e involucramiento de negocio, pues la razón central de DevOps es poder dar respuesta rápida y consistente a las necesidades del negocio.

Si el negocio no se sube al barco de la iniciativa DevOps las probabilidades de éxito y sus beneficios estarán fuertemente limitados. Toda iniciativa DevOps requiere de cierta inversión, ya sea a nivel de capacitación, compra de herramientas o simplemente horas-hombre. Si el negocio ve a IT como un centro de costos difícilmente estará dispuesta a hacer la inversión en DevOps.

Desarrollo y Operaciones pueden tener las mejores intenciones, pueden colaborar de forma muy fluida, pueden incluso ser un mismo equipo, pero nada de eso alcanza si el negocio sigue viendo IT como un centro de costos.

Las empresas que logran implementaciones exitosas DevOps son aquellas que ven IT como una área estratégica, capaz de habilitar oportunidades de negocio, capaz de impactar en la performance del negocio/organización y de proveer un valor diferencial de cara al mercado.

En más de una ocasión me he encontrado trabajando con áreas de IT, tratando de armonizar la relación entre desarrollo y operaciones, pero sin contar con el apoyo suficiente del negocio. Así y todo es posible implementar algunas mejoras, pero difícilmente se logren los plenos beneficios de una cultura DevOps.

Mob-Programming, una práctica para probar

Remote Mob-programming figura entre las técnicas recomendadas para «considerar» (assess) en la edición de abril 2021 del Technology Radar de Thoughtworks y eso me motivó para comenzar escribiendo algunas ideas/definiciones sobre Mob-programming, en otro artículo hablará sobre las particularidades que agrega el componente Remote.

Mob Programming es un práctica a mi entender aún no muy difundida. Se cuenta que la práctica fue inicialmente utilizada por algunos equipos de XP allá por los años 2000, pero no fue hasta ~2014 que empezó a cobrar más popularidad a partir de la difusión impulsada principalmente por Woody Zuill. Fue precisamente de la mano de él que yo conocí la práctica en la XP 2016 en Edimburgo.

All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer

Woody Zuill

En términos resumidos propone que todo el equipo trabaje en conjunto con una sola computadora. Dicho de otra forma, mob-programming es externder la idea de pair-programming a todo el equipo. En cierto modo, es posible que mucha gente considere que en algún momento ha aplicado mob-programming, pero muy posiblemente no sea así porque mob-programming implica ciertas cuestiones como ser:

  • Mob-programming implica cierta dinámica del grupo donde los miembros asumen distintos roles a lo largo del tiempo
  • Mob-programming propone que todo código productivo sea escrito haciendo mob-programming lo cual se traduce a que los miembros del equipo pasan casi todo su tiempo haciendo mob-programming.

Este último punto es el que suele generar cierta resistencia: que todo el equipo esté trabajando en una tarea por vez. Esta resistencia en ocasiones viene de parte de la gerencia pero en muchas ocasiones viene de los propios programadores. De hecho, en algunos contextos hay incluso rechazo al pair-programming. Veo muchos programadores que prefieren trabajar en una dinámica de solo-programming con feature-branches y merge-request aún cuando eso implique tener que lidear con merges y tiempos de espera para tener su código integrado a la rama principal de desarrollo.

Es interesante mencionar que en el contexto de Extreme Programming se propone que todo el código productivo se haga trabajando en pair-programming. En mi experiencia, pair-programming es un práctica de relativo poco uso en el sentido de que quienes la utilizan no la utilizan todo el tiempo (como propone XP) sino en situaciones muy puntuales donde la tarea en cuestión reviste de cierto grado de complejidad/riesgos.

En mi trabajo como coach/mentor casi todo el tiempo que estoy programando lo hago haciendo mob o pair programming.

El uso de mob-programming tiene ciertas consecuencias interesantes:

  • Como todo el equipo está trabajando en una misma tarea, hay una sola rama de desarrollo (trunk-based development) por lo cual no hay que lidiar con merges.
  • El código es revisado mientras se escribe así que no hay tiempo de espera de revisión
  • Todo el equipo está familiarizado con todo el código
  • Es muy fácil la gestión del Work-In-Progress ya que está automáticamente limitado a 1

Les dejo aquí algunos recursos para quienes quieran profundizar en estos temas:

En próximos post contaré mis experiencias aplicando esta técnica.