Categoría: opinion

Nuevo plan de Ingeniería Informática en FIUBA (2023)

Finalmente el martes pasado, 8 de agosto, el Consejo Directivo de la FIUBA aprobó el nuevo plan de estudios de la carrera de Ingeniería en Informática. Esto ocurre en el contexto de la iniciativa «Plan 2020» en la cual la facultad se propuso generar nuevos planes para todas sus carreras, pero que por motivos diversos, llega con años de retraso.

El lo personal no estuve involucrado en la creación de este nuevo plan, es una tarea de la Comisión Curricular de la carrera de la cual yo no formo parte. Pero como docente del departamento de computación suelo recibir consultas de los alumnos respecto de la carrera en general. Es por ello que comparto aquí algunas opiniones respecto de este nuevo plan.

Cabe destacar que tiempo atrás escribí sobre un borrador de plan que se había compartido, pero había sido elaborado por otra comisión, o sea: el plan se empezó a trabajar con una determinada formación de la comisión curricular y un director pero el plan publicado ahora fue creado por una comisión liderada por otro director de carrera y otros miembros. Y si bien algunos miembros se mantienen, no estoy seguro de hasta qué punto esta comisión mantuvo el trabajo realizado por la anterior o hasta que punto, hicieron borrón y cuenta nueva.

En primer lugar hay un cambio significativo respecto de las cuestiones de ciencia básica. No hay ninguna materia de química (ni siquiera en el CBC) y solo quedan dos materias de Física: la del CBC y una nueva materia llamada «Física para Informáticos». También hay algunos cambios menores en las materias de matemática.

Por otro lado, en cuestiones de informática, hay varias cuestiones a notar, detallo algunas materias:

  • Introducción al Desarrollo de Software: me parecen interesantes los contenidos que plantea de forma temprana en la carrera, me gusta que ya tempranamente habla de Desarrollo Orientado por Pruebas (asumo que se refiere a TDD). No me gusta tanto la mención explícita a front-end y back-end pues me parece que es una cuestión tecnológica «de moda».
  • Paradigmas de Programación: entiendo que se la considera equivalente a Algo3 pero no lo veo tan así pues por un lado incluye cuestiones de otros paradigmas más allá de OO y al mismo tiempo no veo ninguna mención a cuestiones de ing. de software (nada de TDD, ni unit testing y tampoco patrones)
  • Ingeniería de Software 1: parece que algunas de las cuestiones que «sacaron de algo3» las metieron aquí, puntualmente las cosas de diseño, oo, patrones. Creo que quedó más parecida a la materia de Ingeniería de Software 1 que se dicta en Exactas. Yo la veo distinta a MeMo 1 en parte por contenido y también porque es una materia 8 créditos (MeMo 1 es de 6).
  • Ingeniería de Software 2: pinta como lo que vengo dando en MeMo2 (de hecho los contenidos mínimos son los mismos) pero tiene 8 créditos cuando MeMo2 tiene 6. Intentaré averiguar que onda.
  • Taller de programación: sus contenidos mínimos me suenan muy distintos a los de la materia que se dicta actualmente y me resulta intrigante cómo se plasmaran en un curso.
  • Empresas de Base Tecnológica: la 1 me parece como un mix de varios temas «de materias de Las Heras» (en general en Las Heras se dicta materia de organización/gestión). La 2 pinta mejor, trae algunas cuestiones de innovación, startups, etc.
  • Gestión del Desarrollo de Sistemas Informáticos: entiendo que esto es lo que viene dictando Carlos Fontela en la materia de gestión de proyectos que dicta actualmente. Pinta bien aunque me llama la atención lo de «Análisis del Impacto Socioambiental» (según averigué es un lineamiento de la facultad que todas las carreras tengan algo de esto)
  • Taller de Seguridad Informática: me parece bien que se haya puesto esta materia, creo que seguridad es un tema muchas veces postergado. Los contenidos son debatibles pero por algo hay que empezar.
  • Electivas: veo muchas que me suenan a «data / machine learning» y solo arquitectura de software del área de Ingeniería de Software. No vi ninguna materia relacionada a operaciones, infraestructura, data centers, etc, cosa que si había en alguna versión preliminar del plan.

