Libro: Código Sostenible

Hace un par de días terminé de leer este libro escrito por Carlos Blé. Me pareció muy bueno y me gustó mucho.

El libro es un muy buen compendio de buenas prácticas de programación y diseño. Reúne temas ya tratados en otras publicaciones y agrega temas que personalmente nunca había visto en un libro. En cada tema, más allá de la explicación y algún ejemplo, se suma la opinión de Carlos, siempre pragmática, constructiva y basada en la experiencia.

El libro está escrito en castellano, lo cual también suma puntos, ya que no tengo presente otros libros de esta temática escritos en castellano. Un punto a mi parecer negativo es que los ejemplos de código están en inglés, lo cual me resultó molesto por tener que cambiar de idioma entre el código y la prosa, pero es un tema menor.

Varios de los temas que cubre el libro son temas de MeMo2, o mejor dicho, son temas que nos gustaría que los alumnos de MeMo2 ya tengan asimilados. Lamentablemente no siempre los tienen asimilados y por ello nos vendría muy bien contar con este libro como recurso de estudio. La editorial del libro (Savvily) tiene un acuerdo para que los estudiantes puedan acceder gratuitamente a sus libros, pero dada la burocracia de UBA, veo muy difícil que se logre firmar el acuerdo. De todas formas, no pierdo la esperanza.

Al igual que Code Complete y The Pragmatic Programmer, este libro tiene contenido que todo programador debería conocer.

Agradezco a Carlos por haber escrito este libro pues lo considero un gran aporte a la comunidad IT de habla castellana.

Cierre de cuatrimestre 2022-2 en MeMo2@fiuba

Bien. Muy bien. Mucho mejor de lo esperado. En la previa teníamos record de inscriptos y el desafió de un cambio importante en el equipo: la salida de EmilioG (que teniendo un cargo de ayudante hacía la veces de JTP) y varios colaboradores. Motivados por estas dos cuestiones y el feedback de los alumnos de cuatrimestres anteriores decidimos realizar algunos cambios en la materia (algo ya había adelanto yo en este otro post)

En resumidas cuentas los cambios más relevantes que implementamos fueron:

  • La primera parte de la materia fue principalmente presencial mientras que la segunda parte fue principalmente virtual. Esto permitió que los alumnos se conozcan cara a cara para formar los equipos de trabajo y luego con los equipos ya armados pasamos a modalidad virtual.
  • Bajamos prioridad a algunos temas para dar más profundidad a otros. En este sentido despriorizamos cuestiones como escalamiento de equipo y principios Lean (cuestiones que verán posiblemente en AdminProd y/o EvaPro) y arquitectura de software (hay una materia entera dedicada a ello). Al mismo tiempo pusimos más foco en el proceso de BDD/TDD/CI/CD y «programación colectiva» (pair-mob programming).
  • También agregamos un ejercicio para trabajar de a pares antes de la conformación de los equipos de proyecto
  • Empezamos a tomar examen final, hasta el momento el mecanismo de evaluación estaba basado exclusivamente en el desempeño de los alumnos en las tareas realizadas durante la cursada (incluyendo tareas individuales y grupales). Pero en los últimos años tuvimos algunos casos en los que en verdad dudamos que algunos alumnos realmente hubieran entendido ciertos conceptos. Para mitigar/minimizar estas situaciones (gente que apruebe la materia sin tener en claro algunos conceptos importantes) es que agregamos el examen final

En lo personal quedé muy conforme con la forma de fluir de la materia. Desde la coordinación de la materia todo resultó muy fluido, no fue necesario «correr» con ningún tema. Preparamos las clases y las consignas con suficiente antelación y no tuvimos la soga al cuello con ninguna corrección. Al mismo tiempo creo que encontramos un mix justo de presencialidad/virtualidad.

