Recuerdos a 10 años de haberme recibido

Hoy se cumplen 10 años de que terminé mi carrera de grado en ingeniería en informática. Fue el día 17 de diciembre de 2007 que defendí mi tesis, curiosamente no escribí un reseña de la defensa en este blog, por lo cual me parece que al cumplirse 10 años es un momento propicio para hacerlo.

Empecé a trabajar en mi tesis (muy a cuenta gotas) en 2005 mientras cursaba el último tramo de la carrera. Tenia en mente trabajar sobre programación orientada a aspectos (AOP), un tema que por aquel momento se mostraba prometedor, pero no estaba seguro del tema concreto.

Recuerdo haber leído la tesis de Fernando Asteasuian la cual me resultó una muy buena fuente para entender el estado del arte de AOP en aquella época. Curiosamente en 2016 tuve la oportunidad de conocer a Fernando personalmente durante el CONAIISI 2016 en Salta.

También recuerdo haber asistido a la defensa de tesis de Alan Cyment y Ruben Altman quienes también trabajaron sobre AOP. Más aún, recuerdo una charla con Alan en el café de una estación de servicio en la zona de la estación Bulnes del subte D en la que le conté algunas de las ideas que yo estaba considerando para mi tesis. Por esas vueltas de la vida volví a cruzarme con Alan algunos años más tarde durante el surgimiento del movimiento ágil en Buenos Aires.

No fue hasta fines de 2006 que empecé a trabajar de forma constante en la tesis.  Recuerdo dedicar consistentemente todas las mañanas de sábado de 2007 a la escritura de la tesis, volcando en texto ideas que maduraba de durante la semana. Mi directora de tesis fue Rosita, excelente profesora con la hoy en día sigo en fluido contacto. El título final de mi tesis fue: «Utilización de Programación Orientada a Aspectos en Aplicaciones Enterprise». Los jurados evaluadores fueron los profesores Osvaldo Clua, Carlos Fontela y Guillermo Pantaleo.

El texto completo de la tesis está disponible aquí.

Finalmente comparto dos fotos de aquel día de la defensa.

 

(re) Pensando el AOC

Reciente el «triunvirato» organizador del AOC Chile publicó un video abriendo la convocatoria de ideas para la edición 2018. En ese sentido aquí va mi opinión.

Considerando que la dinámica de evento implica tener un conjunto de personas conviviendo full-time por un par de días en un escenario «semi-aislado» de la sociedad, creo que es oportunidad excelente para generar algo de valor. Más aún, apostaría a generar algo de valor para la comunidad, no solo para los participantes del evento. En cierto modo, el primer libro del AOC puede verse como un ejemplo de esto. Otro ejemplo son los videos que generó Rob en el AOC Chile 2017.

Ahora bien, pare llevar a cabo iniciativas de valor es necesario un plan y un equipo. Si bien es posible generar tanto los equipos como el plan al inicio de la conferencia, creo que sería mejor que sean definidos de antemano de forma de aprovechar mejor el tiempo de la conferencia y al mismo tiempo para asegurar que se cuente con todo lo necesario para trabajar.

Bajando a tierra mi borrador de propuesta es:

  • Modificar el mecanismo de inscripción/postulación de manera que la misma pueda ser grupal.
  • Al mismo tiempo cada grupo postulante debe hace un propuesta para generar valor.
  • Finalmente el grupo debe estar abierto para incluir más gente.

Pongo un ejemplo:

  • Maria es diseñadora gráfica y trabaja en cuestiones de UX en una empresa de desarrollo y se postula en forma individual para el AOC, tal cual se hizo el año pasado.
  • Diego, Martin y Nicolás son developers que en un evento comunitario conocieron a Mateo que trabaja en una ONG. Entonces deciden postularse como grupo en el AOC con la propuesta de valor de hacer una aplicación para la ONG en la que trabaja Mateo.
  • Resulta que el grupo de Diego, Martín, Nicolás y Mateo es seleccionado y de esa forma todos los integrantes del grupo ganan su vacante para participar del AOC.
  • Siguiendo con el mecanismo San Saru, el grupo elige de entre los postulantes individuales a una persona para invitarla a colaborar en su propuesta de valor. En ese sentido eligen a Maria. Un punto importante aquí: si María acepta la invitación, entonces implica que se compromete a que durante el AOC trabajará en la propuesta de valor del grupo que la seleccionó.

¿Muy loco?

 

Conferencia sin Sponsors, podemos pero ¿queremos?

En términos generales la mayoría de las conferencia de índole comunitaria se financian a partir de dos fuentes principales: el pago de las entradas por parte de los asistentes y los aportes de los sponsors.

En algunos casos el monto recaudado por el lado de las entradas representa un aporte muy inferior al recaudado por el lado de los sponsors.  De hecho me consta de varias conferencias que no habrían podido realizarse sin el aporte de los sponsors.

