Resultados del cuatrimestre que cambiamos a TypeScript (untref-stats-2025)

A partir de los cambios introducidos por el nuevo plan de estudios en UNTreF, realizamos varios cambios en nuestro curso de Ingeniería de Software. Unos de los más relevantes fue el cambio de Ruby a TypeScript, algo que ya mencioné en un post anterior.

Habiendo terminado el cuatrimestre debo decir que la decisión de cambio a TypeScript me parece que fue acertada, pero a pesar de eso los resultados del cuatrimestre me generan cierta incomodidad. Comenzamos el cuatrimestre con +40 alumnos y llegamos al trabajo final (semana 11) con 20, una situación sin precedentes desde que el curso está a mi cargo. En términos generales la materia está estructurada en 2 partes. En la primera los alumnos trabajan individualmente estudiando y poniendo en práctica ciertos temas que evaluamos con ejercicios de programación. Para aprobar esta primera parte y poder «pasar» a la segunda, los alumnos deben promediar al menos 6. De los +40 alumnos que comenzaron la materia apenas 20 lograron completar la primera parte con promedio 6 (o más). En la segunda parte los alumnos trabajan en equipo en un «simulacro de proyecto real», desarrollando una WebAPI REST y aplicando de forma integral todo lo visto en la primera parte de la materia.

Al analizar el desempeño de los alumnos desaprobados nos encontramos ciertas situaciones recurrentes que podríamos resumir como: falta de atención. Dos ejemplos concretos:

  • En la consigna del ejercicio indicamos el nombre de los archivos a entregar. Luego nos encontramos con archivos con nombres distintos a los indicados.
  • Acompañamos la consigna con un conjunto de casos de prueba, esperando que los alumnos se aseguren de que sus soluciones pasen dichos casos antes de realizar la entrega. Luego nos encontramos con soluciones que no pasan los casos de prueba.

Por otro lado, en la segunda parte, el desarrollo del trabajo final requirió de un esfuerzo/dedicación de los alumnos, mucho mayor a la esperada. No fue el caso de todos los equipos pero sí de un porcentaje importante de ellos. Creemos que esto se debe en gran medida a la falta de atención pero también al hecho de los que alumnos llegan bastante «verdes», algo que definitivamente tendremos revisar para el próximo cuatrimestre.

Volviendo al tema de TypeScript, nos sirvió para lograr nuestro primer objetivo: facilitar a los alumnos el setup de sus ambientes y facilitar la explicación/entendimiento de ciertas cuestiones a partir del uso de un lenguaje estáticamente tipado. Sin embargo nos encontramos con algunas «chanchadas» que permite TypeScript, a pesar de haber advertido a los alumnos, como por ejemplo el uso de Any en los objetos de negocio. Aún no lo hemos confirmado con el equipo pero creo que TypeScript es una de las cosas que mantendremos.

Cierro con algunos números concretos surgidos de nuestra encuesta:

  • Evaluación general de la materia (promedio): 8,4 / 10
  • Dinámica de clases : 4,4 / 5
  • Materiales de estudio: 4,4 / 5
  • Claridad de los docentes: 4,5 / 5
  • El 90% de los alumnos estuvieron de acuerdo con la cantidad de clases presenciales (el 10% restante hubiera preferido más presencialidad)
  • Cantidad de respuestas: 18

Nuevo Stream de Desarrollo de Software

Con los miembros del equipo de la materia de Ingeniería de Software de UNTreF, Diego Marcet y Gonzalo Cozzi, decidimos hacer un experimento: un stream.

Vamos reunirnos una vez por semana a desarrollar una aplicación de punta a punta aplicando las prácticas de desarrollo que habitualmente enseñamos en nuestra materia y lo vamos a hacer mientras los transmitimos por YouTube. La idea no es solo mostrar código sino también tener las discusiones/decisiones que típicamente surgen en cualquier equipo de desarrollo.

En principio vamos a hacer una transmisión por semana por YouTube, los días miércoles en el horario de 19:00 a 21:00 (hora argentina, GMT-3) comenzando la semana próxima, el miércoles 26 de marzo.