El feedback de los alumnos también fue muy positivo, tanto en las retrospectiva como en la encuesta final del curso. No hubo tantos reclamos respecto de la carga de trabajo de la materia, si bien fue un tema mencionado, fue mucho más discreto que en ocasiones previas. Con la encuesta de la materia se dieron algunas situaciones particulares:

  • La encuesta fue contestada por 23 de los 24 alumnos que completaron la materia (record)
  • La evaluación general de la materia (en promedio) dio: 9,1 lo cual iguala el máximo histórico de la materia pero con una particularidad adicional: un desvío mínimo, todas las evaluaciones fueron 8, 9 y 10, o sea que nadie calificó la materia con menos de 8.
  • Las otras dimensiones de evaluación de la materia también resultaron muy positivas (algunas incluso con valores record): claridad de los docentes: 4,7/5; Conocimientos de los docentes: 4,9 /5; Dinámica de las clase: 4,7/5; Materiales de estudio: 4,4/5.
  • El NPS, que anteriormente nos había dado 38, ahora nos dio 61 (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 final identifiqué las siguientes acciones concretas para trabajar:

  • Revisar/editar los videos sobre infraestructura pues tienen contenidos que se sueperponen
  • Crear una base de conocimiento con los problemas recurrentes que se encuentran los alumnos al programar con Ruby/Padrino
  • Revisar el timelime de ejercicios/correcciones
  • Hacer una explicación más detallada de la configuración & funcionamiento del pipeline y la infra de los trabajos finales

Algunos otros números:

  • De los más de 30 inscriptos iniciales, solo 24 completaron la cursada
  • La nota promedio de aprobación de cursada fue 7,9
  • Tuvimos 38 tareas individuales, 1 tarea en parejas y 2 trabajos prácticos
  • En términos de dedicación extra clase, en promedio por alumno, fue de un total de 112 horas (53 de tareas individuales/en pareja, 12 horas de tp1 y 47 horas de tp2) repartidas en 15 semanas (que fue la duración de este cuatrimestre para nosotros). Esto nos da unas 7 horas de dedicación semanal extra clase por alumno a lo largo de todo el cuatrimestre.
  • Hasta el momento tuvimos 2 fechas de examen final en las cuales se presentaron 17 estudiantes de los cuales 15 fueron aprobados.

Temas centrales de la enseñanza de la Ingeniería de Software

La facultad de Ingeniería de Universidad de Buenos ofrece dos carreras en el área de sistemas: Ingeniería en Informática y Licenciatura en Análisis de Sistemas. Son dos carreras distintas en el sentido que la licenciatura no es un paso intermedio de la ingeniería. Pero obviamente hay ciertas materias que son «compartidas» por ambas carreras, típicamente las materias de algoritmia, estructura de datos, sistemas operativos y algunas materias de ciencia básica.

En mí época de alumno (allá por comienzos del siglo) ambas carreras compartían dos materias de ingeniería de software que se llamaban: Análisis de Información y Técnicas de Diseño. Tal como los nombres lo sugieren, una estaba centrada en cuestiones de requisitos y la otra en cuestiones de diseño y ambas se cursaban secuencialmente. En el año 2015 la licenciatura modificó su plan de estudio y entre otras cuestiones cambio estas materias reemplazándolas por Métodos y Modelos de la Ingeniería de Software 1 y 2 (comúnmente conocidas como MeMo1 y MeMo2). Por su parte la ingeniería continua aún hoy en día con las mismas dos materias que cursé yo hace 20 años.

Las dos nuevas materias introducidas por la licenciatura están pensadas en línea con la forma en que se desarrolla el software actualmente: de manera iterativa e incremental. Esto implica que en ambas materias se estudia «lo mismo» con distinto pero con distinto foco/profundidad. Ambas materias cubren las distintas actividades del desarrollo de software (requisitos, análisis, diseño, gestión, programación, prueba, etc, etc).

La primera materia (MeMo1) tiene más foco en las primeras actividades del proceso de desarrollo pero cubriendo también cuestiones de diseño, programación y despliegue. La segunda materia (MeMo2) tiene más foco en las cuestiones «del tramo final» incluyendo programación testing, gestión de ambientes y despliegues. Obviamente que hay cierta superposición teórica de temas y es intencional: cuestiones que en una materia tal vez se ven en solo teoría en la otra se ven en la práctica.

A partir de la iniciativa de la Facultad de Ingeniería de rehacer los planes de estudio de todas las carreras, junto a Carlos Fontela y Sergio Villagra comenzamos a trabajar en un propuesta para la enseñanza de la Ingeniería de Software de cara a determinar una estrategia unificada para las 2 carreras. Dado que ambas carreras tienen un perfil distinto, el desafío estaba en determinar el núcleo mínimo común para ambas carreras permitiendo que luego cada carrera acorde a su perfil pueda profundizar contenidos/materias adicionales según considere necesario. En lo que resta de este artículo voy a compartir algunos de los puntos que me parecen más importantes de la propuesta en la que trabajamos.

Antes de hablar de potenciales materias y sus contenidos, hay 2 premisas que tomamos como puntos de partida:

  1. Hay contenidos de ingeniería de software que deben ser abordados en forma temprana y transversalmente en todo el plan de estudio. Ejemplos de esto son prueba unitaria automatizada y versionado.
  2. La ingeniería de software debe cubrir todo el proceso de desarrollo, desde la formulación de la idea hasta la puesta en producción. Lo primero es algo muy aceptado y muy presente en la bibliografía, podríamos incluso llamarlo Ingeniería de Requisitos. Lo segundo es algo un poco más polémico y menos habitual en la academia pues incluye cuestiones como despliegues, ambientes, infraestructura y hasta algunas cuestiones operación, lo que comúnmente se engloba bajo el término «DevOps».

Continuará….

Enseñando prácticas DevOps

La semana pasada presenté en la conferencia ARGENCON 2022, IEEE Biennial Congress of Argentina un artículo formal (experience report) que describe la forma en que abordamos las cuestiones relacionadas a DevOps en el contexto de MeMo2

Este artículo junto con los publicados por Sergio Villagra (Teaching software engineering: an active learning experience) y Carlos Fontela (Learning Communication Skills in Software Development Management Courses: An Active Learning Experience), resume de forma bastante acabada el núcleo de Ingeniería de Software de la carrera de Licenciatura en Análisis de Sistemas de Universidad de Buenos Aires. En un par de semanas el artículo estará disponible en IEEE Explore.

Clases virtuales condicionadas

Luego de 2 años de clases obligadas en modalidad virtual, la mayoría de los alumnos siguen prefiriendo esa modalidad. De mi lado docente, si bien la virtualidad me resulta en cierto modo más cómoda (no tengo que trasladarme hasta la universidad) hay ciertas cuestiones que me resultan mucho más incómodas y que en el balance me llevan a elegir la presencialidad en varias casos.

Concretamente me genera una gran incomodidad dar clases virtuales para una audiencia «ausente»: gente con cámara apagada (o sin cámara) y con nula participación durante la clase. La participación «verbal» puede que no cambie en un esquema virtual o presencial (hay gente que incluso estando en el aula física, no aporta ni una palabra durante toda la clase), pero a pesar de eso, el poder ver las caras ofrece al menos cierto grado de feedback infinitamente más rico que una foto de perfil.

Es por eso que para este segundo cuatrimestre 2022 de MeMo2 vamos a regular la virtualidad acorde a la participación de los alumnos. Si los alumnos quieren clases virtuales entonces deben tener sus cámaras encendidas. En la medida que la mayoría de las cámaras permanezcan apagadas vamos a optar por más clases presenciales. Según la planificación que hicimos tenemos 6 clases que si o si serán presenciales y otras 2 que si o si serán virtuales. El resto de las clases, tenemos la flexibilidad de poder darlas en cualquiera de las dos modalidades.

Cambios en MeMo2 @ FIUBA

Para este segundo cuatrimestre de 2022 estamos considerando realizar varios cambios en la dinámica de la materia.

En primer lugar tenemos un cambio importante en el equipo docente. Emilio Gutter quien venía desempeñando funciones de JTP ya no estará en la materia. Su lugar lo tomará, al menos parcialmente, Hernán de la Fuente, ex-alumno de la materia, miembro del equipo hace ya varios años y muy próximo a graduarse. También tenemos algunos otras bajas, no todas ellas cubiertas, con lo cual el tamaño del equipo se verá disminuído.

Por otro lado vamos a cambiar el orden de algunos temas y la forma en que los damos. Vamos a mantener una modalidad híbrida en la apuntamos a realizar cambios significativos en la dinámica de las clases presenciales.

También tenemos la intención de «reenfocar» algunas cuestiones, concretamente vamos a quitar un poco de relevancia al modelado de objetos/clases para poner más foco en el proceso de construcción (BDD/TDD) y el trabajo en equipo. Esto implica que algunos de los ejercicio individuales de programación pasarán a ser ejercicios en grupales.

Finalmente el último cambio es tal vez el de mayor impacto, vamos a cambiar el mecanismo de evaluación. Hasta el momento no tomábamos parciales ni final. La evaluación de los alumnos era constante a partir de las distintas tareas semanales y proyecto de TP. La idea es mantener eso pero adicionalmente agregar una instancia de evaluación al final de la materia donde cada alumno individualmente tenga que desarrollar «en vivo» una funcionalidad sobre su proyecto. Cuando digo en vivo me refiero a una sesión tipo pairing, donde el alumno acompañado por un docente desarrolla una funcionalidad de acuerdo al proceso y técnicas estudiadas en la materia. Esto no debería representar ningún desafío para los alumnos ya que es lo que hacemos durante la materia. ¿Entonces por qué lo vamos a hacer? Porque tenemos la sospecha de que al trabajar en equipo no todos los miembros asimilan los conceptos, como que algunos «delegan» en sus compañeros.

Cierre de cuatrimestre en UBA: ¡volvimos!

Luego de dos años de completa virtualidad, en marzo de 2022 volvimos a las aulas. Pero dado que descubrimos que algunas cuestiones funcionaban mejor en modo virtual, la vuelta fue mixta. La facultad habilitó un esquema híbrido con un cierto porcentaje obligatorio de clases presenciales y el resto a criterio de cada docente. En el caso de MeMo2, hicimos principalmente presencial la primera parte de la materia y principalmente virtual la segunda parte.

Para ser «el primer cuatrimestre del regreso» creo que estuvo bien y confío en que aún podemos mejorar algunos aspectos. De todas formas tengo la sensación de que gran parte de los alumnos (¿casi todos?) prefiere quedarse en la virtualidad total. Al margen de la vuelta parcial a la presencialidad, este cuatrimestre tuvimos 2 cambios relevantes respecto de cuatrimestres anteriores: 1) dedicamos una clase a hacer el setup de la infraestructura del TP2 (creación del clúster de kubernetes, configuración del pipeline, etc), cosa que previamente lo veníamos haciendo los docentes «tras bambalinas» y 2) Reciclamos un TP2 existente (hasta el momento, cada cuatrimestre «inventábamos» un nuevo TP). Creo que ambos cambios fueron positivos.

