En la primera mitad de año casi no participé de académicos ni comunitarios. Sin embargo para la parte final de este 2025 ya tengo varios agendados.
De entrada la semana próxima voy a estar participando de Testear.la, evento en modalidad mixta online/presencial organizado por los amigos de Crowdar. Ahí estaré estrenando charla: «BDD: Lecciones de +10 Años en la Trinchera» (miércoles 10/9, 11:40 hs, presencial). En ese mismo contexto también estaré dando mi taller «Principios y Patrones para el diseño de Pipelines» (jueves 11/9, 11:20 hs, presencial).
Luego estaré comenzando la primera con el clásico Nerdearla @ Baires, del 23 al 27 de septiembre 2025, presencial y online. Aquí no daré charla, seré 100% expectador. Donde sí voy a dar una charla es en el Nerdearla @ Madrid, del 13 al 15 de noviembre, presencial y online. Ahí estrenaré mi charla «Patrones de Diseño: de vuelta a la bases«.
Finalmente, estaré cerrando el año en casa, Facultad de Ingeniería UBA, donde se llevará a cabo la Smalltalks 2025. No estoy seguro si presentaré alguna charla (por el momento no mandé propuesta), pero igualmente ya sé que iré de espectador.
Sin duda Agile, y más específicamente XP, hicieron esto, pero no fueron los únicos.
En la época «pre-agile«, el testing estaba en manos de un grupo de personas «externas» al equipo de desarrollo. Agile cambio esto en varios sentidos, por un lado puso de relieve el testing como un trabajo de todos y junto con eso puso gran parte del testing en manos de los developers. Al mismo tiempo puso a los testers a trabajar codo a codo con los developers dentro del equipo de desarrollo y a la pasada cambió las tareas cotidiadas de los testers incluyéndolos en otras cuestiones como ser las plannings y los refinamientos, etc. Hasta aquí creo que no hay novedad, cualquier practicante en la actualidad sabe esto (consciente o inconscientemente).
Pero hay otro hecho que me parece ha pasado desapercibido. Resulta que estoy ayudando a un equipo de un cliente a mejorar su proceso de delivery y en ese contexto estamos agregando tests automatizados, cosa que el equipo nunca hizo. Su solución consiste en una aplicación móvil construida con Ionic y un conjunto de servicios construidos con node/loopback. Personalmente había hecho algunas cosillas con Ionic pero nunca había trabajado con Loopback. Para mi sorpresa, ambos framework traen soporte (guias, ejemplos, etc) para hacer pruebas automatizadas de distinto tipo. Más aún, el scaffolding de Ionic ya genera el esqueleto de pruebas cuando uno genera un componente. Esta sorpresa me hizo caer en la cuenta que hoy en día la gran mayoría de los frameworks de desarrollo ya traen soporte, documentación y ejemplos para hacer pruebas automatizadas. Esto que puede parecer «normal» en la actualidad pero creanme que no era así hace ~20 años cuando yo empezaba a dar mis primeros pasos con automatización de pruebas. Recuerdo varios proyectos lidiando para agregar pruebas a aplicaciones AspNet/C#.
Creo que unas de las herramientas pioneras en este sentido fue Smalltalk (¿squeak?) y luego Rails. Me parece que hoy en día todo frameworks/sdk viene con soporte para hacer pruebas automatizadas: Rails, Django, Java/Spring, NetCore, Nest.js, Next.Js, Android Sdk, por nombrar algunos populares. Es cierto que tal vez no todos los developers escriben pruebas, pero el hecho que las herramientas los habiliten representa una posición de la industria: los developers deben escribir pruebas y es de esta forma el testing se ha convertido en un ciudadano de primera categoría.
El próximo mes de septiembre estaré participando en la conferencia Testearla organizada por la gente de Crowdar (JaviRe y sus colegas).
La conferencia será 9 y 10 de septiembre, el 9 online y el 10 presencial en Plaza Galicia (Ciudad de Buenos Aires). La entrada es gratuita pero requiere registración. Al margen de la agenda de sesiones, que se ve muy interesante, en el evento también habrá espacios de networking.
Adicionalmente, el 11 habrá una jornada intensiva de entrenamiento de la cual estaré participando. Habrá 4 sesiones y yo daré una de ellas. Mi sesión será «Principios y Patrones para el diseño de Pipelines», veremos la teoría y la pondremos en práctica con algunas herramientas. Será la primera vez que dicte este sesión, pues si bien parte del contenido suelo darlo en mi materia de Ingeniería de Software, para este caso agregaré algunas cuestiones nuevas surgidas de mis últimas experiencias. Esta jornada de entrenamiento tiene cupos limitados y es paga.
Desde hace varios años en mi curso de Ingeniería de Software @ UNTreF venimos usando Ruby como lenguaje de programación. Una elección con la que estábamos muy conformes. Pero el cambio de plan de estudio del año pasado, cambió radicalmente el perfil de nuestros alumnos y ello nos llevó a replantear varias cuestiones de la forma en que dictamos la materia. Entre ellas el lenguaje de programación.
Dado el perfil de los alumnos pensamos que trabajar con un lenguaje de tipado estático podía resultar más conveniente para explicar algunas cuestiones (cuestiones que previamente no teníamos que explicar porque las estudiaban en materias anteriores). Inicialmente consideramos C# pero luego de algunas pruebas decidimos descartarlo. Finalmente la semana pasada decidimos ir con TypeScript. Yo vengo de armar un programa de entrenamiento para pasantes en uno de mis clientes y considero que TypeScript dió muy buen resultado. Mis colegas estuvieron de acuerdo así que ahí vamos.
Complementando TypeScript el stack de desarrollo que vamos usar está conformado por VScode + yarn + eslint + jest + cucumber + express (nada muy novedoso).
La semana pasada comencé a trabajar en un proyecto nuevo. El objetivo es hacer un «refactor» de un sistema que tiene varios años de vida y al mismo tiempo agregarle algunas capacidades nuevas basadas en IA. El sistema consta de 1 componente central construido en javascript, dos «satelites» en php y varias APIs externas algunas bajo el control de otros equipos de la misma organización y otras bajo el control de otras organizaciones.
En el equipo somos unas 10 personas: un Product Owner, cuatro devs todo terreno con dedicación full time, un dev referente técnico con dedicación parcial, un tester full-time, una persona de UX, un persona de infra con dedicación on-demand y yo con dedicación parcial en el rol de coach dev. Los miembros del equipo vienen de trabajar en distintos equipos de la organización y nunca trabajaron todos juntos como equipo.
El proyecto debería durar aproximadamente unos 3 meses.
Estamos haciendo iteraciones semanales con todas las ceremonias (review-retro-planning) de corrido los días miércoles. Estamos haciendo dailies que logramos mantener ~10 minutos.
En la primera iteración no hicimos una estimación formal, simplemente agarramos un conjunto de 17 ítems que consideramos podrían llegar a completarse en 1 semana (spoiler: a los dos días ya no dimos cuenta que llegamos a completar todo, ja!).
Hasta el momento evité escribir sobre cuestiones de Inteligencia Artificial en parte porque me pareció que había demasiada gente hablando del tema, algunos incluso hablando con muchas imprecisiones (por no decir «tirando fruta») pero también porque yo mismo no quería tirar fruta. A pesar de estar trabajando profesionalmente en iniciativas de IA desde 2023 sentí que mi conocimiento era muy superficial.
Pero ya desde un tiempo la IA comenzó a meterse en mis cursos y eso nos obligó a tomar el tema. Es por eso que a comienzos de este año junto a Diego Marcet y Gonza Cozzi (miembros de mi equipo docente en UNTreF) nos pusimos a estudiar formalmente el tema. En concreto comenzamos estudiando el uso de la IA en la enseñanza de la programación. Hicimos una revisión de papers y encuestamos a docentes de programación. Esta iniciativa quedó plasmada en un artículo que enviamos al Simposio Argentino de Educación en Informática y que estaremos presentando en Agosto en el contexto de las Jornadas Argentinas de Informática.
Algunos de los hallazgos que hicimos fueron:
La mayoría de los docentes (~70 %) ya utiliza herramientas basadas en IA en sus tareas docentes.
Al mismo tiempo (más del 70 %), la gran mayoría cree que la incorporación de IA en sus cursos requiere de un cambio significativo en la forma en que dictan sus cursos.
Más del 90% de los encuestados reportaron que sus alumnos ya utilizan herramientas basadas en IA
Más allá de todo lo anterior, y que en un punto era esperable, lo que más nos llamó la atención fue la diferencia de opinión cuando preguntamos si consideraban positiva o negativa la irrupción de IA en la educación, el siguiente histograma muestra la consolidación de las respuestas.
Este artículo representa el primer paso de nuestra iniciativa de estudio del uso de la IA en la enseñanza. Nuestro siguiente paso es trabajar con practicantes, con lo cual si hay algún desarrollador leyendo esto y utilizando IA (co-pilot, cursor, etc) y le interesa participar de un estudio, no deje de contactarme.
La UBA es una institución muy grande, tiene 13 facultades y más de 300 mil estudiantes. Los temas de Ingeniería de Software se estudian en más de una facultad.
Al mismo tiempo se da que la Ingeniería de Software es un cuerpo de conocimiento bastante amplio y diverso, incluye cuestiones de proceso y metodología como también cuestiones de arquitectura, programación y verificación. Y en los últimos años, algunos autores, también han incluido cuestiones de despliegue y operación.
Me animo a decir que la Facultad de Ingeniería (fiuba) es la facultad de la UBA que más cuestiones de Ingeniería de Software cubre. En fiuba hay temas de Ingeniería de Software que se ven en forma transversal a lo largo de distintas materias, cuestiones de programación, verificación, versionado, etc. Al mismo tiempo hay un núcleo de 3 materias específicas de Ingeniería de Software: Ingeniería de Software 1(IS1), Ingeniería de Software 2(IS2) y Gestión del Desarrollo de Sistemas Informáticos(GDS). Finalmente hay materias electivas enfocadas en áreas específicas de la Ingeniería de Software como ser Arquitectura de Software y Estándares de Calidad y Modelos de Referencia, entre otras. En lo personal creo que esta oferta da a los estudiantes una muy buena formación de cara a su ejercicio profesional como Ingenieros de Software. Quienes gusten curiosear pueden ver los contenidos mínimos de estas tres materias en el plan de estudios.
El reciente cambio en el plan de estudio de la carrera de Ingeniería Informática generó un reordenamiento de cursos que llevó varios cuatrimestre. Finalmente, este primer cuatrimestre de 2025, las materias del área de Ingeniería de Software quedaron organizadas en 8 cursos: 3 de IS1, 3 de GDS y 2 de IS2. A continuación resumo algunos datos de cada curso que pueden resultar útiles para futuros estudiantes.
Comparto también las páginas públicas de los cursos (no todos tienen):
Una particularidad interesante es que las 3 materias del núcleo de Ingeniería de Software apuntan a cubrir (en mayor o menor medida dependiendo del curso) todo el ciclo de desarrollo de software. En cierto modo, esto queda evidenciado en que en 7 de los 8 cursos hay que programar. Destaco este hecho porque en algunas carreras/instituciones e incluso en las versiones anteriores de los planes de fiuba, cada materia cubría solo una etapa del ciclo de desarrollo, lo cual denotaba un enfoque «secuencial» bastante distintos del ejercicio de la profesión. En el enfoque actual, más punta a punta e iterativo, se abordan las distintas etapas reiteradamente en las distintas materias pero con distinto foco y nivel de profundidad.
Se fue el primero de 2025 y no fue fácil. Los últimos cuatrimestres veníamos viendo una mejora en diversos aspectos que lamentablemente no continuaron este cuatrimestre.
Por un lado la evaluación del curso por parte de los alumnos fue peor que lo que venía siendo en los últimos cuatrimestres: veníamos alrededor de nueve y con una dispersión mínima (todas evaluaciones 8,9 y 10), ahora tuvimos un evaluación de 8 con mucha dispersión (4, 6, 7, 8, 9 y 10).
Al mismo tiempo el desempeño de los alumnos fue también «más bajo», la nota promedio de evaluación que había sido de 7,3 ahora fue 6,9.
No tenemos una explicación certera de esta situación pero hay ciertos hechos que pueden haber influido:
Tuvimos una cantidad record de alumnos
Uno de los ayudantes colaboradores abandonó a mitad del cuatrimestre y eso nos trajo ciertas complicaciones
El reciente cambio del plan de estudio produjo, entre otras cuestiones, cambios de correlatividades lo cual a su vez produjo cambios en el perfil de los alumnos.
Al margen de los fríos números, en las encuestas nos encontramos con comentarios diversos casi todos muy positivos:
«Excelente materia. Top materias que he cursado. He visto cosas que me sirvieron para reafirmar conceptos y que también me sirvieron en el ámbito laboral»
«La dinamica que proponen da un golpe de realidad y un efoque en la integracion de los temas ya vistos de la carrera que me parece muy valioso. Ademas, para mi, los temas que tratan son clave para diferenciarse dentro del ambito laboral»
«Muy buenas las clases presenciales, muy dinámicas y las actividades ayudaron a entender mejor los temas de una manera divertida.»
«Pagás deuda técnica de materias anteriores»
Por otro lado, en la retrospectiva surgieron cuestiones habituales: la carga de trabajo, uso de otro lenguaje, más presencialidad, menos presencialidad. Pero algo que destacó fueron un par de menciones referentes al feedback y las devoluciones/correcciones. Aunque suene curioso, este es uno de los puntos en los que se expresa la falta de presupuesto: cuando la cantidad de docentes es menor a la apropiada cada docente debe dedicar más tiempo, eso hace que las devoluciones sean menos profundas y cuidadas. Según pudimos hablarlo, algunos alumnos sintieron que el feedback tenía una «carga negativa», de hecho alguien dijo literalmente «feedback duro, no cándido». Frases del tipo «este código no pasa de algo1» o «no se cómo llegaron hasta acá» no serían raras en mí. Reconozco que no son frases alentadoras pero tampoco me parecen tan duras. Por momentos pienso que puede haber alguna cuestión generacional, en mi época de estudiante recuerdo profesores con comentarios bastante menos corteses y en general nadie hacía problema por ello. Pero los tiempos cambian y uno debe adaptarse, en ello vengo trabajando. Sin embargo me queda la duda si no vamos a terminar formando «ingenieros de cristal».
La semana pasada tuve el honor de ser jurado del trabajo final de carrera de Paola Rodrigues quien obtuvo su título de Ingeniera en Computación por la UNTreF. Si bien en las carreras de sistemas hay pocas mujeres, en Ingeniería en Computación suele haber aún menos. De hecho Paola es la segunda egresada mujer de la carrera.
El trabajo de Paola, titulado Análisis, visibilidad de tráfico y seguridad para usuarios finales en redes hogareñas, incluyó el desarrollo de una solución de bajo costo para el control de tráfico en redes hogareñas. El trabajo me resultó muy interesante, una combinación de innovación, programación, hardware y software. ¡Mi felicitaciones para nueva egresada!
Luego de más de 20 años de docencia se me ocurrió empezar a compartir algunas de las situaciones «curiosas» que vivo con mis alumnos que me llevan (no siempre) a reflexionar, #anecdotasDelAula. Aquí va la primera.
Desde que empecé a tomar final oral en mi curso de Ingeniería de Software, los alumnos sugieren/piden recurrentemente que no tome final. La imagen que acompaña este post surgió en una actividad de cierre de curso que hice la semana pasada con mis alumnos de fiuba, no fue la única ni tampoco la primera.
No tengo claro si se debe a una situación de «molestia» pues en cierto modo implica estudiar un poco más o si adicionalmente hay cierto «miedo» a rendir oral.
En lo personal decidí tomar final oral principalmente por dos cuestiones. Por un lado para «forzar» a que los alumnos vean ciertas cuestiones/materiales de índole más conceptual/teórica que no ponemos en práctica durante el curso. Por otro lado creo que un ingeniero tiene que poder mantener una conversación técnica y explicar ciertos conceptos, justamente el final oral es una oportunidad para que los alumnos practiquen dicha habilidad. Adicionalmente a esto, creo que un examen oral es también una instancia de aprendizaje (o al menos eso lo que yo intento).
Blog de NicoPaez 