Hablaremos (e implementaremos) de BDD, TDD, Integración Continua, Trunk-Based Development, Pair-Programming, Feature Flags, Infra as Code, Continuous Delivery, DevOps, Patrones, Arquitectura, Calidad y mucho más.

Los interesados nos vemos aquí en el miércoles próximo, pasen y vean.

Los dos estilos de backlogs

El término «backlog» alcanzó una gran popularidad de la mano de Scrum llegando incluso a trascenderlo. Muchos utilizamos en la actualidad el término «backlog» aún sin estar trabajando necesariamente con Scrum. En este sentido he visto enfoques de uso de backlog muy diversos entre los que me parece destacan 2.

En un extremo está la visión más cercana a Scrum donde el backlog está centrado en el producto, sus ítems están expresados en términos negocio, típicamente con forma de user stories y épicas.

En el otro extremo tenemos un backlog que representa el trabajo por hacer y si bien todos sus ítems tienen alguna relación con el producto/servicio que estamos construyendo, esa relación no siempre es tan directa o evidente. El backlog es en este caso una herramienta de gestión del trabajo y en parte por ello sus ítems no siempre toman la forma de user stories, sino que muchas veces son tareas.

He visto equipos trabajando con uno u otro enfoque de backlog y también he visto equipos trabajando con ambos tipos de backlog en simultáneo. Y obviamente también he visto equipos trabajando con enfoques distintos a estos dos.

En lo personal, y desde mi posición de miembro del equipo de ingeniería, tiendo a inclinarme por el segundo enfoque, es fundamental para mi tener en bien en claro y visible todo el trabajo por delante. Me ha pasado de trabajar con equipos «novatos» en términos de gestión que intentan trabajar con un backlog puramente de producto y que pierden de vista tareas indispensables para la entrega de valor como ser la gestión de ambientes, configuración y demás tareas relacionadas a la puesta en producción.

Nuevos cursos de Ingeniería de Software

A partir del cambio de plan de estudios de la carrera de Ingeniería en Computación de UNTreF, este cuatrimestre tuvimos que cambiar nuestro curso de Ingeniería de Software. Previamente la materia Ingeniería de Software se encontraba al final de la carrera (último año) y ahora, en el nuevo plan, se encuentra en tercer año.

Este cambio impactó en varias cuestiones:

  1. Los conocimientos previos con los que llegan los alumnos. Previamente los alumnos llevaban con unas 35 materias aprobadas, mientras que ahora llegan con alrededor de 20.
  2. El nivel de maduración/experiencia de los alumnos. En general los alumnos de último año ya se encuentran trabajando en el rubro y eso les da una determinada experiencia de programación, resolución de problemas, etc. Los alumnos de tercer año, en cambio, muchos aún no trabajan en el rubro y su experiencia en programación es mucho más acotada.
  3. La cantidad de alumnos, hay muchos más alumnos en tercer año que en quinto. Pasamos de tener unos 8-10 alumnos a tener alrededor de 25.

Al mismo tiempo, si bien el nombre de la materia se mantiene y los contenidos no son tan distintos, el nivel de profundidad cambió radicalmente. Vimos de forma mucho más superficial ciertas cuestiones de gestión, e incluso sacamos algunos temas de arquitectura, mientras que nos detuvimos mucho más en temas de programación y diseño a nivel objetos. Cuando comenzamos a planificar la materia pensamos en varios cambios, pero finalmente decidimos no hacer demasiado cambios «up-front» porque desconocíamos el perfil de los «nuevos alumnos», así que decidimos seguir un enfoque más «adaptativo» e ir viendo sobre la marcha.

Comenzamos el curso con 33 alumnos y lo terminamos con 24, una caída muy importante comparado con nuestros números históricos (en los últimos dos años todos los alumnos que comenzaron la materia, la completaron). Sin embargo creemos que no estuve tan mal, sobre todo porque en un primer momento pensamos que llegaríamos al final con menos de 10 alumnos.

Una consecuencia del cambio de plan de estudio es que muchos de los contenidos que sacamos de la materia, los estaremos dando en una nueva materia optativa, «Ingeniería de Software Avanzada» que comenzaremos a dictar el año próximo. En lo personal nunca dicté una materia optativa, pero es algo que me viene dando vueltas en la cabeza hace un buen rato. Me gusta la idea de que la gente no venga «obligada». Al mismo tiempo, creo que al ser una materia optativa, se presta un poco más a la experimentación.

