La hora de JavaScript, a tomarlo en serio

Para muchos de mi generación, los que empezamos a programar en la web 1.0 allá por fines de los ’90 comienzos de 2000, Javascript nunca fue “algo serio”. En general uno no aspiraba a ser programador JavaScript. Uno podía definirse como programador de un lenguaje en particular: Java, Php, Visual Basic, C++, etc. y en todo caso si era necesario tiraba algunas líneas de JavaScript.

Claramente los tiempos han cambiando y también JavaScript. Y en un punto las cosas se han pasado de rosca, ahora tenemos gente que directamente se define como “programadores de un framework basado en JavaScript” (react developer, angular developer, etc.) y lamento decir que he visto algunos de estos programadores que apenas si dominan JavaScript y no tienen ni idea de la diferencia en JavaScript y ECMAScript. Ojo, no pretendo hacer un juicio de valor sobre esto, tal vez pueda resultar conveniente saber de React sin tener demasiada idea de JavaScript con el fin de manejar un mayor nivel de abstracción y bajar la carga cognitiva.

En fin, hoy en día JavaScript como lenguaje está en un estado, a mi parecer, bastante maduro. Sin embargo creo que el ecosistema JavaScript aún está medio inestable. Todo el tiempo están saliendo nuevas librerías/frameworks/componentes para resolver cuestiones recurrentes. Es así que a la hora de resolver una problemática hay varias opciones de componentes/frameworks. Esto puede parecer positivo pero es también un arma de doble filo. Cuando un programador experimentado se enfrenta a varias opciones es precisamente su experiencia una cuestión central para elegir la opción a utilizar. Pero ocurre que en el mundo JavaScript hay mucho programador sin demasiada experiencia y en esos casos el tener varias opciones puede resultar más riesgoso. Cuando digo “mucho programador sin experiencia”, lo digo en términos comparativos con otros lenguajes. Cuando vemos la oferta de bootcamps y cursos de programación para gente que se está iniciando en esta disciplina, vemos que la gran mayoría en la actualidad están relacionados a JavaScript y tecnologías de frontend en general.

Al margen de todo lo anterior, hoy en día tenemos herramientas JavaScript para construir interfaces de usuario web (angular, react, vue), aplicaciones móbiles (react native, flutter), y aplicaciones/servicios server-side (nodejs). Esto hace que empiece a sonar muy atractivo tener JavaScript como lenguaje de cabecera, ya que parece esta por todos lados. Sin embargo no hay que tomar esto a la ligera porque si bien estamos hablando del mismo lenguaje de programación, cada escenario implica un stack de frameworks y herramientas distintos. Personalmente, por mucho tiempo no le di mayor importancia a JavaScript y siempre que me lo cruzaba, veía puntualmente de resolver la cuestión inmediata que tenía entre manos sin profundizar demasiado. Pero ya desde hace un tiempo he comenzado a tomarlo más seriamente, estudiándolo más en profundidad.

El Equipo Quirúrgico

(en idioma original “The Surgical Team“) Este es el título de uno de los artículos del clásico libro de Fred Brooks The Mythical Man-Month. A diferencia de otros artículos de ese libro, como The Mythical Man-Month y No Silver Bullet, este artículo no ha cobrado tanta fama pero eso no significa que sea menos genial.

En este artículo Fred Brooks desarrolla una idea previamente esbozada por Harlan Mills: resulta conveniente que los proyectos de software sean desarrollados por equipos pequeños de no más de 10 personas. Al mismo tiempo esos equipos deberían estar organizados como un equipo quirúrgico, eso es: opera una sola persona, el cirujano, que es asistido por un conjunto de especialistas (anestesista, instrumentista, etc, etc). Llevado esto al desarrollo de software, se propone que todo el diseño, desarrollo e implementación lo haga una única persona: el programador jefe (cirujano). Este programador es asistido por un conjunto de especialistas (tester, admin, toolsmith, etc).

Una versión actualizada de esta propuesta (tengamos presente que la propuesta inicial es de los ’70), podría tener un Senior Developer / Architect en el lugar del cirujano, asistido por un tester, un especialista en frontend, un especialista en backend, un dba, un sysadmin, un especialista UX, etc.

En muchos contextos esta idea puede resultar muy polémica pero al mismo tiempo en algunos otros contextos puede tener mucho sentido. Más aún, si a esta idea de cómo organizar un equipo la extrapolamos a nivel organización terminaremos con una propuesta del estilo de Team Topologies donde los equipos de producto (stream-aligned teams) toman todas las decisiones asistidos por otros equipos de especialistas (platform & enabling teams).

No deja de resultar curioso como algunas de ideas del siglo pasado vuelven a tomar vigencia luego de ser olvidadas por generaciones.

Experimento: universidad abierta 2021

El año pasado hicimos el experimento de permitir que gente externa a la universidad curse nuestra materia Ingeniería de Software en UNTreF. Quedamos muy satisfecho con el resultado y por eso este año hemos decidido repetir la experiencia. Entonces la cuestión es así:

