Sobre el rol del director en el trabajo final de carrera

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.

Cierre de otro cuatrimestre particular en Ingeniería de Software @ UNTREF

Particular no solo por ser en modalidad online sino también porque participaron del curso estudiantes externos a la carrera. Esto último es parte de una iniciativa de «abrir la universidad» que comenzamos hace ya un tiempo.

Algunos números descriptivos de este cuatrimestre:

  • Comenzamos con 10 estudiantes y terminamos con 9
  • La nota promedio de aprobación fue 8
  • Tuvimos 35 tareas individuales incluyendo videos, lecturas, cuestionarios y ejercicios de programación
  • Hicimos un trabajo grupal que duró 5 semanas trabajando en equipos de 3

Luego de 15 semanas de clases online, la última clase la hicimos en modo mixto: parte del curso reunido presencialmente y parte del curso en forma online. En 4 cuatrimestres de pandemia es la primera vez que hacemos una clase en esta modalidad y esta experiencia confirmó mi sospecha: es preferible estar todo el curso en un mismo medio, ya sea online o presencial, pero todos juntos.

Para la reunión presencial, a pesar de estar todos vacunados, seguimos algunos protocolos básicos: todos con tapabocas, ventanas abiertas, etc.

Como de costumbre la última clase estuvo dedicada a una actividad de cierre tipo retrospectiva. De esa actividad sacamos 3 accionables:

  • Armar una base de conocimiento (con una wiki o documento compartido) donde docentes y alumnos vayan colaborando con preguntas/respuestas frecuentes.
  • Enviar el checkpoint con las tareas semanales apenas terminada la clase.
  • Grabar las clases que sean más «teóricas»

Finalmente algunos números de las encuestas de fin de curso:

  • Evaluación general de la materia: 9.5 / 10
  • Conocimientos de los docentes: 5 / 5
  • Dinámica de las clases: 4.9 / 5
  • Materiales de estudio: 4.6 / 5
  • Dedicación semana promedio extra clase: 7.6 horas

Recursos sobre Persistencia Objeto-Relacional

Persistir Objetos en una base de datos relacional es una problemática muy común sobre todo en el desarrollo de las denominadas «aplicaciones enterprise». Los desafíos de esta cuestión han sido caracterizados con nombre propio: «Impedance Mismatch«. Hoy en día esta problemática ha sido resuelta por diversas en herramientas entre las que a mi entender se destacan Hibernate(Java) y ActiveRecord(Ruby).

En MeMo2 trabajamos con Ruby pero evitamos el uso de ActiveRecord de la manera tradicional pues resulta intrusiva en el modelo de objetos, ya que obliga a que las clases a persistir deban heredar de una clase de ActiveRecord. La intención en MeMo2 es implementar lo que desde una perspectiva Domain-Driven Design suele denominarse «Persistence Ignorance», esto es que el modelo de objetos permanezca «ignorante» de la tecnología de persistencia. Si bien es importante que los alumnos entiendan los desafíos de esta problemática, no esperamos que implementen un ORM pero si que respeten la idea de «Persistence Ignorance». Es por ello que a lo largo de varios cuatrimestres hemos provisto a los alumnos con ejemplos de implementación de persistencia basados en la idea de Repositorios y utilizando distintos frameworks. Basados en el feedback que los propios alumnos nos han dado, este cuatrimestre agregamos un ejemplo de implementación basado en Sequel y una serie de video que explican la problemática y algunas técnicas de diseño.

El primer video explica conceptual el problema de guardar objetos en una base de datos relacional.

El segundo video explica desde los distintos modelos con los lidiamos en el desarrollo de una aplicación y como es la relación entre ellos a la hora de implementar la persistencia.

Finalmente, el tercer video menciona una seria de recomendaciones para implementar la persistencia de forma trasparente utilizando el patrón Repositorio.

Sobre la presentación de la nueva gestión del Departamento de computación de FIUBA

El pasado viernes fue la presentación de la nueva gestión del Departamento de Computación de Facultad de Ingeniería de la Universidad de Buenos Aires. Este departamento se encarga de la gestión de las materias del área de computación, no de las cuestiones de «informática/tecnología» de la facultad, eso está en manos de la Subsecretaría de Tecnologías de la Información y Comunicaciones.

Esta nueva gestión está encabezada por la el Lic. Manuel Camejo en el rol de director del departamento. Según me comentaron es un nombramiento interino pero no puedo asegurarlo, la única información formal que recibí sobre este cambio fue el mail de despedida del director anterior hace menos de un 1 mes.

Este cambio viene en principio con cambio de imagen y estrategia de comunicación. Hay un logo y presencia en Twitter, Twich e Instagram. Al mismo tiempo me parece interesante el hecho de que hayan realizado una presentación de la gestión y que la hayan transmitido en vivo por redes.

Respecto de lo que se habló en la reunión de presentación hay algunos puntos que me parece interesante destacar:

  • La intención explícita de que el departamento sea un proveedor de servicios a la carreras.
  • El foco inmediato en reestructurar la asignación de recursos del departamento dado que hay materias del comienzo de la carrera con una relación de 1 docente cada 30 alumnos y materias del final de la carrera con una relación de 1 docente cada 4 alumnos. Creo que esto puede ser un desafió interesante y tengo mis dudas hasta que punto puede corregirse.
  • La información que comentó Rosita respecto de el rumbo de los planes 2020 que por la pandemia terminarán siendo los planes 2022.
  • Como parte de la presentación, también habló el Ing. Pablo Deymonnaz, el reciente director de la carrera de Ingeniería en Informática. Entre las cosas que mencionó Pablo lo que me resultó más interesante es el foco que tendrá la carrera de ingeniería con el nuevo plan. Claramente se apunta a una formación muy técnica con contenidos de matemática aplicada/ciencia de datos, system programming y sistemas distribuidos entre otros. Con esto queda muy clara para mi la diferencia entre la Ingeniería Informática y la Licenciatura en Sistemas. La licenciatura queda posicionada como una carrera de Ingeniería de Software, no es que la Ingeniería no vaya a tener contenido de Ingeniería de Software, sino que dicha temática será tratada con mucho mayor profundidad en la Licenciatura.
  • Se presentaron también dos colaboradores externos que justamente estarán colaborando con la dirección del departamento. Uno de ellos es Javier Brugues, egresado de la casa y con quien tuve la oportunidad de compartir algún proyecto hace unos años. El otro es Federico Carrone, un ex-alumno de la casa que abandonó la carrera.