Hoy, habiendo terminado la materia, estamos muy conformes con el resultado y lo cual es confirmado por el feedback de los alumnos. La evaluación general de la materia, resultado de una encuesta anónima, nos arrojó en promedio 9/10, con una dispersión mínima (fueron todos 8, 9 y 10).

Cierro con algunos comentarios de la encuesta:

«Gran materia, aprendí un montón. Vine de entrada con esa expectativa, ya que compañeros que ya la había cursado me dijeron que era de las mejores de la carrera.»

«Aprendí como es la dinámica de trabajar desarrollando, algo que no se aprende en ninguna materia. Me parece muy valiosa la enseñanza desde cero y terminar aplicando todo junto en un proyecto. Estoy muy agradecido»

«Buena dinámica de clases, menos aburridas que una clase normal.»

(esto último comentario que encantó «menos aburridas que una clase normal» 😉 )

Sobre story points, horas y demás yerbas de estimación

Ayer en una clase de Ingeniería de Software en @untref un alumno me consulto sobre «la tendencia a dejar de utilizar story points».

En lo personal desconocía esa tendencia, pero si me constan un par de cuestiones al respecto de los story points.

  1. Los story points son uno de los artefactos peor entendidos y más mal utilizados de la ingeniería de software. Ejemplos clásico: gente que estima en story point para luego «traducirlos» a horas.
  2. Los story points son herramientas surgidas en un contexto con ciertas condiciones, valores y principios. Como suele ocurrir, utilizar una herramienta fuera del contexto y las condiciones en las que fue pensada, podría no dar los resultados esperados.
  3. En lo personal me animo a decir que me han resultado una herramienta útil pero que hoy en día, intento no utilizarlos. Los story points nos ayudan a lidiar con ítems de distinta complejidad/tamaño. Si logramos particionar los ítems de forma tal que todos tengan «el mismo tamaño», entonces podremos directamente hablar de cantidad de ítems y prescindir de los story points.
  4. Lo que definitivamente no me ha funcionado es estimar/planificar utilizando horas. No digo que no funcione en general, sino que a mi, con el conjunto de prácticas que utilizo(pair-programming, mobbing, gestión de alcance variable, etc), no me funciona. Más aún, en un punto resulta incompatible.

En fin, cada médico con su librito.

Sobre la investigación en Informática

En estos tiempos en que la educación y sistema científico Argentino están sometidos a desfinanciamiento y cuestionamientos varios, quiero compartir un poco de información general y algunas cuestiones de mi caso.

Al hacer investigación, en primer lugar uno debe encontrar un tema de investigación y debe empezar a estudiar para encontrar algún punto concreto donde potencialmente hacer un aporte. Ya estudiar un tema implica recursos, de mínima hay que leer publicaciones científicas, las cuales en su gran mayoría no son de acceso gratuito. En general los centros de investigación y universidades suelen tener suscripciones pagas para poder dar acceso a sus investigadores. En Argentina, hay ciertas suscripciones cuyo acceso lo gestionaba el ministerio de ciencia y técnica y lo disponibilizaba para diversas instituciones públicas. En este momento, varias de esas suscripciones han caído (no las renovaron). En fin, de alguna forma el investigador estudia, encuentra una idea dónde hacer un aporte y comienza entonces «el camino hacia el aporte». Esto que describo aquí de forma lineal puede no ser tan así, dependiendo del caso puede ser una cuestión más «iterativa», con idas y vueltas.

Ya teniendo un tema (o al menos una pista de por dónde ir) hay que poner manos a lo obra, lo cual puede implicar actividades muy distintas dependiendo del área de investigación. En mi caso, yo trabajo en Ingeniería de Software Empírica, lo cual no suele requerir ningún equipamiento particular, ni compuestos químicos, ni tampoco un laboratorio. Nos basta con una computadora. En este sentido podríamos pensar que para mi caso esta parte del trabajo es relativamente «barata» en términos comparativos con otras disciplinas. Básicamente trabajamos con gente y con datos. Puede que necesitemos de algunas herramientas no gratuitas (software licenciado, algún servicio online, etc), pero en general de costo bastante accesible (algunos cientos de dólares). Es importante destacar que dentro de la informática hay otras temáticas muy distintas (por ejemplo todo lo relacionado a Inteligencia Artificial) y que pueden tener necesidades de recursos/infraestructura también muy distintas.

