Ayer terminé mi primer lectura de vacaciones, el libro más reciente de Kent Beck: «Tidy First?: A Personal Exercise in Empirical Software Design».
Primero los datos: el libro es bastante corto, apenas 99 páginas distribuidas en 33 capítulos lo cual sigue el estilo típico de los libros de Beck: capítulos cortos. En este caso está llevado al extremo porque hay capítulos de menos de 2 páginas. El libro es el primero de una serie, que según el propio Beck, tendrá 3 libros. El libro arranca con cuestiones muy concretas y gradualmente se va poniendo más teórico/filosófico.
Pero… ¿qué es un «tidy»? Como la traducción puede sugerir, un tidy es un emprolijamiento. Una mejora en la estructura del código de cara a facilitar su entendimiento/evolución. En un punto es cómo un refactor, pero más chico.
Ahora mi opinión: el libro me gustó mucho, mezcla cuestiones muy concretas/prácticas (los «tidyings») con cuestiones más teóricas/filosóficas (cuando tidy y cuando no, cuánto tidy, etc). Todo esto analizado una visión económica. Creo que son muy pocos los libros que tratan este tipo de cuestiones. A su vez, la organización en capítulos cortos hace que la lectura me resulte muy cómoda. Si bien es libro que cualquier programador debería poder entender sin dificultad, creo que los programadores más experimentados van a sacarle mayor provecho.
Desde mediados de diciembre hasta mediados de Marzo es el período que denomino «cuatrimestre de verano» y que en mi caso se caracteriza por tres cuestiones:
Mis actividades en la universidad son mínimas en gran medida por el receso de verano
Como consecuencia del punto anterior tengo más tiempo disponible que durante el resto del año. Obviamente parte de ese tiempo lo utilizo para descansar pero también para hacer «proyectos distintos», por ejemplo proyectos «experimentales», proyecto con nuevos clientes, etc.
Investigación y generación de material, escribo, hago videos, etc, etc.
Para este «cuatrimestre de verano de 2025», tengo poco trabajo agendado con clientes con lo cual, si la situación no cambia, ya tengo dos temas en los que trabajar.
Por un lado quiero hacer algunos experimentos con tecnologías de inteligencia artificial. Creo que mi proceso de desarrollo podría mejorar (en términos de productividad/velocidad) a partir del uso de herramientas como Co-Pilot y JetBrains AI.
Por otro lado quiero escribir una actualización de algunos capítulos de mi libro «Construcción de Software: una mirada ágil» que ya tiene más de 10 años y ya tengo identificado algunos capítulos que requieren una actualización.
Mi última PC de escritorio la compré allá por 2005 y dejé de utilizarla allá por 2008. Desde entonces he utilizado notebooks. A comienzos de 2013 compré una MacBook Air y desde entonces he vivido con MacOS.
Pero este año decidí volver a comprarme una máquina de escritorio, me compré una mini PC (en otro post hablaré sobre el hardware). La cuestión era qué sistema operativo utilizar, las opciones eran: Windows 11 o algún Linux. Descartar el Windows fue mucho más fácil que elegir la distribución de Linux. Luego hablarlo con un par de colegas y leer algunos foros, los finalistas fueron Arch y Ubuntu. Me incliné por Ubuntu, principalmente porque pensé que tendría menos troubleshooting con los drivers (la última vez que instalé Linux tuve que recompilar el kernel para hacer andar un modem 3G).
Ya teniendo decidido instalar Ubuntu lo siguiente a ver era si ir por un «Ubuntu puro» o alguno de sus «primos» como Mint o Elementary. Finalmente me quedé con Ubuntu y con el sistema de ventanas default.
La instalación fue muy fluída, descargué una imagen, la quemé en un USB booteable y desde ahí instalé. Hice una configuración dual-boot con el Windows que venía de fábrica con la PC porque uno nunca sabe si en algún momento sale un proyecto de desarrollo Windows.
Para mi sorpresa, todo, absolutamente todo me anduvo de una: wifi, bluetooth, micrófono, webcam, impresora y los dos monitores. Impresionante. El dato curioso es que lo único que me requirió más trabajo de lo esperado fue la configuración de la VPN que yo pensaba que andaría de una y sin embargo tuve que hacer troubleshooting y unas operaciones adicionales via terminal.
Luego de esta fluida experiencia, estoy convencido que de ahora en más vamos a pedir uso obligatorio de Linux en las materias a mi cargo. Perdón, corrijo, no vamos a obligar a usar Linux, sino que solo daremos soporte a quienes trabajen con sistemas de la familia unix/linux.
Atípico básicamente por dos cuestiones: un cambio en plan de estudios de la carrera y una situación de movilización y defensa de la educación pública. Vamos por parte.
La situación sin precedentes de emergencia presupuestaria y ataque constante a la educación pública nos llevo a realizar varias acciones de visualización y apoyo, que entre otras cuestiones, nos llevó a realizar clases públicas.
Por otro lado, y al igual que en UNTreF, este cuatrimestre «estrenamos» curso en FIUBA a partir de la implementación del nuevo plan de Ingeniería Informática.
En este sentido, el curso que dicto actualmente está «homologado» como Métodos y Modelos en la Ingeniería de Software 2 (9521 para la carrera de Licenciatura en Sistemas) y como Ingeniería de Software 2 (TA049 para la carrera de Ingeniería Informática).
En lo formal el cambio de plan de Ingeniería Informática tiene un impacto menor en términos de contenidos, pero en la práctica vivimos dos impactos:
Si bien la materia sigue ubicada en cuarto año, hay un cambio en la correlativas que hace que los alumnos puedan llegar habiendo recorrido un camino distinto de materias.
Al mismo tiempo, como la materia no es correlativa de ninguna otra, es posible que esta materia sea la última de la carrera. De hecho este cuatrimestre tuvimos 3 alumnos para quienes esta fue su última materia.
Adicionalmente, debido a el proceso de transición entre planes, tuvimos gente gente en situaciones particulares respecto de las materias cursadas previamente.
A pesar de estos cambios creemos que el curso salió muy bien. Inicialmente parecía que sería más complicado pero luego la cuestión mejoró. Comenzamos el cuatrimestre con un record de inscriptos, según nos informó el departamento: 51 alumnos. Sin embargo, varios nunca aparecieron y en la segunda clase ya teníamos 33. Como de costumbre, durante el cuatrimestre se fueron bajando algunos más y finalmente terminamos la materia con 22 alumnos. Algunos otros números de nuestra encuesta:
La encuesta fue contestada por 18 alumnos
La evaluación general de la materia: 8,9 / 10
La nota promedio de aprobación fue 7,3/10 lo cual representa un mínimo histórico pero al mismo tiempo la conformidad con la nota fue 4,4 / 5.
Dinámica de clases fue 4,7/5 lo cual iguala el máximo histórico. Curiosamente algunos alumnos destacaron que lo mejor de la materia fueron las clases presenciales.
Respecto del porcentaje de presencialidad/virtualidad, 15/18 indicaron que les pareció indicado mientras que 2 hubieran preferido más virtualidad y 1 más presencialidad.
La dedicación semanal extra-clase, según reportaron en la encuesta, fue de 9 horas, sin embargo en el tracking de tareas ese número da 7,9.
El NPS nos dió 44
Por otro lado, en la actividad de cierre destacaron dos items accionables hacía adelante:
Proveer más material sobre Arquitectura Hexagonal, un tema central de la materia y que este cuatrimestre costó mucho.
Revisar la configuración de las reglas de code quality ya que algunas resultaron incómodas, sin sentido y/o demasiado exigentes.
Cierro con algunos comentarios de feedback libre de la encuesta:
«Excelente la materia, por momentos la odie, pero ya al haber terminado, puedo observar que la dureza y el nivel de exigencia valieron la pena y me enriquecieron en todo sentido.»
«Fue la materia en la que más aprendí en lo que va de la carrera»
«Me pareciero muy util el contenido dado y la forma de dictarlos. Me da lástima recién a esta altura de la carrera toparme con esta materia que siento que me hubiera servido mucho en otro momento. Me gustó mucho que se recomienden autores para leer sobre ciertos conceptos, que utilicemos TDD (por más que personalmente no me gusta, ahora le encuentro un gran valor) y sobre todo que hayamos tenido clases presenciales. Me voy de la materia sintiéndome motivada a mejorar, queriendo investigar y profundizar sobre los temas que aprendí. Muchas gracias por a todo el equipo docente de la materia, me pareció muy bueno todo!»
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:
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.
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.
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» 😉 )
Blog de NicoPaez 