En lo referente al desempeño de los alumnos notamos una disparidad importante en la dedicación del TP2. Contexto: el TP2 tiene un alcance fijo (negociable) y dadas las capacidades de cada equipo puede que el tiempo requerido para completarlo sea distinto para cada uno. Lo que vimos es que en términos de calificación todos los equipos tuvieron notas muy similares (menor dispersión de notas que cuatrimestres anteriores), pero al ver la dedicación tenemos en un extremo equipos que completaron el TP2 en ~80 horas mientras que otros dedicaron ~170 horas. Mi explicación de esto tiene que ver con 2 cuestiones: 1) afinidad de los miembros de equipo y 2) experiencia / «habilidad» técnica (no necesariamente en este orden):

  1. No es lo mismo un equipo cuyo miembros son amigos y vienen trabajando juntos en varias materias que un equipo cuyos miembros recién se conocen y que tal vez no se llevan muy bien.
  2. No es lo mismo un equipo cuyos miembros ya tienen experiencia profesional programando y están familiarizados con el stack de herramientas que un equipo donde no todos sus miembros tienen experiencia profesional programando y que desconocen completamente el stack de herramientas. Aquí también entra en juego «la maña» que cada uno se puede dar para resolver dificultades técnicas.

Respecto de 1) no veo que como docentes podamos hacer mucho más allá de permitir que los alumnos armen los equipos a su parecer y de forma temprana en la materia como para que se vayan conociendo. Respeto de 2) lo que intentamos hacer es contestar muy rápidamente las consultas de indole técnicas y proveer a los alumnos con guías/videos para facilitar las cuestiones técnicas/tooling.