No voy a entrar en detalles pero básicamente aplicamos el método científico y en algún punto llegamos algún hallazgo que consideramos que agrega valor y «expande la frontera del conocimiento». Es momento de publicar, pues según las reglas del sistema la real medida de avance es la publicación. Escribimos un artículo y lo enviamos a una conferencia o a una revista. La publicación tiene dos objetivos: validación y difusión. Para publicar, ya sea en una conferencia o en una revista, hay que pasar por un proceso de revisión por pares. Los revisores evaluarán nuestro artículo considerando diversas dimensiones que obviamente incluyen el valor de nuestro aporte, pero también la rigurosidad del proceso de investigación y la presentación (o sea, qué tan bien escrito está el artículo). En el «caso feliz», nuestro artículo será aceptado para publicación lo cual nos pondrá muy contentos pero traerá seguramente aparejado un desembolso de dinero. En el caso de las conferencias tendremos que afrontar los gastos de la participación en la conferencia que básicamente son la inscripción y la logística de participación (traslado, alojamiento, viáticos, etc). Simplemente a modo de ejemplo: en agosto participé del CLEI 2024, una conferencia internacional que se realizó en Bahía Blanca. Tuve que viajar a Bahía Blanca y alojarme allí 2 noches. Asimismo la inscripción me costo 260 dólares. Redondeando tuve un gasto total de 400 dólares, de los cuales 340 salieron de mi bolsillo. La universidad solo me pudo aportar unos 60 dólares. Claro que hay conferencias más económicas pero también las hay más caras. Personalmente he participado en conferencias de 100 dólares y en conferencias de más de 1.000. Asimismo he participado en conferencias en Argentina, Brazil, Bolivia, Escocia, España y Finlandia y en todos los casos la mayor parte de los costos los afronte de mi bolsillo. A diferencia de lo que suele ocurrir con las conferencias de industria, donde los speakers tienen la entrada bonificada y en ocasiones también algunos viáticos, en las conferencias académicas hay que pagar, sobre todo los autores deben pagar pues el proceso de publicación no es gratuito. Publicar en una revista, puede en algunos casos, resultar menos oneroso, pues no hay costos de logística ni inscripción, pero en general hay que pagar a la revista. Si bien hay revistas en las que puede publicase gratuitamente, hay muchas otras en las que el costo publicación requiere un desembolso. Un costo implícito en todo este proceso es el tiempo que deben dedicar los investigadores, un tiempo que hoy en día en Argentina es remunerado muy pobremente.

City Building Game @ UNTreF

El martes pasado en mi curso de Ingeniería de Software hicimos este juego como actividad para poner en práctica un proceso «Scrum-like». Este juego fue diseñado por mis colegas Alejandra Alfonso y Emilio Gutter.

En general veníamos usando el juego del Pajarraco Scrumero porque teníamos grupos chicos (no más de 10 alumnos), pero este cuatrimestre tenemos 30 alumnos y nos pareció que el City Building escalaba mejor que el Pajarraco. Y creo que no nos equivocamos. Si bien en alguna conferencia hemos hecho el Pajarraco con unas ~80 personas, en ese caso contábamos con muchos materiales y varios facilitadores. El Pajarraco requiere de materiales muy específicos (ladrillitos tipo Rasti) mientras que el City Building básicamente requiere de elementos de librería (tijeras, papel y pegamento) que son más fáciles de conseguir.

Lamentablemente Emilio y Alejandra no hay publicado el juego aún. Sin embargo cuando le comenté a Emilio que estaba escribiendo este post, me prometió en breve publicar todos los detalles del juego, así que los interesados pueden contactarlo directamente a él.