¿Te interesa aprender un enfoque adaptativo, moderno y práctico de Ingeniería de Software?

Si la respuesta es sí, entonces considera las siguientes cuestiones:

  • La materia tiene una duración calendario de 16 semanas, comenzando en Agosto
  • Las clases se dictan los días miércoles de 18 a 22 hs (obviamente de forma online)
  • Adicionalmente a la clases se requiere una dedicación continua de alrededor de 6 horas semanales
  • Hay teoría (videos, lecturas) y también mucha práctica de programación
  • Trabajamos con tecnologías actuales como Ruby, Docker, Heroku, GitLab, etc.
  • Este artículo describe formalmente la dinámica de la materia
  • Aquí puedes encontrar varios artículos sobre el dictado de la materia en cuatrimestres anteriores

Quienes serían buenos candidatxs para participar:

  • Gente está actualmente trabajando en desarrollo de software y tiene al menos 3 años de experiencia, ya que en la materia hay una parte importante de programación pero no enseñamos a programar
  • Gente que tiene conocimiento y experiencia en desarrollo web, patrones de diseño y diseño de software en general
  • Gente que estudio algo de informática a nivel universitario pero no completó la carrera
  • Gente que completó sus estudios universitarios de informática hace un par de años pero que estudió un enfoque “tradicional” de ingeniería de software, muy teórico, posiblemente “cascadoso” y distante de la práctica de industria

Si bien no es absolutamente necesario haber tenido un paso por la universidad para participar de esta iniciativa, creemos que es un punto importante dado el nivel de exigencia. O sea, esto es un materia del último año de la carrera de Ingeniería en Computación y no hacemos distinción entre quienes cursan como parte de la carrera y la gente externa a la universidad que viene solo a tomar este curso. Un detalle no menor, esto es completamente gratuito, los participantes no deben abonar abonar absolutamente nada (en cierto modo el costo del curso ya lo está pagando el estado Argentino)

Bien, si luego de haber considerado todo lo mencionado en las líneas anteriores aún estás interesado en participar te invito a que completes este formulario contando un poco sobre ti y porque te interesaría cursar la materia, nos estaremos comunicando contigo en los próximos días.

Cambio de rumbo: de proyecto a producto

Luego de 20 años trabajando en la industria de servicios de software he decidido un cambio de rumbo a mi carrera. Prácticamente toda mi carrera he estado trabajando construyendo software o brindando consultoría/capacitación para terceros. Aproximadamente la mitad de mi carrera lo hice lo trabajando en software factories y la otra mitad trabajando de forma independiente. Si bien tuve un breve paso por Microsoft (que es una empresa de producto) mi tareas allí estaban mas relacionadas a cuestiones de asesoramiento técnico y no tenía casi ningún contacto con los equipos que desarrollaban los productos.

Desde hace unos años empezó a resultarme atractiva la idea de trabajar en una empresa de producto. Personalmente creo que trabajar en un producto tiene ciertas particularidades/implicancias en lo que refiere a ingeniería de software. Al mismo tiempo me resulta muy atractiva la idea de poder proponer cambios en el producto, poder implementarlos y ver en el corto plazo los impactos de esos cambios en el negocio.

Cuando digo empresa de producto me refiero a una empresa cuyo negocio pasa por ofrecer un producto de software o un servicio basado en producto en un producto de software. Es una definición muy amplia en la que pueden entrar organizaciones financieras (como Paypal, Mercado Pagos, Banco Nación, etc), empresas de video juegos (como EA Sport y Blizzard) y redes sociales (como LinkedIn y Facebook). Básicamente lo que no entra en esta categoría “de empresa de producto” son las empresas de consultoría y/o desarrollo( como Globant y Accenture).

A comienzos de este año empecé a explorar oportunidades en empresas de producto a las cuales sumarme en un esquema part-time. El hecho de buscar una posición part-time tiene que ver principalmente con el hecho de que tengo la intención de continuar trabajando en la universidad. Empecé por ver las búsquedas activas de ciertas empresas que me resultaban interesantes tanto por su producto como por su cultura. Si bien encontré varias posiciones posibles, todas ellas eran full-time.

Finalmente, hace poco más de un mes vi pasar un publicación en LinkedIn de una empresa que conocía, cuyo producto yo había usado un par de veces y que gente de su equipo había participado de alguno de mis cursos. No tenía idea de la cultura de la empresa, pero sabía que el producto estaba sólidamente establecido y a mi parecer con un gran potencial de crecimiento. Así que decidí postularme.

Desde entonces venimos teniendo conversaciones para definir cómo darle forma a mi incorporación. Tengo sensaciones encontradas, por un lado estoy entusiasmado con poder trabajar en este producto pero al mismo tiempo me cuesta acostumbrarme a la idea de “abandonar mi kiosquito”. O sea, en cierto modo yo tengo mi propio negocio que viene funcionando completamente a mi gusto desde hace años y eso no es algo fácil de dejar.

En fin, las conversaciones van avanzando y seguramente en las próximas semanas tendré novedades para compartir.

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.