Las encuesta interna del curso nos arrojó los siguientes números:

  • Evaluación general de la materia: 8.1 / 10
  • Conformidad con la nota de aprobación: 4.8 / 5
  • Dedicación semanal extra-clase: 8.6 horas
  • Materiales de estudio: 4.0 / 5
  • Claridad de los docentes: 4.3 / 5
  • Conocimientos de los docentes: 4.9 / 5
  • Dinámica de las clases: 4.1 / 5
  • Net Promoter Score: 37.5 (métrica que puede oscilar entre -100 y +100)

Comenzamos el cuatrimestre con 22 alumnos, 2 abandonaron en las primeras semanas y los restantes 20 aprobaron la materia. Lo nota promedio de aprobación fue 8 lo cual es lo mismo que el cuatrimestre anterior pero en este caso la dispersión fue menor.

Como de costumbre cerramos el cuatrimestre con una retrospectiva pero esta vez entre barbijos (que solo algunos nos los sacamos para la foto final)

Y un día volvimos al aula…

Todos con tapabocas, con menos distanciamiento que el recomendado pero con puertas y ventanas abiertas, el pasado lunes 21 de marzo volvimos al aula. Si bien creo que nos adaptamos muy bien a las clases online no hay como la interacción dentro del aula.

Algunas clases de MeMo2 claramente conviene que sean virtuales, principalmente aquellas que incluyen actividades de programación. En esos casos resulta muy conveniente que el alumno pueda trabajar sobre su propia computadora. Del mismo modo, hay otras clases en las que la presencialidad es un valor diferencial. Un claro ejemplo de esto es la primer clase de curso, donde conocemos y comenzamos a intentar generar una relación de confianza que facilite el proceso de enseñanza-aprendizaje.

