Dinámica de un grupo de investigación part-time

La mayoría de la gente que conozco que trabaja en investigación lo hace con una alta dedicación. En general tienen un cargo de tiempo completo en la academia y dentro de ese contexto hacen investigación y algunas otras tareas como dar clases o participar de proyectos de extensión.

Pero en el grupo de investigación de que yo trabajo nadie tiene una dedicación de tiempo completo en la academia. Más aún algunos tienen dedicación de tiempo completo en la industria y la cuestión académica la hacen en “tiempo-extra”. Solo el director del proyecto tiene dedicación de tiempo completo en la academia, pero aún así la mayoría de su tiempo está dedicado a cuestiones administrativas/operativas ya que además de dirigir nuestro proyecto es también el director de la carrera de grado.

En mi caso particular yo tengo un cargo docente de dedicación no-exlusiva para dictar una materia y hacer investigación y colaborar en cuestiones varias con la dirección de la carrera. El presupuesto que nos da el hecho de tener el proyecto formalmente radicado en la universidad está restringido para ser utilizado en viajes, entradas a conferencia, pago de algunos recursos, etc, pero no sueldos. Al mismo tiempo, como contraprestación tenemos que generar cierta cantidad de publicaciones.

Respecto de la dinámica de trabajo en nuestro grupo de investigación cada miembro trabaja en un línea de investigación de la cual es responsable y como tal establece el ritmo de trabajo y es quien “rema” para publicar los resultados de su línea de investigación. Al mismo tiempo cada uno colabora con alguna otra línea y obviamente el director del grupo está involucrado en todas las líneas. En mi caso mi línea de trabajo es en Métodos Agiles de Desarrollo de Software y colaboro con DiegoF quien trabaja en cuestiones de Usabilidad de Procesos. A su vez DiegoF colabora con mi trabajo. Mas allá de todos los experimentos, hallazgos y conclusiones que uno logre en su investigación el avance y aporte de un proyecto se mide en términos de publicaciones. Esto se debe a que la publicación tiene un doble cometido. Por un lado es un mecanismo de validación, previo a la publicación el trabajo es evaluado por un comité y solo es publicado si ese comité lo considera valioso y correcto. Por otro lado la publicación es la forma de difundir trabajos y sus hallazgos.

Conceptualmente uno debería hacer el trabajo de investigación y luego ver dónde publicar. Pero personalmente esto no me funciona, o sea, necesito poner un deadline para evitar el trabajo se extienda infinitamente. Por eso, cuando logro cierto grado de avance ya intento definir una conferencia para publicar y eso ya me establece un deadline de finalización.

Para este 2020 tengo en mi plan de trabajo hacer tres publicaciones, dos de las cuales ya tengo en mente donde. El número no es arbitrario sino que tiene que ver con tres hitos/avances esperados de mi proyecto de investigación.

Yo me sumé al grupo de investigación en 2016 con lo cual mi experiencia es bastante acotada, pero a pesar de ello en estos 4 años he publicado, dentro de mi línea de investigación, 5 artículos en conferencias locales y 4 en conferencias internacionales. Más allá de las publicaciones estoy muy conforme con lo logrado porque he aprendido mucho de los temas investigados y también de cuestiones de metodología de investigación.

Por estos días estamos planificando los próximos dos años del proyecto de investigación (las convocatorias de proyectos de UNTreF son bi-anuales). Personalmente creo que hemos consolidado el grupo y me parece que estamos en condiciones de sumar más gente, de hecho ya tenemos algunas incorporaciones confirmadas.

Breve reseña de algunos libros de patrones diseño

Continuando con el tema de patrones del post anterior, se me ocurrió compartir esta breve reseña de algunos libros de patrones diseño de mi biblioteca.

Design Patterns, de Gamma y amigos

Este es EL libro de patrones de diseño que acuñó el término. Es un clásico, tiene dos capítulos introductorios y luego presenta los patrones agrupados por tipo de patrón: de creación, de comportamiento, de estructura, etc. El conjunto de patrones presentados en este libro son comúnmente denominados “los patrones de Gamma”.
Una curiosidad del libro es que utiliza una notación gráfica para representar clases que es anterior (pero muy parecida) a UML. Por esas cosas de la vida que por momentos resultan inexplicables me compré la edición en castellano de este libro.

UML and Patterns, de Larman

Este es otro libro que para mi también es un clásico. Este libro tiene dos cuestiones que me gustan mucho. Por una la lado es un libro que presenta el uso de patrones de diseño en el contexto de un proceso de desarrollo en este caso el Proceso Unificado. Por otro lado, más allá de los patrones Gamma, este libro presenta un conjunto de patrones que denomina GRASP:

Este libro lo tomamos como referencia hace un par de año con @dfontde cuando armamos la primera versión de la materia Análisis y Diseño Orientado a Objetos en UNTreF.

Implementation Patterns, de Kent Beck

Tengo la sensación que este libro es muy poco conocido pero a mi me gustó mucho. Ma animaría a decir que es un libro de patrones de código, o sea son patrones “de bajo nivel”. Si bien el código está en escrito en Java, muchas de las cuestiones son más de programación orientada a objetos y por lo tanto resultan aplicables incluso cuando uno no trabaje con Java. En InfoQ hay una interesante entrevista a Kent Beck sobre este libro.