En lo personal creo que es un buen plan, mucho más adecuado a los tiempos actuales que el plan anterior. También creo que está mucho más enfocado en cuestiones de informática (y no tantas generalidades de ciencia básica). Por último pero no menos importante, el plan tiene una estructura distinta que entre otras cosas elimina las orientaciones y que constituye una carrera más corta (al menos en los papeles): son en total 10 cuatrimestres incluyendo el ciclo de ingreso.

Este nuevo plan se pondrá en funcionamiento este segundo cuatrimestre de 2023 con la oferta de 3 materias aún cuando falta la aprobación del Consejo Superior de la UBA, cosa que debería ocurrir en las próximas semanas.

Actualización 2023-09-08: el plan ya es oficial, fue aprobado por el consejo superior. Aún no lo actualizan en la página de la facultad pero se puede descargar desde la página de UBA, aquí.

Nuevo proyecto: refactoring, Python y OpenAI

Esta semana comencé a trabajar en un nuevo proyecto. En términos simples voy a acompañar a un grupo de devs en el refactor de una de sus aplicaciones. A la pasada vamos a revisar algunas cuestiones de diseño, arquitectura, testing y posiblemente a la pasada veremos un poco de TDD.

Venía intentando escaparle a la ola de AI, pero ya no más pues este proyecto trabaja con OpenAI, así que, más obligado que por gusto, me toca meterme en este mundillo.

El refactor surge a partir de la necesidad de agregar ciertas nuevas funcionalidades que con el diseño actual podrían resultar no tan fáciles de introducir. Entonces la idea es seguir la estrategia de Beck: «for each desired change, make the change easy (warning: this may be hard), then make the easy change» o sea:

  • primero vamos a refactorizar el código existente para facilitar la implementación de las nuevas funcionalidades
  • a partir de esa refactorización vamos a poder agregar algunos test «chicos/unitarios» ya que el código solo tiene pruebas «grandes/de aceptación» que son caras y no ofrecen suficiente cobertura
  • una vez finalizado el refactor y agregados nuevos tests, avanzamos el desarrollo de la nueva funcionalidad
  • bonus track: el desarrollo de la nueva funcionalidad lo hacemos guiado por tests (tdd)

Continuará…

Notes and resources of my talk at #Agile2023

Last Thursday afternoon I delivered my talk «Technical Practices Walkthrough for non-technical People» at Agile 2023 Conference.

The session was attended by an enthusiastic audience of over 100 participants, and I was delighted to see that nearly everyone stayed engaged until the very end. From the positive atmosphere in the room, I believe it was a successful and impactful session. I am glad to share that I accomplished all the objectives I had planned for the talk.

Overall, I feel gratified by the experience and want to express my gratitude to the Agile 2023 Conference organizers for letting me share my knowledge and insights.

At the end of the session I gave away some of my books (both in Spanish: Construcción de Software, una mirada ágil y Experiencias ágiles).

Here you have some resources I mentioned/used during the talk:

  • The slides are here
  • One of the books I gave away at the end of the session is available for free to read online here
  • The application I used to perform the demo is online at https://jobvacancy.com.ar
  • In this article, I describe a case were I combined the use of slicing feature toggles.

Picture of the audience minutes before starting the session

Sobre la Guia Oficial de eXtreme Programming

En Scrum que existe una guía oficial que los autores mantienen actualizada. También existe una organización (en realidad creo que más de una pero la que conozco yo es la Scrum Alliance) que ofrece certificaciones de Scrum. En este sentido es razonable pensar que quien se acercó a Agile con Scrum, luego quiera acercarse a Extreme Programming (XP) y busque la guia oficial de XP.

Pero en XP no hay guía oficial, perdón si llegaron a este post buscando esa guía oficial. Al menos ahora saben que no existe :-). Tampoco existe una certificación oficial de XP, ni una XP Alliance.