Llevamos 2 semanas de clase y hasta el momento tengo en claro que la primera clase debería ser presencial (por lo que mencioné previamente) mientras que la segunda debería ser virtual, para que los alumnos puedan hacer el setup de sus computadoras durante el tiempo de clase y que eventualmente podamos asistirlos en vivo.

Como de costumbre, en la primera clase les pedimos a los alumnos que completen la encuesta de perfil. Una vez más nos encontramos con situaciones incómodas como ser el tener alumnos con cantidades muy dispares de materias aprobadas: en un extremo 15 y en el otro 32.

También tenemos disparidad en la edad: gente de 21 y gente de 42.

Un rubro en el que notamos un cambio respecto del histórico de la materia es en el laboral. Este cuatrimestre tenemos que el 81% de los alumnos ya trabaja en un actividad afín de la carrera, porcentaje que tradicionalmente estaba en torno al 70%.

Cierre de 2021 en MeMo2 @ FIUBA

Y se nos fue un cuatrimestre más en modalidad virtual. Ya el cuarto. Personalmente estoy muy contento debido principalmente a 3 cuestiones, paso a enumerar en orden aleatorio.

Una de las cuestiones destacadas es que me parece que logramos transmitir de forma efectiva la propuesta de Desarrollo Guiado por Pruebas (TDD ourside-in). Este es un tema que venimos dando desde que comenzamos a dictar la materia pero que creo que este cuatrimestre en particular logramos transmitir esta técnica de forma efectiva. Digo esto basado en ciertas charlas que se dieron con los alumnos, en los trabajos realizados y en el resultado de una actividad de relevamiento que hicimos en clase que se puede apreciar en la figura 1.