C++ Coding Standards, de Sutter & Alexandrescu

El subtitulo del libro es “101 Rules, Guidelines and Best Practices” y si bien ni título ni subtítulo hacen referencia a patrones el libro perfectamente puede clasificarse como un libro de patrones. Las recomendaciones/patrones son específicas de C++ y en general no son extrapolables a otros lenguajes. Cuando los patrones son específicos de un lenguaje, como en este caso, se los suele llamar idioms. Este libro me llegó por mera casualidad hace unos 15 años en la época en que cursaba Taller de Programación 1 en Fiuba donde aprendí C++ en profundidad.

Applying Domain-Driven Design and Patterns, de Jimmy Nilsson

Este libro fue publicado en 2006, y si bien el subtítulo “With Examples in C# and .NET“, varias de las cuestiones expuestas son extrapolables a otras tecnologías. De hecho el libro es una bajada a C#/.NET de las ideas de dos libros: Patterns of Enterprise Applicacion Architecture (fowler) y Domain Driven Design (Evans). A pesar de ser un libro de que tiene ~15 años, creo que sigue vigente.

En un próximo post, escribiré sobre algunos otros libros que no son específicamente de patrones sino de temas muy relacionados.

Cierre 2019 y Plan 2020

Se fue un año movido a nivel personal y nivel país ni te cuento. Esto tuvo algún impacto en mi actividad profesional. De entrada a nivel profesional y comparado con años anteriores aumenté mi dedicación académica. Esto estuvo motivado por varias cuestiones, pero uno de ellas fue mi decisión de completar mi maestría en Tecnología Informática Aplicada en Educación.

En lo que hace a mi trabajo en la industria, hice muy poco training (~6 %), casi todo mi tiempo estuvo dividido en partes iguales entre tareas de consultoría con equipos de desarrollo y tareas de “devops”.

Por otro lado participé de 6 conferencias en diversos países: Argentina, Uruguay, Brazil y España. Publiqué 3 papers y colaboré en un cuarto. Escribí 93 artículos este blog, colaboré con el libro de Fede Zuppa y fui jurado de la tesis de Maribel.

Para el 2020 espero completar mi postgrado en UNLP y dictar la primera edición del Seminario de Postgrado en Software Delivery en UNTreF.
En términos de industria, voy a comenzar el año trabajando en un proyecto de desarrollo con .Net Core y Kubernetes de cara a reemplazar una aplicación legacy.

Cierre del segundo cuatrimestre 2019 @MeMO2

Completamos una edición más de la materia, en términos estrictos es la quinta, pero dado que la primera solo tuvo 2 alumnos, estoy más inclinado a considerar que esta fue la cuarta.

Personalmente estoy muy conforme con el resultado y flujo de la materia. Y sin duda esto fue posible gracias a un equipo docente conformado por varios ex-alumnos. Además de Emi y yo como docentes nombrados, contamos con la colaboración de JoaquínC, TomasZ, JazminF, AldanaR, NachoI y PabloR. Gracias totales a todo el equipo.

Comenzamos el cuatrimestre con 21 inscriptos en guaraní, pero 2 de ellos nunca asistieron a clase. De los 19 que asistieron la primera semana, 2 abandonaron antes del comenzar con los trabajos grupales. Los 17 restantes completaron la materia.

En términos generales no hicimos cambios mayores respecto de lo que fue el primer cuatrimestre. Tuvimos:

  • 18 tareas individuales que incluyeron varios ejercicios de programación y unos 10 cuestionarios con sus correspondientes lecturas y videos
  • 2 trabajos grupales, uno de alcance variable y esfuerzo fijo y otro de alcance fijo y esfuerzo variable
  • 2 visitas de profesionales de la industria, Fede Diaz y Diego Sánchez, gracias a ambos

En feedback de los alumnos fue muy positivo y entre los accionables de mejora identificamos:

  • Hacer algún repaso tipo cierre de cada tema luego del cuestionario comentando los puntos destacados
  • Dar lecturas más cortas / enfocadas
  • Hacer una actividad para que los alumnos presenten sus propias experiencias profesionales
  • TP: Intentar que las iteraciones sean de jueves a jueves
  • TP: Durante el TP2 dedicar los lunes a repasar/acordar las especificaciones y ejemplos

Finalmente comparto algunas estadísticas de la encuesta final del curso completada por los alumnos (estos números son de la encuesta interna, los resultados de la encuesta que realiza el departamento aún no están disponibles):

  • Evaluación general del curso: 8.5 / 10
  • Claridad de los docentes: 4.7 / 5
  • Conocimiento de los docentes: 4.9 / 5
  • Dinámica de clases: 4.1 / 5
  • Materiales de estudio: 4.1 / 5
  • Dedicación promedio extra clase: 9 hs. semanales
  • Confirmidad con la nota de aprobación: 4.1 / 5

La nota promedio de aprobación de la materia fue 8 (desvío 0.96).