Cierro con algunas modificaciones que hicimos al guión original del juego:

  1. Descartamos el papel glase, lo reemplazamos por papeles de colores (tipo los de taquitos de oficina), hojas blancas y lápices.
  2. De la mano de lo anterior agregamos un nuevo rol a los equipos: el pintor.
  3. Solo 4 minutos de iteración nos pareció muy poco, creemos que sería mejor hacer iteraciones de 5 o 6 minutos.
  4. Redujimos el número de tijeras por equipo, creemos que salvo el cortador de círculos, los otros cortadores se pueden arreglar para cortar «a mano».

Diplomatura en Ingeniería de Software Continua: charla informativa 2024-2

Ya está abierta la inscripción para la Diplomatura en Ingeniería de Software Continua que dictamos en UNtreF junto a Diego Fontdevila, Carlos Fontela, Andrés Diaz Pace, Diego Marcet y Federico Casuscelli.

En estos días estamos completando la primera cohorte de graduados (nos falta cerrar notas de una de las materias) pero al margen de ese detalle ya hemos tenido muy buen feedback de los estudiantes y estamos trabajando en algunas mejoras de cara a la nueva cohorte que comenzará en septiembre.

Como de costumbre vamos a hacer una charla informativa para contar sobre los contenidos, forma de cursada, etc y atender consultas de los potenciales alumnos. Dicha charla será este miércoles 31 de Julio a las 9:30 hs hora argentina (aclaro que es hora argentina por que al ser una carrera 100% online ya nos ha pasado de tener estudiantes de diversos paises).

Los interesados en participar de la charla informativa pueden completar este formulario y les enviaremos el link de acceso.

La materia faltante en la universidad

Una problemática cotidiana de los sistemas de software es el mantenimiento y evolución de los mismos. Es común encontrar en los planes de estudio diversas técnicas para aplicar durante el desarrollo inicial del software de cara a facilitar su futuro mantenimiento y evolución.

Pero es poco habitual para los estudiantes tener que lidiar con el mantenimiento y evolución de código existente. Más aún, es poco habitual que los alumnos tengan que trabajar con código ajeno. No me refiero a tener que utilizar componentes desarrollados por otros sino a tener que modificar código escrito por otros.

Las técnicas para mantener y evolucionar código ajeno no son necesariamente las mismas que las que se utilizan para facilitar el futuro mantenimiento y evolución. Más aún, esas técnicas son tanto de índole técnico como también de índole de gestión.

Algunas de estas cuestiones intentamos cubrir en MeMo2@fiuba. Justamente cada vez que doy estos temas vuelvo sobre esta idea de tener una materia exclusivamente centrada en «código legacy».

Al mismo tiempo creo que estudiar estas técnicas requiere de aplicación práctica, no basta con estudiarlas teóricamente. Esto es lo que me lleva a pensar que es necesario una materia para lidiar con esta problemática.

No estoy seguro que sea una materia para estudiar en un carrera de grado, por el simple hecho de que me parece necesario que antes de abordar estos temas, los estudiantes dominen cuestiones Ingeniería de Software y también (sobre todo) tengan cierta experiencia de aplicación en «mundo real».

Invitación & Iniciativa: Desarrollo con NicoPaez

El próximo lunes 15 de enero comenzaré esta nueva iniciativa. La idea es que voy a desarrollar una aplicación de forma iterativa e incremental, dedicando tan solo 15 minutos por día y aplicando las prácticas «modernas» desarrollo (BDD/TDD, CI, Test automation, etc) y gestión (slicing, estimación, planificación). En cierto modo voy a estar poniendo en práctica gran de los temas que vemos en MeMo2.

Estaré trabajando en Ruby casi puro, voy a intentar evitar utilizar complementos mágicos como Rails de forma que sea fácil seguirme y que incluso, quienes gusten, puedan trabajar a la par utilizando algún otro lenguaje.

Creo que mantener las sesiones acotadas a 15 minutos puede ser un gran desafío, pero en principio es la intención. Dicho esto, los interesados en participar me pueden mandar un mensaje aquí y los agrego a la cita para que les quede en el calendar y puedan acceder el meet.

¡Nos vemos el lunes 15 de enero a las 12:00 (hora Argentina, o sea: GMT-3)!

Actualización: comparto aquí el video de la primera sesión donde explico varios detalles de la iniciativa (alcance, grabación, etc)