La semana pasada completé la primera edición de este curso que pensamos junto @martinalaimo. Estoy muy contento con cómo salió considerando que fue la primera edición.
Fueron 4 encuentros online y sincrónicos a todo ritmo con un grupo de 20 participantes muy motivados. Si bien los encuentros tuvieron bastante interacción, me quedó gusto a poco con las interacción offline, me hubiera gustado ver más participación en los foros :-(.
Hablamos de facilitación de estimaciones, modelos de branching, integración continua, test automation y devops.
El feedback de los participantes fue muy positivo y todos coincidieron en que el curso debería haber tenido más encuentros para poder profundizar mas en algunas cuestiones, cosa con la que estoy completamente de acuerdo. Agradezco a todos los participantes por haberse sumado al curso y haber sido en cierto modo «conejillos de india» de este nuevo curso.
Ya tengo en mente varias mejoras para la siguiente edición incluyendo el hecho de extender la duración (posiblemente sean 5 o 6 encuentros) y agregar algunas demostraciones «ejecutables» de pipelines y pruebas automatizadas. Aún no hemos puesto fecha para la siguiente edición pero seguramente tengamos una fecha para el primer trimestre de 2023.
Finalmente quiero agradecer a Martin Alaimo por haberme alentado en esta iniciativa y al equipo de AlaimoLabs por el soporte y la logística del curso.
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.
Hace ya tiempo venía dando vueltas en mi cabeza la idea de una materia para estudiar ciertas cuestiones «avanzadas» y en un punto hasta filosóficas de nuestra profesión. Dada la gran mezcolanza de temas no lograba darle nombre. Se me ocurrieron nombres como «Desarrollo Profesional de Software», «Programación Avanzada» y «Ejercicio profesional del desarrollo de software» pero ninguno me convencía. Finalmente, el pasado fin de semana me puse a escribir una descripción de los temas a abordar y mientras escribía la bibliografía de referencia me resultó evidente que el título debería ser «Artesanía de Software».
La idea de esta materia es estudiar ciertas cuestiones del ejercicio profesional del desarrollo de software. Es una materia avanzada, no por la complejidad de los temas a abordar sino por el hecho de que para poder abordarlos con profundidad y con una visión crítica es necesario tener algunos años de experiencia en el ejercicio de la profesión y más específicamente en programación. O sea, esta no es una materia para gerentes, analistas o maquetadores, es una materia para programadores.
Si tuviera que ubicar esta materia en el plan de estudio, sería una materia optativa del último año de la carrera.
Sobre los temas
Si miramos los planes de estudio de las carreras de sistemas vemos varias materias de programación: Algoritmos y Programación, Paradigmas de Programación, Programación Concurrente, Programación Orientada a Objetos, Taller de Programación, etc. Cada una de estas materias aborda alguna técnica o aspecto de la programación, pero hay ciertas cuestiones que son en cierto modo transversales a todas estas materias.
Entre estas cuestiones transversales hay temas tan básicos como la elección de los nombres de variables que uno podría pensar que deberían abordarse en las primeras materias de programación pero que en ocasiones no se abordan en profundidad o que incluso cuando sí se abordan, son cuestiones que resulta interesante replanteantearse luego de un par de años programando.
También tenemos algunos otros temas relacionados al versionado que es algo que utilizamos a diario pero que muchas veces lo hacemos en modo automático y sin considerar qué estamos metiendo en cada commit, que mensaje de commit ponemos, con que criterio creamos branches, etc.
Uno de los temas más polémicos y filosóficos que trata la materia es la discusión del desarrollo de software como ingeniería, ciencia u oficio.
Algunos otros temas a cubrir:
Profesionalismo, ética y contratos
Freelancing
Work-life balance
Aprender, enseñar, aprender a aprender y aprender a enseñar
Estimación, No-estimación, presupuestos y planificación
Lenguajes y paradigmas
Tipado estático vs. tipado dinámico vs. no tipado
Código de aplicación y código de pruebas
Las pruebas como documentación
Java, el nuevo cobol
El ascenso de JavaScript
Smalltalk…..
Mantenimiento y evolución
Trabajo con código legado
Código de infraestructura
Versionado y trazabilidad
Revisiones, Pairing y Mobbing
No-code / Low-code
Modalidad de cursada
La materia se dicta en una modalidad de aula invertida durante 16 semanas con un encuentro online de 3 horas por semana y con una dedicación estimada extra clase de unas 4 horas semanales.
La materia incluye lecturas (varias), videos (no tantos), código (tanto para leer y como para escribir) y debate (espero que mucho).
Participantes
Los candidatos a cursar la materia deberían:
Estar a menos de 4 materias para recibirse de una carrera de grado de sistemas/computación.
Tener al menos 3 años de experiencia programando profesionalmente en la industria.
Sentirse cómodos trabajando con al menos dos lenguajes de programación y tener alguna experiencia en al menos otros dos lenguajes (no cuenta HTML, CSS, ni bash).
Bibliografía
Estos son algunas de la fuentes y materiales en los que está basada la materia:
The Pragmatic Programmer, de Hunt & Thomas
Software Craftsmanship: The New Imperative, de Pete McBreen
Code Complete, de Steve McConnell
The Software Craftsman, de Sandro Mancuso
Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, de Oshineye & Hoover
The Design of the Design, de Brooks
Atomic Habits, de James Clear
Implementation Patterns, de Beck
Refactoring to Patterns, de Kerievsky
xUnit Test Patterns, de Meszaros
A esto se suman varios artículos (algunos formales y otros no tanto) y algunos videos.
Pre-Inscripción
Si el lector llegó hasta este punto, posiblemente se esté preguntando donde se dicta esta materia. La respuesta es que no lo sé. Por el momento tengo armada la estructura de la materia, algunos materiales, muchas ideas pero no tengo institución para dictarla. Claro que podría hacer un curso «no académico» y dictar esto por mi cuenta, pero precisamente lo pensé como materia porque me parece que es un contenido faltante en las carreras de grado de sistemas/computación. Creo que estos temas deben ser parte de la formación académica de los profesionales de esta disciplina.
En fin, por lo pronto y mientras veo como meter esto en una institución, si estás interesado en tomar este curso te invito a que completes este formulario y en cuanto tenga más definiciones me contactaré contigo.
Un detalle importante a mencionar es que se trata de un workshop académico, o sea: no es típico de taller que podemos encontrar en el contexto de una conferencia de industria como podría ser Nerdearla o la RubyConf. Sino que se trata de un workshop en el contexto de una conferencia académica, en este caso particular la conferencia es ICSE (International Conference on Software Engineering). En este tipo de workshops se presentan artículos que son previamente evaluados por pares (los miembros del comité del programa) y luego se trabaja colaborativamente sobre las temáticas planteadas en los artículos.
Esta es la cuarta edición del edición del workshop, yo participé como autor en 2017 y personalmente creo que es un espacio interesante para participar y publicar:
Al ser un espacio en formato workshop, además de la exposición de los artículos, hay un espacio interactivo de intercambio, colaboración, debate y hasta co-creación de contenido/materiales
La convocatoria (CFP) incluye obviamente trabajos de investigación pero también reportes de experiencia y artículos de posicionamiento (position papers).
Es parte de ICSE, lo cual le da una gran exposición, pero al mismo tiempo, al ser un workshop «la vara de entrada» no es tan exigente como en el track de educación de ICSE.
Debido a las condiciones de pandemia, esta edición se realizará en formato virtual, con lo cual no hace falta viajar para participar.
El deadline para el envió de artículos es el 14 de enero, se que es poco tiempo para escribir algo desde cero, pero tal vez quien algo escrito a medias y esta pueda ser una buena opción para redondear y publicar.
La materia que dicto (tanto en UBA como en UNTReF) es Ingeniería de Software, pero dado que la «Ingeniería de Software» es un rótulo tan amplio, no basta con decir eso para transmitir qué es lo que realmente estudiamos.
Razonablemente alguien podría pensar que toda materia nombrada como «Ingeniería de Software» debería cubrir los temas descriptos en el Software Engineering Body of Knowledge (SWEBoK). Esto es lo que intentamos hacer en las materias Ingeniería de Software 1 y 2 (conocidas informalmente como memo1 y memo2) de la Licenciatura en Análisis de Sistemas de la UBA. Pero esto muchas veces no es así.
En algunas casas de estudio la materia «Ingeniería de Software» solo cubre una parte de esos temas del SWEBoK. Un caso de esto parece ser la materia Ingeniería de Software de la carrera de Licenciatura en Ciencias de la Computación de la UBA, la cual está muy enfocada en cuestiones de diseño y programación orientada a objetos y sin tratar varios temas de SWEBoK.
También está el caso de algunas carreras que no tienen ninguna materia llamada Ingeniería de Software, sino que cuentan con materias particulares para las distintas disciplinas que componen la Ingeniería de Software (análisis, diseño, programación, testing, etc). Este es el caso de la carrera Ingeniería en Informática de la UBA.
También tenemos el caso carreras que cuentan con materias específicas para algunas de las distintas disciplinas de la Ingeniería de Software y al mismo tiempo tienen una materia Ingeniería de Software que cubre los temas restantes de la Ingeniería de Software que no cubre ninguna materia particular como ser muchas veces las cuestiones de proceso, trabajo en equipo y metodologías de desarrollo. Este el caso de la carrera Ingeniería en Computación de UNTreF.
Más allá de todas estas variantes, hay una cuestión que quiero destacar respecto de la forma en que dictamos las materias MeMo1 y MeMo2 en UBA. Ambas materias pretenden cubrir todas las disciplinas de la Ingeniería de Software, en ambas materias se estudia desde requerimientos hasta puesta en marcha pero con mayor profundidad en distintos temas. MeMo1 tiene un mayor foco en las cuestiones iniciales de los proyectos, como ser visión, requisitos, etc, pero aún así trata cuestiones de metodología, arquitectura, etc. Y un punto central: se hace implementación, o sea, los alumnos tienen que programar y poner lo que programan en un ambiente «símil producción». Esto me parece que es fundamental para cerrar el «feedback loop», recién al poner nuestra aplicación en producción sabemos cuán bueno ha sido nuestro trabajo en requisitos y demás tareas de la ciclo de desarrollo. Por otro lado en MeMo2 también cubrimos todo el ciclo pero con un mayor foco en ciertas cuestiones que MeMo1 toca de forma más superficial. En particular en MeMo2 ponemos mucho foco en proceso de desarrollo, el ciclo de BDD/TDD, CI/CD, Configuration Management y dinámica de equipo.
Como ya he mencionado en varias ocasiones es habitual que en la carreras de informática/sistemas los estudiantes tengan que hacer un trabajo final aplicando los conocimientos obtenidos durante la carrera.
Dependiendo de la carrera, el trabajo final suele tomar distinta forma. En algunas carreras ese trabajo final suele ser un trabajo de investigación (tipo «tesis») mientras que en otras carreras ese trabajo suele plantearse como un proyecto de desarrollo de software. Pero en todos los casos, ese trabajo final requiere de profesor que auspicie de director o tutor (el nombre del rol también suele variar de una carrera a otra).
Muchas veces se cree que el director/tutor debe ser un especialista en la temática del trabajo final. Yo personalmente no comparto esa idea, al menos no en forma general. El objetivo del trabajo final es que el alumno demuestre que ha adquirido los conocimientos para ejercer su profesión y en ese sentido es el alumno quien debe ser (o mejor dicho convertirse) en especialista en el tema en cuestión. Entonces ¿Cuál es el rol del director? Podemos debatirlo, pero sin duda el director debe «allanar» toda la cuestión administrativa que conlleva la realización del trabajo. Obviamente esto implica que el director esté familiarizado con el reglamento del trabajo final y el reglamento de la carrera en forma más general.
En lo personal creo que el director debe jugar un rol entre coach y project manager ayudando a los alumnos a mantener el foco y buscando que el trabajo sea completado en tiempo y forma.
Una situación particular puede darse cuando la idea del trabajo final surge del director, en ese cosas el director juega un rol adicional de Product Owner, definiendo funcionalidad y priorizándola.
Si el trabajo es de investigación, entonces uno esperaría que el director tenga cierta experiencia en investigación. De mismo, modo si el trabajo es desarrollo uno esperaría que el director tenga experiencia en desarrollo. La duda en ambos casos es cuánto debe conocer el director del dominio del trabajo, o sea, si estamos desarrollando un aplicación financiera ¿debería el director ser experto en el dominio financiero? Yo creo que creo. Tampoco creo que el director deba ser experto en blockchain si el trabajo se tratara sobre un tema de investigación relacionado a ello.
Para cerrar hay que mencionar que en algunas carreras el director es el encargado de evaluar el trabajo realizado por sus dirigidos, mientras que en otras carreras la evaluación está a cargo de un jurado que no incluye al director. En este segundo caso, uno esperaría que el director hiciera todo lo posible para asegurar el trabajo de los alumnos y que el jurado pueda calificarlo con la mayor nota.
Era la tercera clase del cuatrimestre. Debido a la pandemia estábamos dictando la materia de forma virtual. Como de costumbre sólo un puñado de alumnos tenían la cámara encendida y participaban activamente de la clase. Llevábamos unos 40 minutos de clase cuando uno de los alumnos con cámara encendida, cómodamente sentado en un sillón, enciende lo que a mí pareció un faso (término usualmente utilizado en Argentina para referirse al cigarrillo marihuana). Inicialmente me sentí muy sorprendido, dudé sobre cómo actuar. Finalmente no hice nada, solo continué con la clase como si nada hubiera ocurrido.
Situaciones de este tipo nos llevan a reflexionar sobre las implicancias de las clases virtuales. El hecho de que fuera o no un faso es anecdótico, la discusión es igualmente válida si se tratara de un cigarro de tabaco. En una clase presencial creo que a nadie se le ocurriría encender un faso, ni siquiera un cigarrillo de tabaco. Pero en una clase virtual el alumno no está en las instalaciones de la institución, sino que generalmente está en sus propias instalaciones: su casa. Personalmente en clase suelo tomar mate o café, ya sea cuando estoy en el aula física en la universidad o también cuando estoy en el aula virtual desde mi casa. Debo admitir que en más de una ocasión, estando en un clase virtual, estuve tentado de destapar una cerveza pero finalmente no lo hice. Supongo que por una cuestión de «ética»: virtual o presencial estoy en un aula. De todas formas esta situación me hizo repensar el tema, aunque por ahora sigo limitándome a consumir café y mate durante las clases.
A partir del déficit de profesionales informáticos en Argentina, en los últimos años muchas organizaciones están apuntando a contratar gente más jóven, sin experiencia y formarlos «en casa». Los nombres que toman estas iniciativas son variados: bootcamp, training camp, escuelita, academia, etc, etc. En términos generales estas iniciativas consisten en conformar un grupo de jóvenes, generalmente con muy poca o nula experiencia y entrenarlos durante X semanas/meses antes de incluirlos en los equipos de desarrollo de la organización.
Tal es el auge de estas iniciativas que en lo que va del año me contactaron 3 organizaciones para que los ayude a armar sus bootcamps/academias. En los 3 casos las propuestas iniciales me parecieron desacertadas por diferentes cuestiones tanto desde el punto de vista didáctico como operativo. En los 3 casos hice una propuesta alternativa y a mi entender superadora.
Hasta el momento en solo un caso mi propuesta fue aceptada y puede implementarla. El resultado fue muy positivo tanto para los jóvenes participantes como también para organización contratante. Yo personalmente también quedé muy conforme, incluso cuando algunas cuestiones no fluyeron de la forma que yo esperaba. Meses después de haber completado el entrenamiento y estando los jóvenes ya incorporados a equipos de trabajo en la organización pude confirmar que el objetivo del entrenamiento se había cumplido.
En los otros dos casos ni siquiera llegué a enviar una propuesta económica, solo comenté como sería mi enfoque y me dijeron que mi propuesta les resultaba interesante, que la evaluarían internamente y me volverían a contactar.
Tengo varios reparos sobre este tipo de iniciativas, creo que bien direccionadas pueden resultar muy beneficiosas para las organizaciones y también para jóvenes profesionales. Pero también puede ocurrir que de no tomar ciertas precauciones en el diseño e implementación terminen resultando en un pérdida de dinero para organización y una frustración para los jóvenes.
Si alguien está trabajando en un iniciativa de este tipo y necesita ayuda, me puede invitar un cafecito y lo charlamos.
Desde hace varios años vengo dictando cursos más a allá de mis materias en la universidad. Si bien las temáticas de mis cursos es compartida con los temas que suelo dictar en mis materias, los cursos implican un desafío distinto que amerita una dinámica distinta.
Una materia tiene usualmente (en Argentina) una duración de 16 semanas, lo cual permite «cocinar a fuego lento», un mismo tema puede verse varias veces, con distintos abordajes, dando al estudiante tiempo y material complementario para digerirlo durante la materia.
Mis cursos han sido típicamente «one-shot», uno o dos días, consecutivos, varias horas de corrido con duraciones totales variando entre 4 y 16 horas de clase. Sin embargo, para ayudar en el entendimiento de los temas, todos mis cursos tienen una parte práctica importante y es por ello que prefiero utilizar el término «taller» más que «curso».
Creo que esta modalidad on-shot va bien para cursos/talleres introductorios, donde los participantes vienen a tener un primer acercamiento al tema y se llevan una lista de cuestiones para investigar/profundizar. El tema es justamente que esa investigación/profundización queda en manos del participante y completamente fuera del alcance curso. Para los casos en los que la inversión la hace el propio participante, el retorno de la inversión de haber participado del curso queda a criterio del participante. Pero para los casos en los que la inversión la hace una organización, las expectativas de retorno de la inversión son distintas. Usualmente la organización espera algún impacto positivo en el desempeño de la gente que participa del curso, lo cual me parece completamente razonable.
En 2019 hice un par de experimentos de cursos de «larga» duración, varios encuentros cortos (~90 minutos) a lo largo de varias semanas, con tareas para hacer «fuera del aula». En aquel momento fueron un conjunto de talleres sobre Docker y Kubernetes y anduvieron muy bien. Esta misma dinámica utilizamos en el Seminario de Software Delivery y también tuvimos buenos resultados. Pero en el caso del seminario fuimos un paso más allá y en el trabajo final les propusimos a los alumnos que trabajen sobre una problemática de su organización. Con esta estrategia estoy diseñando mis nuevos cursos: 100% remoto, varias semanas, con un encuentro semanal de ~90 minutos, con trabajo e interacciones entre encuentros y con actividades de aplicación en el contexto/proyecto/organización de cada participante.
El primer curso que voy a ofrecer aún no tiene título pero tengo la intención de utilizar el stack de herramientas con el que estuve trabajando gran parte de 2020: netCore, Gitlab y Docker/Kubernetes. El foco del curso será Continuous Delivery. En los próximo días estaré publicando más información al respecto.
El estado invierte en la universidad pública. Por su parte la universidad educa a los ciudadanos, hace investigación y genera conocimiento que ayuda a mejorar la sociedad. Esta mejora se traduce (indirectamente) en una mejora del estado y así se cierra un circulo virtuoso.
En el área de informática/computación/sistemas creo que se da una situación en la que este circulo virtuoso no resulta tan virtuoso, o al menos no todo lo virtuoso que podría resultar.
Más allá de mi trabajo en la universidad, llevo casi 20 años trabajando en la industria del software, he sido empleado de distintas empresas privadas y en los últimos años he trabajado de manera independiente. Nunca fui empleado de un organismo estatal (más allá de mi trabajo en la universidad) pero como empleado de una empresa privada he trabajado en proyectos de consultoría y capacitación para organismos estatales. Proyectos que perfectamente podría haber realizado una universidad. Al mismo tiempo tengo muchos colegas en situaciones análogas. Esto me ha disparado una pregunta recurrente: ¿porque está una empresa privada haciendo este proyecto y no una universidad pública?
Es aquí donde veo que el círculo virtuoso Estado-Universidad no es todo lo virtuoso que podría ser. Si los organismos estatales contrataran a universidades públicas, estas podrían tener más presupuesto, una cuestión siempre escasa en las universidades Argentinas. Al tener más presupuesto podrían hacer más investigación, o mejorar diversos aspectos de su operatoria y en un última instancia aportar más valor a la sociedad.
Intentando dar respuesta a la pregunta planteada comparto aquí algunas posibles respuestas que se cruzaron por mi cabeza:
La universidad no tiene el conocimiento para dar servicios a terceros. No lo creo. Si efectivamente fuera así, entonces tendríamos un problema muy grave. Pero sinceramente no lo creo. Muchos docentes universitarios del área de informática trabajan en la industria y enseñan en la universidad justamente lo que ponen en práctica en la industria (es mi propio caso y el de todo mi equipo docente).
La función de la universidad no es dar servicios a terceros. Falso, la universidad (al menos en Argentina) tiene 3 funciones: docencia, investigación y extensión. El prestar servicios a terceros es una actividad de transferencia que puede enmarcarse perfectamente dentro de actividades de investigación y/o extensión.
Las personas de la universidad que podrían brindar servicios a terceros prefieren hacerlo en forma privada que por medio de la universidad. Este sí puede ser un tema. Las diferencias salariales en el área de informática entre la universidad y lo que paga el sector privado pueden ser muy relevantes. Sin embargo, según he estado averiguando, hay alternativas que podrían habilitar que los docentes que trabajen en brindar servicios a terceros puedan recibir una remuneración equiparable a lo que podrían ganar desde el sector privado.
Ojo, con esto no estoy diciendo que la universidad tenga que convertirse en una software factory o en un proveedor de servicios de manpower vendiendo «programador por kilo». Sino que los tipos de trabajos en los que imagino a la universidad, son trabajos de capacitación, consultoría o proyectos de desarrollo con un alto componente investigación/innovación.
Me consta que en algunos casos de algunas universidades y algunos organismos, esta colaboración fluye exitosamente, pero no es el caso común.
Creo que revertir esta situación requiere de un acuerdo de las 3 partes: las universidades, los organismo estatales y los docentes/profesionales.
Estoy bastante convencido de esta idea del círculo virtuoso de colaboración Estado-Universidad y es por ello que ya estoy gestionando para participar de un proyecto de colaboración entre la universidad y un organismo estatal durante el año próximo. Continuará…
Blog de NicoPaez 