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.

Anuncios

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/

Primeros egresados UNTreF

El pasado miércoles por la tarde tuve la oportunidad de asistir a la defensa del trabajo final de carrera de los dos primeros egresados de la carrera de Ingeniería en Computación de la Universidad Nacional de Tres de Febrero: Fernando Scorpiniti y Fernando Degirmenntjis. Adicionalmente fui jurado evaluador de uno de estos trabajos. Más allá de lo que esto representa para los egresados y sus familias, este es un gran hito para la carrera e incluso para la universidad. Mis felicitaciones a ambos Fernandos.

PD: Curiosamente también fui jurado evaluador del trabajo de primer egresado de la Tecnicatura en Programación de UNQ, ¡que loco!

Build de 10 minutos y categorización de tests

Cuando el equipo actual tomó a su cargo el sistema este tenía una alto grado de inestabilidad y prácticamente no tenía tests automatizados. Gradualmente se fueron agregando tests que ayudaron a mejorar a la estabilidad del sistema. En un punto se llegó a tener unos ~2600 tests de componentes/unitarios cuya ejecución excedía los 30 minutos. Todos estos tests eran ejecutados como parte del build de integración continua. A esto se sumaba el hecho de que equipo hacía feature-branches, los cuales también eran buildeados automáticamete, aumentando la carga del build server. Llegado un punto, cada vez que un developer hacía un commit (+push) tenía que esperar, en el mejor de los casos, unos 40 minutos para obtener feedback. Podía llevar a pasar que el build server estuviera ocupado y entonces el build quedaba encolado estirando aún más el tiempo de espera.

Ante esta situación hicimos dos cosas. En primer lugar instalamos un segundo agente del Build Server, para bajar el tiempo tiempo de espera en cola. En segundo lugar categorizamos los tests y ajustamos la configuración del build server. En este segundo punto quiero profundizar.

Es un práctica muy difundida y aceptaba, el tener un build de integración/feedback continua que no exceda los 10 minutos (algunas referencias para profundizar aquí y aquí). En línea con esto decidimos categorizar los ~2600+ tests, identificando aquellos que cubrían las partes críticas de la iteración. Identificamos unos ~600 tests fundamentales cuyo tiempo de ejecución resultó en unos 7 minutos. Categorizamos esos tests como “core”. Al mismo tiempo ajustamos el build server para que se ejecuten en forma continua (ante cada commit+push) los tests “core” y de los “current” (pertenecientes a la iteración actual), de manera de poder tener un feedback “rápido”. Por otro lado, creamos otra tarea que se ejecuta al fin del día para correr el set completo de tests.