Sin embargo esta probado que es posible hacer conferencias sin sponsors, dos ejemplos bastante distintos son: Agiles Argentina y Agiles Latam 2017. Paso a analizar.

Agiles Argentina es una conferencia relativamente chica, no tengo números oficiales, pero en base a las veces que asistí, creo que en el mejor de los casos ha reunido unas 80 personas. Desde hace un par de años la conferencia se hace en un lugar cedido gratuitamente por alguna institución (típicamente universidades) y el catering es auto-organizado. Si bien en algunas ocasiones ha habido sponsors, su aporte no ha sido ni remotamente condicionante del evento, en general el aporte de los sponsors se ha utilizado para habilitar que viaje gente desde otras ciudades. A cambio de su aporte estos sponsors han tenido su logo en sitio de la conferencia y a lo sumo algún póster en el lugar de la conferencia y los flyers de difusión.

Otro ejemplo bastante distinto en términos de escala es la reciente conferencia latinoamericana Agiles 2017. En este caso hablamos de un evento de 800+ personas de diversos países, donde no hubo catering auto-organizado pero donde los asistentes pagaron una entrada de  u$d ~100. Esta conferencia también se realizó en las instalación cedidas gratuitamente de una institución y  no hubo ningún tipo de sponsors.

Dicho esto, queda claro que es posible hacer conferencias sin sponsors y me alegra mucho, pero me queda la duda: ¿realmente queremos conferencias sin sponsors?

Menciono algunos puntos que podrían llegar a considerarse positivos de tener sponsors:

  • Los sponsors hacen algún tipo de aporte a la conferencia, ya sea directamente dinero o en en «especias» (por ejemplo pagar el coffee break, ayudar en los gastos de asistentes extranjeros o proveer un espacio físico para la conferencia)
  • Ciertos sponsors pueden dar «jerarquía» a la conferencia. Por ejemplo: ciertas organizaciones (potenciales sponsors) tienen cierta fama positiva y eso puede «contagiarse» a la conferencia. Al mismo tiempo cuando alguien tiene que pedir un día de trabajo para ir a la conferencia,  un jefe que no conoce puede verse influenciado al ver los sponsors de la conferencia (obviamente esa influencia puede ser negativa o positiva, y por eso hay que elijir muy bien a los sponsors).
  • En línea a lo anterior, hay ciertas organizaciones que no tienen fines de lucro como ONGs que al ser sponsor, más allá del aporte económico también pueden colaborar en cuestiones de difusión.

Pensando en el caso concreto de Agiles Latam y en el último punto de la lista, me parece que sería valioso contar en futuras ediciones poder contar mínimamente con el apoyo de organizaciones como Agile Alliance e IEEE.

Ya para cerrar: me parece fundamental no necesitar sponsors para llevar adelante la conferencia, pues ello da mucha libertad y al mismo tiempo una «posición de poder» en caso que uno quiera negociar con sponsors. Con esta premisa, yo voto por tener sponsors delicadamente seleccionados.

Libros de Ingeniería de Software

En tiempos de las «lecturas cortas» (blog post, twits, etc) sigo convencido de que una carrera universitaria requiere en algún punto leer libros. En línea con esto, en cada materia o taller que dicto, busco tener un libro de referencia que cubra la mayor cantidad de contenidos posibles de la materia en cuestión. En este sentido el libro de referencia para mi materia de Ingeniería de Software, es «The Art of Agile Development» de Shore & Warden, el cual es básicamente un libro de ingeniería de software con una visión Extreme Programming.

Adicionalmente, desde hace ya unos años, tengo la costumbre de llevar un libro de mi biblioteca a cada una de mis clases, para que lo estudiantes puedan darle una mirada (cabe destacar que amo los libros en papel). Esta es la lista de libros que compartí con mis alumnos de Ingeniería de Software en UNTreF este cuatrimestre:

  • The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks Jr.
  • Rapid Development, Taming Wild Software Schedules by Steve McConnell
  • Extreme Programming Explained by Kent Beck
  • Planning Extreme Programming by Kent Beck
  • Specification by Example, how successful teams deliver the right software by Gojko Adzic
  • Agile Estimating and Planning by Mike Cohn
  • More Agile Testing, Learning Journeys for the whole team By Janet Gregory
  • Soft Skills: The software developer’s life manual by John Sonmez
  • The Software Craftsman: Professionalism, Pragmatism, Pride by Sandro Mancuso
  • The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations by Gene Kim
  • DevOps, A software Architect’s Perspective by Len Bass
  • Site Reliability Engineering, How Google Runs Production Systems

 

C#: new project, old discussion

Last week I started a new C# project with an existing team that was in charge of the maintenance of an existing application. One of the first things we did was defining the project structure in terms of development tools/frameworks. This is not a trivial discussion in C# because the are always 2 ways of doing things: the Microsoft way and the Community way.

Microsoft way is very straight forward for working with Visual Studio and writing quick (and usually dirty) code. But if you want to build testeable, robust and maintainable solutions, it could be better to stay with the community way.