Balas de plata, carros delante de los caballos y vende humos

No dejo de asombrarme de las realidades tan distintas que enfrentan las organizaciones en términos de software delivery y la “ceguera” de algunos consultores, coaches y líderes.

Dos por tres escucho frases del estilo “hay que implementar X” o “hacer Y está mal” o “tienen que usar Z”,expresadas en forma absoluta como si fueran balas de plata o como si el contexto no fuera relevante. Muchas veces quienes se pronuncian de esta forma son personas que están trabajando en escenarios de innovación , transformación o renovación tecnológica en el contexto de sistemas de información en los cuales muy posiblemente sus frases o recetas sean apropiadas. Pero la realidad es mucho más amplia, hay contextos que no son sistemas de información y hay contextos que no son de transformación. Yo mismo me suelo involucrar en proyectos de mantenimiento de aplicaciones legacy. Esta cuestión que estoy planteando aplica tanto a cuestiones de proceso como a cuestiones de tecnología.

En términos de proceso he visto consultores impulsando iniciativas del tipo #noEstimates o #noProjects y criticando el uso de burndown charts y el uso de velocity/capacity para planificar. En mi opinion estos consultores ven sus recetas como balas de plata cuando todos sabemos que tal cosa no existe.

En términos de tecnología veo consultores proponiendo cuestiones como Continuous Delivery cuando tienen aplicaciones con alto grado de acoplamiento, baja cohesión, modelos de dominio anémicos y sin pruebas automatizadas. Del mismo modo veo consultores de calidad implementando Sonar cuando los equipos de desarrollo ni siquiera leen los warnings que tira el compilador de Java o el propio IDE. En mi opinión estos consultores ponen el carro por delante del caballo, lo cual en lugar de ayudar genera complejidades adicionales.

En un punto me pregunto si estos consultores no terminan siendo “vende humo”.

Desorientados con los patrones de diseño

Los patrones de diseño son una herramienta muy popular en la actualidad, imagino que la gran mayoría de los programadores profesionales utilizan en sus soluciones algún patrón de diseño. Incluso en algunos casos, es posible que estén usando algún patrón sin ser conscientes de ello.

Sin embargo, he notado que en muchos casos se utilizan patrones sin tener en claro el problema que el patrón resuelve. En reiteradas ocasiones me he encontrado preguntado a un programador “¿Qué problema estás resolviendo con este patrón?” y he obtenido respuestas conceptualmente incorrectas. Me me encontrado con gente que cree que aplicar Model-View-Controller le dará escalabilidad a su solución. También me he encontrado con gente que organiza su solución con Layers y no sabe a ciencia cierta porque.

La razón para aplicar un patrón debería ser que el patrón en cuestión resuelve de forma satisfactoria un problema o situación concreta que uno está enfrentando. Esto implica que uno debería en primera instancia entender el problema que tiene entre manos y luego buscar un patrón que resuelva ese problema. Si no tenemos en claro el problema podríamos terminar aplicando un patrón menos apropiado.

Haciendo una analogía con la cocina: uno tiene que preparar una cena con determinas características, entonces busca en un libro de recetas alguna que se ajuste a la necesidades de la cena en cuestión. Obviamente que ese proceso de buscar el patrón apropiado puede no ser instantáneo. Uno podría estar horas buscando un patrón hasta encontrar uno apropiado o incluso podría no encontrarlo. Es ahí donde puede resultar muy valiosa la experiencia personal de cada uno y el hecho de haber leído algunos libros de patrones.

En línea con esto último, tengo que ganas de hacer un reunión (meetup) para compartir patrones diseño. Se me ocurre una consigna del tipo:

Cuentame tu problema
(y el patrón con que el que lo resolviste)

Todos los que quieran presentar se anotan con anterioridad a la reunión y al hacerlo indican que patrón presentarán. Luego durante la reunión:

  • Cada presentador tiene 15 minutos (este tiempo se puede ajustar dependiendo de la cantidad de gente presentar).
  • La presentación debe ser de un caso real de aplicación del patrón, o sea: no vale simplemente contar un patrón conceptualmente. Tiene que haber sido un caso de aplicación en un contexto de proyecto real.
  • La presentación del patrón debe empezar contando el contexto y el problema particular a resolver.
  • Debe incluir también las diferentes opciones consideradas para la solución (si es que la hubo)
  • A continuación se presenta el patrón
  • Finalmente se mencionan los efectos colaterales de la aplicación del patrón

Make sense?

Primera Ingeniera en Computación de UNTreF

Ayer Maribel Maisano(@maribelmai) hizo la defensa de su trabajo final y obtuvo su título de Ingeniera en Computación convirtiéndose en la primera egresada mujer de la carrera.
Tuve a Maribel de alumna años atrás y esta vez tuve el honor de ser parte del jurado evaluador de su trabajo. Los otros dos jurados fueron Pablo Cosso y Luis Argerich.

El reglamento de UNTreF no estipula una nota para los trabajos finales, sino simplemente un dictamen de aprobado / desaprobado, pero de haber tenido que poner una nota, le hubiera puesto un 10. Mis felicitaciones para Maribel.