Autor: NicoPaez

Conferencia Testing UY 2021

Este año participé por primera vez como orador en esta conferencia. Más allá de mi experiencia como orador me gustó la organización de la conferencia debido a varias cuestiones que me resultaron innovadoras sobre todo considerando que es un conferencia gratuita organizada por voluntarios.

Además de las tradicionales charlas como la que di yo (de una 1 hora de duración), había también una oferta de talleres (en general de carácter muy práctico y con cupo limitado) y charlas relámpago.

La conferencia se desarrolló durante toda la semana. Los talleres se dictaban durante la mañana/mediodia y primera hora de la tarde. Las charlas tenían lugar por las tardes en horario «after office».

Más allá de las actividades de contenido, había sorteos y un desafió de testing en equipos. La transmisión de las charlas se hizo por Zoom y todas ellas (las charlas, no los talleres) serán publicadas en el canal de YouTube de la organización.

Como ya es costumbre en tiempos de pandemia, había también un discord a modo de «espacio social».

Un detalle que me resultó muy interesante es que a pesar de ser un evento «latino» hubó varias presentaciones de otros lugares del mundo, varias de ellas en inglés.

Tuve la oportunidad de participar de varias charlas entre las que se destacaron a mi gusto: la de Guillermo Skrilec sobre el testing de la aplicación de vacunación en Uruguay, la de José Luis Velázquez Jacobo sobre testing de sistemas de conducción asistida y la de Federico Toledo y Matias Fornara sobre calidad de pruebas automatizadas.

Las diapositivas de mi charla está disponibles aquí.

Mis felicitaciones y agradecimiento a los organizadores, creo que ha sido un gran evento, de los mejores de la región.

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.