En términos de publicaciones creo que los más cercano a una guía oficial es la serie de libros «XP Series» de la editorial Addison-Wesley publicada entre 1999 y 2005. En dicha serie se incluye el libro fundacional de XP escrito por Beck: «Extreme Programming Explained, Embrace chance» que a mi parece no es el mejor libro de la serie. No leí todos los libros de la serie en parte porque no pude conseguirlos, varios de ellos están discontinuados, de hecho algunos los conseguí usados. Dos libros que me parecieron excelentes fueron «Planning Extreme Programming» de Beck y Fowler y «Extreme Programming Installed» de Jeffries, Anderson y Hendrickson.

Por otro lado, un libro que a simple vista no parece de XP pero que definitivamente lo es, es el libro de James Shore «The Art of Agile Development«. La segunda edición, publicada en 2021, creo que es una descripción muy acertada de lo que podría considerarse un «XP Moderno».

En lo personal, creo que cada vez tiene menos sentido hablar de «métodos/marcos/metodologías» de desarrollo de software. Podemos debatir valores, principios, mindsets y luego bajar a prácticas concretas en las que materialicemos esos valores pero no necesitamos un rótulo para eso. Creo que las combinaciones pre-armadas de «valores + principios + prácticas» empaquetadas bajo un rótulo pueden agregar valor para un equipo/organización que recién empieza, pero a medida que conformamos grupos de trabajo más estables los «combos» agregan cada vez menos valor por el simple hecho de que el grupo de trabajo se convierte en un equipo y empieza a generar sus propias prácticas.

Cierre de cuatrimestre 2023-1 en MeMo2 @ FIUBA

Cerramos un cuatrimestre más con algunas particularidades. Una de las más destacadas fue el horario de cursada: dimos la materia en horario matutino de 8 a 11 hs. Otra de las particularidades fue la relación entre la cantidad de alumnos y la cantidad de docentes que nos permitió dar feedback bastante detallado en las entregas de los alumnos.

El feedback de los alumnos en la encuesta de cierre la cual nos arrojó los siguientes números:

  • La encuesta fue contestada por la totalidad de los alumnos que completaron el curso (10)
  • La evaluación general de la materia (en promedio) dio: 8,8 lo cual es menor que el cuatrimestre anterior (9,1) pero es mayor al promedio histórico (8,4). Adicionalmente el desvío fue mínimo: nadie calificó la materia con menos de 8.
  • Respecto del porcentaje de clases presenciales/virtuales, 9 alumnos lo consideraron apropiado mientras que solo 1 hubiera preferido más virtualidad.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,6/5; Conocimientos de los docentes: 5 /5; Dinámica de las clase: 4,4/5; Materiales de estudio: 4/5.
  • El NPS nos dio 60 (esta es una métrica que puede tomar valores en el rango -100 +100, con lo cual un 60 es muy bueno)

De la restrospectiva de cierre nos quedamos con los siguientes accionables:

  • Agregar un ejercicio individual con el bot para familiarizarse antes del TP2
  • Dar un video o clase mostrando el flow de desarrollo guiado por pruebas desde el bot hasta la api
  • Dar la opción de usar infra gratuita o paga (por los propios alumnos) y considerar también que los propios alumnos gestionen su infra

Algunos otros números:

  • Respecto a la dedicación, tuvimos 28 clases de entre 2 y 3 horas cada una. Por otro lado la dedicación extra clase, en promedio por alumno, fue de un total de 116 horas (51 horas de tareas individuales, 12 horas de tp1 y 53 horas de tp2) repartidas en 16 semanas. Esto nos da unas 7,25 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre. Claro está que en este promedio hay semanas de 2 horas de dedicación extra clase y hay otras de 15 horas.
  • Tuvimos 42 tareas individuales, 1 en parejas y 2 TPs.
  • Tuvimos 14 inscriptos, solo 11 que asistieron alguna clase y finalmente 10 que aprobaron la cursada.
  • La nota promedio de aprobación de cursada fue 8.

Guía Oficial de Scrum, ¡chau!