The community way usually includes open source and community supported tools/frameworks like NUnit and OpenCover. One drawback of the community way is that you have to take care of integration the different tools/frameworks, a concern that is usually already solve when you go with the Microsoft way. As a consequence of this situation I implemented some time ago my BuildTools package.

Last week, when we started the new project I was thinking to use that BuildTools package, but I realized that Visual Studio 2017 has been released recently, so I decided to re-think the strategy in case something has changed.

I after some research I was able to create a MsBuild script to run tests with NUNit and measure coverage with OpenCover. But I was not able to find a nice solution for NuGet, it seems NuGet is now firs-class citizen inside Visual Studio, but the nuget.exe is not part of the Visual Studio, so we still have to install on by hand.

Here is the sample project I am using to document my approach, any feedback is welcomed.

In future articles I will write about the strategy to integrate React and its build stack into the C# solution.

Agiles Argentina 2017

Entrando como por la ventana, un evento más apareció en el tramo final del año: Agiles Argentina 2017.
Si bien se venía hablando de su realización desde hace un par de semanas, recién el jueves pasado se confirmó su realización.
La cita es para los días 24 y 25 de noviembre (viernes y sábado próximos) en la sede Paseo Colón de la Facultad de Ingeniería de la Universidad de Buenos Aires. Como de costumbre el catering es auto-organizado, la entrada es libre y gratuita.

Más información en: https://www.meetup.com/es/agiles-arg/events/245234890/

Mis notas del CONAIISI 2017

Jueves y Viernes pasado estuve participando por segunda vez del CONAIISI. En ese contexto estuvimos con Fernando Gainey y Diego Fontdevila presentando nuestro trabajo An empirical study on the usage of technical and organizational practices in the Agile Community. Personalmente me gustó como salió nuestra presentación. Las diapositivas utilizadas están disponibles aquí.

Más allá de nuestra presentación, tuve la oportunidad de escuchar la exposición de algunos otros trabajos de investigación que me resultaron interesantes.

Entre los trabajos de estudiantes hubo un par que me parecieron muy buenos. En este contexto quiero destacar el trabajo final de carrera Ema Suriano y sus colegas de la UNLAM quienes desarrollaron un artefacto para habilitar el aprendizaje/asistencia de escritura/lectura braile. Más información sobre este desarrollo está disponible en https://blindle.github.io/.

Por otro lado, me llamo mucho la atención que ciertos trabajos no fueron presentados a pesar de que algunos de los autores estaban presentes en la conferencia.

Más allá de la cuestión académica, el jueves por la noche fue evento social de la conferencia en el patio cervecero de la cervecería Santa Fe. Lugar 100% recomendable.

Finalmente en el cierre de la conferencia, se anunció que el CONAIISI 2018 será en Mar del Plata.

Con Fer y Diego en el camino de vuelta casa.
Cena social en el patio cervecero.
Exposición de pósters de trabajos estudiantiles.

Conferencias de cierre de Año

Hoy y mañana estoy participando del Congreso Nacional de Ingeniería Informática y Sistemas de Información (CONAIISI) que se está desarrollando en la Facultad Regional Santa Fe de la Universidad Tecnológica Nacional. En este contexto voy a estar presentando el trabajo An empirical study on the usage of technical and organizational practices in the Agile Community.

La semana próxima, estaré participando de la Smalltalks. La misma se desarrollará del 8 al 10 de noviembre, en la Universidad Nacional de La Plata.

Banca DevOps, nuevo proyecto

Desde hace un tiempo hay en Argentina un auge de transformación digital en el sector bancario, el cual suele incluir iniciativas Agile + DevOps. En ese contexto, fui contactado hace un par de semanas por un banco para colaborar en la optimización de su flujo de valor (en realidad el pedido vino por otro lado y después de un par de charlas derivó en esto).

Luego de un par de conversaciones con las personas que me convocaron, nos pusimos de acuerdo y accionamos. La idea es comenzar trabajando sobre un equipo en concreto, y luego incorporar gradualmente otros equipos. La intención es poder ir resolviendo problemas reales de los equipos y definir reglas/patrones a partir de generalizaciones de lo realizado en cada equipo.

Una de mis premisas de trabajo cuando participo de este tipo de iniciativas es definir criterios claros y objetivos de éxito. Muchas veces he visto iniciativas fundamentando su éxito en frases tales como «La gente se siente más contenta», lo cual puede estar bien para «la gente», pero muchas veces resulta insuficiente para quien paga. Tal vez sea una limitación mía, pero no he tenido éxito convenciendo gerentes con «sensaciones». Tal vez sea por mi perfil ingenieril: las sensaciones me parecen importantes, pero a la hora de tomar desiciones quiero números concretos. En este sentido, en el contexto de esta nueva iniciativa, hemos definido dos métricas iniciales como referencia: lead time y risk exposure.

Continuará…