Figura 1. Resultado de la actividad de relevamiento de TDD

Otra cuestión destacada son ciertos ajustes internos en la dinámica del TP2. La forma en que presentamos el problema, el mecanismo de seguimiento y tutoría que implementamos para guiar a los alumnos y un conjunto de checklist que implementamos como herramientas de soporte para los docentes. Creo que esto nos permitió mejorar la experiencia de docentes y alumnos en el desarrollo del TP2.

Finalmente, un objetivo que nos habíamos propuesto a partir del feedback del cuatrimestre anterior, fue disminuir la carga de trabajo del TP2. Este objetivo lo logramos con éxito aun cuando esa carga de trabajo es importante, este cuatrimestre fue menor que el cuatrimestre anterior.

Creo que directa o indirectamente todas estas mejoras se reflejan en los resultados de la encuesta final del curso:

  • Evaluación general de la materia: 9.1 / 10
  • Dedicación semanal extra-clase: 9.1 horas
  • Materiales de estudio: 4.1 / 5
  • Claridad de los docentes: 4.5 / 5
  • Conocimientos de los docentes: 4.6 / 5
  • Dinámica de las clases 4.5 / 5
  • Nota promedio de aprobación: 8
  • Conformidad con nota de aprobación: 4.7 / 5
  • Net Promoter Score: 79 (métrica que puede oscilar entre -100 y +100)

De estas 10 métricas, 9 tienen mejores valores que el cuatrimestre anterior. Al mismo tiempo la Evaluación general de la materia tiene un máximo histórico (9.1 vs. el máximo anterior de 8.9). El otro valor record es el NPS que marca 79 vs. el máximo anterior de 42.
Un punto a mencionar es que no todos los alumnos contestaron la encuesta (tenemos 19 respuestas sobre un total de 26 alumnos), este es un tema recurrente, como la encuesta es anónima y como la hacemos una vez terminada la materia no hemos encontrado un mecanismo para asegurar que todos los alumnos la completen. Pero dado que este es tema recurrente de todos los cuatrimestres creemos que la igualmente la encuesta sigue siendo un elemento válido para medir el curso.

Finalmente, para dar un poco más de contexto comparto algunos otros números del curso:

  • Cantidad de inscriptos: 30
  • Abandonos: 4
  • Aprobados: 26
  • Tareas individuales: 42
  • Trabajos grupales: 2
  • Visitas de la industria: 1

Percepciones de mis alumnos sobre TDD y otras prácticas de desarrollo

En MeMo2 estudiamos diversas prácticas de desarrollo que luego pedimos a los alumnos utilizar durante el desarrollo de los trabajos grupales. En la clase de ayer, a punto ya de terminar el cuatrimestre, hicimos una muy breve actividad para relevar cómo les resultó el uso de esas prácticas.

Nos centramos en 3 prácticas concretas: Test-Driven Development (outside-in style), Mob-Programming y Trunk-Based Development. Para cada una de estas prácticas les pedimos que se ubiquen en lo que seria un «cuadro cartesiano» donde un eje horizontal representa cuánto utilizaron la práctica y el eje vertical representa el grado de confort/utilidad que sintieron con esa práctica.

En el caso de Mob-Programming las respuestas estuvieron bastante dispersas y sin extremos.

Pero para Trunk-Based Development y Test-Driven Development las respuestas resultaron mucho más categóricas: la gran mayoría indicó haber utilizado mucho lás prácticas con un grado positivo de confort/utilidad.

Personalmente estoy muy contento con estos resultados, que los alumnos perciban utilidad en lo que enseñamos resulta muy reconfortante. La gran duda (habitual en el ámbito académico) es cuanto finalmente terminan «comprando» estas prácticas los alumnos, o sea: fuera del contexto de la materia ¿seguirán utilizando estas prácticas?…..