En mis materias vengo utilizando la Guía Oficial de Scrum pero a partir de dos charlas distintas que tuve con colegas en la última semana he decidido dejar de usarla.

Resulta que una de las modificaciones «recientes» de la guía oficial de Scrum es que elimina los roles. En realidad no elimina los roles conceptualmente, sino que elimina el término «rol» y en su lugar habla de responsabilidades (accountabilities), o sea: «Scrum Master» es un conjunto de responsabilidades, «Product Owner» es un conjunto de responsabilidades, etc. Según me comentaban mis colegas expertos en Scrum (cosa que yo no soy) es para evitar la usual creencia de que las responsabilidades de Scrum Master deben ser tomadas por una única persona y que esa persona debe dedicarse de forma exclusiva a ello. Pero precisamente eso es un rol, «un conjunto de responsabilidades». Entonces si conceptualmente hablamos de roles pero no queremos usar el término roles, creo que lo que se está haciendo es una «precarización» del vocabulario y al mismo tiempo se genera ruido y confusión para aquellos que sabemos lo que es un rol.

Por otro lado tengo la sensación que la guía cada vez tiene menos cuestiones relacionadas al desarrollo de software, posiblemente consecuencia del uso de Agile/Scrum fuera de contexto de IT. Pero dado que lo que estudiamos en mi materias es desarrollo de software, estas nuevas versiones de la Guía de Scrum, me resultan cada vez menos útiles.

Es por esto que de ahora en más ya no usaré la guía oficial de Scrum como material de estudio sino (algunos de) los siguientes materiales:

  • El artículo «Scrum Development Process» de Ken Schwaber de los años 90
  • El libro «Scrum and XP from the treches» de Henrik Kniberg
  • El resumen de Scrum de mi libro «Construcción de Software»

De Chicago a Londres, artículo aceptado

En línea con la estrategia de enseñanza de TDD que seguimos en FIUBA y UNTreF, escribí este artículo que fue aceptado en el Simposio Argentino de Educación en Informática de las Jornadas Argentinas de Informática, JAIIO 52. Al margen de la presentación del artículo que haré en el contexto del Simposio, tengo planeado hacer un charla abierta (meet-up online) para compartir esta experiencia. Si están interesados esten atentos a este canal.

La paradoja de los Ingenieros de Software

Es habitual hoy en día encontrar gente «autodenominándose» Software Engineer sin tener un título formal de ingeniero o disciplina universitaria aledaña. Personalmente no creo que sea una cuestión relevante pues a diferencia de lo que ocurre con otras ingenierías, la ingenieria de software no es una disciplina regulada, o sea: para construir un puente es necesario el aval legal de un ingeniero civil pero para construir un software no es necesario el aval legal de un ingeniero de software.

Por otro lado, algunos de los que somos Software Engineer «con título», dudamos de la denominación «ingeniero» o mejor dicho dudamos de que el Desarrollo de Software deba ser considerado formalmente una ingeniería. He aquí la paradoja:

No ingenieros que quieren ser ingenieros e ingenieros que dudan de serlo

Varios referentes de la disciplina se han pronunciado respecto de este dilema, uno de ellos es David Parnas en su artículo «Software Engineering – Missing in Action: A Personal Perspective«. Otro autor que trata la cuestión es Pete McBreen en su libro Software Craftsmanship.

Esta visión «ingenieril» del desarrollo de software llevó a que las carreras de Ingeniería Informática/Sistemas en Argentina tengan varias materias de ciencia básica (física y química entre otras) compartidas las demás ingenierías. En lo personal y viendo la carrera que yo cursé me hubiera gustando tener menos contenido ciencia básica y más contenido de específico de informática.

En fin, los años pasan y la polémica se renueva.

Role Smell: Test Automation Engineer

Este es un rol viene ganando cada vez más popularidad desde el auge de DevOps. Ocurre que en muchas organizaciones el testing lo realiza gente que no sabe programar y por ende no puede automatizar los tests que realizan (en realidad es posible utilizar herramientas del tipo record & play, pero en general esa estrategia tiene muchas limitaciones).