Ojalá este cambio en la gestión sea para mejor. En un par de meses les cuento que tal.

Ser proveedor del (¿ineficiente?) estado Argentino

Este año por primera vez que fui proveedor directo de un par de organismo de la administración pública del estado Argentino, en todos los casos por cuestiones de capacitación IT y es justamente en estas experiencias que están inspiradas estas líneas. Pero hay que destacar, que casualmente (o no tanto), estas experiencias coinciden con tantas otras experiencias que me han comentado varios colegas.

Antes de continuar me parece importante aclarar que esto no es una crítica a la administración actual (ni a la anterior), o mejor dicho: no es una crítica a ninguna administración en particular al mismo tiempo que es una crítica a todas las administraciones por no haber solucionado la cuestión.

Reescribí estas líneas varias veces de cara a intentar que la lectura sea lo más fluida posible y que al mismo tiempo sea fácil de entender. Primero describo el flujo y luego entro en los detalles e implicancias de cada paso.

  1. El estado requiere contratar capacitación para lo cual hace un convocatoria. Dependiendo de la envergadura del presupuesto esa convocatoria puede ser más o menos formal, más o menos burocrática.
  2. En cualquier caso, uno termina presentando una propuesta.
  3. El estado evalúa las propuestas recibidas y elige una.
  4. El proveedor adjudicado realiza la capacitación de acuerdo a lo pactado.
  5. El estado verifica que la capacitación fue efectivamente completada de acuerdo a pactado y da intervención al área encargada de pagar, la cual coordina con el proveedor para que presente la documentación pertinente.
  6. El proveedor presenta la documentación correspondiente que típicamente incluye una factura entre otras cosas.
  7. Finalmente el estado realiza el pago

Este flujo es bastante genérico y no resulta muy distinto a lo que ocurre con empresas grandes (en las empresas chicas el flujo suele resultar más simple porque del lado del contratante suele haber menos áreas/personas involucradas). Ahora bien, el tema central aquí es el tiempo calendario. Desde la presentación de la propuesta hasta la adjudicación de la misma y de ahí hasta el dictado de la capacitación, pueden pasar varios meses. Más aún, una vez finalizado el dictado de la capacitación puede que el pago no sea inmediato. Esto tiene especial impacto en contextos altamente inflacionarios como los que habitualmente se viven en Argentina. Esta situación «obliga» a los proveedores a «inflar» los valores. O sea, si la capacitación tiene un valor X al momento de la cotización, pero se sabe que será cobrada N meses después, el proveedor presenta un presupuesto Z (bastante mayor X) para estar cubierto por las variaciones inflacionarias. Pero la cuestión no termina ahí, si el proveedor es una empresa chica (o directamente una empresa unipersonal) puede que su estructura financiera no le permita afrontar los largos tiempos que típicamente se toma el estado para concretar los pagos. Resumiendo: los largos plazos de pago del estado provocan que:

  1. Los pequeños proveedores queden fuera de juego por no tener la espalda financiera para hacer frente a los largos plazos de pago
  2. El estado termine pagando más caro por el servicio por el colchón que pone el proveedor para cubrirse del pago retrasado

A esto, alguien podría agregar que contratar empresas más grandes, implica pagar precios más caros pues los costos operativos de la empresa grande son más caros que los de una empresa pequeña sobre todo en el rubro capacitación IT. Yo no estoy tan seguro de esto y por ello no voy a profundizar en este punto. Por eso quiero volver a los puntos (1) y (2). Una consecuencia de esto es que al dejar afuera a los pequeños proveedores, se genera una mayor concentraron en las grandes empresas, algo que a mi parecer el estado debería intentar evitar. Puede que aquí esté influyendo cierta cuestión política/ideológica, pero dejemos al margen el rol del estado regulador/justiciero. Si las pequeñas empresas pudieran convertirse en proveedores del estado, eso podría incentivar un ecosistemas más diverso de proveedores, promoviendo la competencia y ayudando a los pequeños emprendedores. Pero no termina aquí, en algunos escenarios es aún peor, el estado pide ciertos «avales» para que el proveedor pueda presentar su propuesta. Esto parece razonable para ciertos proyectos de gran envergadura, pero sin duda para cuestiones de IT hay convocatorias en las que perfectamente podrían obviarse esos «avales» que muchas veces las empresas chicas no tienen y que las dejan fuera de la convocatoria.

En un punto es un círculo vicioso: la operatoria del estado deja fuera a los pequeños proveedores, concentrando las contrataciones en las empresas grandes, haciendo que cada vez sean menos los potenciales proveedores. Cuanto menos oferta, más caros son los precios. Al aumentar los precios aumentan los presupuestos y el riesgo financiero que afecta cada vez más a los proveedores y achica la cantidad de potenciales proveedores. Y esto concentra cada vez las contrataciones en las grandes empresas y disminuye la oferta…