En un par ocasiones trabajé con equipos donde había gente en este rol y sinceramente no me pareció una buena idea. En todos los casos la dinámica de trabajo era:

  • en primera instancia un tester (o varios) definía los casos de prueba y los ejecutaba manualmente
  • luego, generalmente en la siguiente iteración, un automatizador (test automation engineer) se encargaba de automatizar algunos de los casos de prueba previamente definidos

De entrada esto me hizo recordar a la época en que una persona hablaba con el usuario (analista), escribía un documento de casos de uso y luego otra persona (desarrollador) leía el documento y programaba la funcionalidad. Si bien aún hoy hay equipos trabajando de esta forma creo que son minoría. Por algo será.

Otra cuestión que me resultaba poderosamente llamativa era la desconexión total entre estos automatizadores y los desarrolladores.

También ocurría que si en una determinada iteración no había trabajo de automatización, esos automatizadores, a pesar de saber programar, no se ponían a programar la aplicación.

Finalmente lo que para mí resultaba más perjudicial: toda la automatización de pruebas quedaba en manos de estos automatizadores, o sea: los desarrolladores no escribían ningún tipo de prueba automatizada, ni siquiera unitarias. Es bien sabido que para tener un buen flujo de entrega continua es necesario tener pruebas automatizadas, pero también es necesario que parte de ese trabajo de automatización lo hagan los propios desarrolladores comenzando por las pruebas unitarias.

En fin, no digo que tener un rol de Test Automation Engineering sea algo malo ni incorrecto. Solo digo que las dinámicas de trabajo que he visto en equipos que tienen personas en dicho rol, no generan un buen flujo de entrega continua. No digo que siempre sea así, pero sí lo fue en los casos que vi de cerca. Dicho esto, mi recomendación es que si tienes en tu equipo una persona en este rol o estás pensando en incorporarla, tal vez deberías detenerte un momento a pensar en la dinámica de trabajo del equipo.

De feature-branches y Pull-Request a Continuous Delivery

El uso de feature branches en conjunto con pull-request es una práctica muy habitual en la actualidad, a pesar de que en general termina siendo un impedimento para implementar Continuous Delivery. Esto resulta en gran medida curioso porque mucha gente que utiliza feature branches y pull-request cree que hace Continuous Delivery.

Por definición Continuous Delivery implica Continuous Integración lo cual a su vez implica Trunk-Based Development, o sea: no hacer branches que duren más de un día. Siendo conceptualmente estrictos uno podría hacer feature-branches & pull-request y aún así hacer Continuous Delivery, pero entonces los branches y pull-request no deberían extenderse más de un 1 día, situación que no condice con lo que suele verse en la industria mayoritariamente en la actualidad.

Desde hace varios par de meses vengo trabajando con un equipo muy maduro en un sistema que ya está productivo hace años. Trabajan con una dinámica de feature-branches, pull-requests bloqueantes y puesta en producción al final de la iteración. Dado que la iteración dura 2 semanas, esta dinámica implica que todo ítem, por simple que sea, tardar 2 semanas en llegar a producción. A su vez esto provoca que cada release a producción sea bastante grande pues contiene todo el trabajo acumulado durante 2 semanas. Y obviamente, cuanto más grande, más riesgoso. En parte como consecuencia de esto cada release a producción implica un downtime del sistema lo que obliga notificar a los usuarios sobre el tiempo de downtime y al mismo tiempo obliga que el release se realice fuera del horario de oficina para así afectar lo menos posible a los usuarios.

Dado que a mi parecer el equipo está bien consolidado, cuenta con un interesante set de pruebas automatizadas, el producto está estable, hay un proceso formal de testing y release, considero que están en condiciones de transicionar a un esquema de Continuous Delivery y por ello la semana pasada le propuse hacer un experimento. La propuesta es identificar un par de items de backlog, de bajo riesgo, para liberarlos (ponerlos en producción) tan pronto estén listos. De esta forma se entrega valor al negocio más rápidamente y al mismo tiempo el release de fin de iteración es más pequeño y menos riesgoso.