Balance 2022

Hace varias semanas tenia pendiente la publicación de este post. Creo que para muchos el 2022 fue «el año de la vuelta»: volvimos a las aulas, volvimos a la oficinas, volvimos a encontrarnos, volvimos… ¿mejores? Mmmm, no sé, pero sin duda volvimos distintos. De hecho algunos no volvimos completamente, algunas casas de estudio (y empresas) tomaron consciencia de que hay ciertas cuestiones de la educación (y del trabajo) que pueden verse beneficiadas de un esquema híbrido online/onsite. En mi caso particular, no volví a pisar las oficinas de un cliente en parte porque he estado trabajando con clientes del exterior. Y en el ámbito académico, adoptamos un esquema híbrido que consideramos lo más apropiado didácticamente para nuestra materia.

Al igual que el año pasado tuve una dedicación muy similar en academia e industria.

En el ámbito académico:

En el ámbito industrial, la primera mitad del año estuve trabajando como parte del staff de RadioCut, una aventura que inicié en 2021 con la intención de ser parte de un producto pero que lamentablemente no resultó como esperaba. Ya en la segunda mitad del año volví a mi trabajo de consultoría/freelance. Finalmente por otro lado dicté en reiteradas ediciones mi Taller de Introducción a Kubernetes y realicé la primera edición del Taller de Prácticas Técnicas para Scrum Masters.

Sobre el uso de Gherkin/Cucumber y esa costumbre de dormir en la mesa

Toda herramienta es creada con un fin y luego usada como a cada uno le parece. El ejemplo que siempre pongo es el de la mesa: podríamos pensar que la mesa fue pensada para sentarse a comer o a trabajar, pero sin embargo alguien podría usarla para acostarse a dormir. Esto puede traer dos riesgos: 

  1. que no resulte muy cómodo/conveniente o incluso que tenga limitaciones, «¡que incómodo dormir en la mesa! => es razonable ya que no fue pensada para eso»
  2. que posiblemente haya una herramienta más apropiada => ¿qué tal si probas dormir en la cama?

(tengo la sensación de que esta situación de «dormir» en la mesa se repite frecuentemente en la industria del software con distintas herramientas)

En este sentido Gherkin fue pensado como una herramienta de colaboración/comunicación/especificación para ser utilizada de programar la solución y que nos trae el beneficio adicional de poder automatizar utilizando alguna herramienta Gherkin-compatible como Cucumber, Cucumber-jvm, Behat, etc, etc.

Sin embargo vemos en la industria un uso alternativo de Gherkin/Cucumber: la automatización de pruebas una vez que la solución ya está programada. Si bien este escenario esalgo perfectamente válido a mi no me resulta conveniente. O sea: si no vamos a tener el involucramiento del usuario y no vamos a trabajar colaborativamente en entender el negocio antes de empezar a programar y solo buscamos automatizar pruebas, me resulta entonces más práctico programar las pruebas con alguna herramienta de la familia xUnit o Rspec. Un escenario en el que automatizar con Gherkin/Cucumber «a posteriori de la programación» es cuando tenemos una persona describiendo la prueba (erscribiendo Gherkin) y otra persona escribiendo el código de automatización por detrás del Gherkin. En lo personal sigue sin convencerme.

Pero al margen de mis gustos y convicciones, hay una diferencia importante en el uso de Gherkin dependiendo de la intención con la que lo estamos usando. Más concretamente la forma en la que vamos a escribir los escenarios con Gherkin va a ser distinta. Veamos un ejemplo, tomemos una funcionalidad de login, si estamos usando Gherkin como herramienta de colaboración/comunicación/especificación y seguimos las recomendaciones de los creadores, podríamos tener lo siguiente:

Antecedentes:
  Dado que existe un usuario "juan" con clave "claveFuerte123"

Escenario: Login exitoso
  Cuando un usuario ingresa credenciales "juan" y "claveFuerte123"
  Entonces el login exitoso

Escenario: Login fallido por clave incorrecta
  Cuando un usuario ingresa credenciales "juan" y "claveIncorrecta"
  Entonces el login es fallido

Algunos puntos para destacar:

  • El foco está en el comportamiento omitiendo todo detalle de implementación
  • No hay ninguna mención a elemento de presentación/pantallas/html
  • Los escenarios son muy cortos

Veamos ahora una versión alternativa que típicamente podría ser creada «post-programación» con el fin de automatizar una prueba de regresión.

Antecedentes:
  Dado que existe un usuario "juan" con clave "claveFuerte123"

Escenario: Login exitoso
  Dado que en el campo "usuario" pongo "juan"
  Y que en el campo "clave" pongo "claveFuerte123"
  Cuando hago click en el "Login"
  Entonces veo el mensaje "Bienvenido"

Escenario: Login fallido por clave incorrecta
  Dado que en el campo "usuario" pongo "juan"
  Y que en el campo "clave" pongo "claveIncorrecta"
  Cuando hago click en el "Login"
  Entonces veo el mensaje "Credenciales incorrectas"

A diferencia del otro caso aquí vemos mención a los elementos de presentación/pantalla y un detalle «del cómo», esto se debe a que el escribir el Gherkin de esta segunda forma permite reutilizar código de automatización. O sea, el paso «Dado que en el campo <x> pongo <v>» es completamente genérico y lo puedo utilizar tanto en el escenario de login como en cualquier otro. Por otro lado el paso «Cuando un usuario se logueo con credenciales «juan» y «unaClaveIncorrecta» es muy específico del login.

Entonces:

  • En un contexto donde el objetivo central es la automatización, será mucho más probable encontrarnos con Gherkin del segundo estilo.
  • En un contexto donde el objetivo es entender/comunicar será más probable (y conveniente) el uso de Gherkin del primer estilo.

Estos dos estilos de Gherkin que menciono aquí son en cierto modo dos extremos. Asimismo, si bien la sintáxis de Gherkin no viene sufriendo grandes cambios, la forma de uso ha ido variando dado pie a distintos estilos. Lo importante para mi es que cada equipo establezca explícitamente un conjunto de convenciones sobre su uso que estén en sintonía con el uso que le vayan a dar.

Para aquellos que apuesten a utilizar Gherkin como herramienta de colaboración/especificación les recomiendo la serie de libros de Rose y Nagy «The BDD Books«.

Sobre las modalidades de contratación: freelance, contractor y empleado

Hablando de «modalidades de contratación» en el mundo IT podemos identificar en un extremo el «empleado en relación de dependencia» y posiblemente en el otro al «freelancer».

Cuando alguien es contratado en relación de dependencia es un «empleado pleno», goza de una serie derechos de acuerdo a la legislación vigente que incluye típicamente (en Argentina) cuestiones tales como aporte a la seguridad social, cobertura médica privada, indemnización en caso de despido injustificado, etc, etc. A esto, algunas empresas agregan beneficios extra como posibilidad de comprar acciones de la empresa, días extra de vacaciones, etc. En este contexto el empleado típicamente debe trabajar determinada cantidad de horas mensuales en un determinado rango horario (con mayor o menor flexibilidad) y a fin de mes cobra un sueldo fijo seguro.

Por su parte el freelancer no trabaja para un cliente en particular, más aún, no tiene cliente fijo (pues si lo tuviera seria posiblemente una relación de dependencia «encubierta», algo penado por la ley) y por ende no goza de todos los beneficios del empleado en relación de dependencia. No tiene sueldo asegurado y debe encargarse él mismo de sus cargas sociales, su cobertura médica, etc, etc. . Tiene que salir a buscar clientes, vender, ejecutar y cobrar. Puede no sonar muy atractivo, pero tiene algunos beneficios que para algunas personas son muy valiosos. Puede elegir en qué proyectos trabajar, con quién trabajar, cuando trabajar (esto es medio relativo porque dependiendo de que tipo de trabajo realice, puede que tenga que trabajar en un horario fijo o al menos en el rango típico de oficina). Puede incluso elegir cuánto cobrar, puede cobrar más (si se da mañana para venderlo) o incluso cobrar menos si por alguna razón «estratégica» (o de gusto) así lo desea. Quienes prestamos servicios de consultoría solemos trabajar en esta modalidad.

En cierto modo a mitad de camino entre las dos modalidades previamente mencionadas hay una modalidad muy comúnmente utilizada por empresas de USA. Es lo que habitualmente se denomina «contractor». Alguna vez escuché a alguien referirse a este tipo de contratación como «relación laboral precarizada» porque el «contractor» muchas veces tiene muchas de las obligaciones de los empleados en relación de dependencia pero sin los derechos/beneficios de estos. Ojo aquí, hay que tener presente que las legislaciones laborales son distintas en USA y en Argentina, entonces cuando digo «relación precarizada» lo digo a la luz de la legislación Argentina. Para el empleador resulta típicamente más «barato» el contractor que el empleado en relación de dependencia y al mismo tiempo le da más flexibilidad. Por su parte el trabajador «contractor» tiene alguna cuestiones como el empleado en relación de dependencia en el sentido que tiene que trabajar determinada cantidad de horas por mes, típicamente no elige sus proyectos ni con quien trabaja, pero tampoco tienen que andar buscando clientes ni gestionando cobros.

Se me ocurrieron dos ejemplos ambientados en Juego de Tronos. Un caso típico de freelancer es Bronn, de hecho el término freelancer hace referencia a esos caballeros «lanzas libres» que vendían sus servicios a uno u otro señor. Típicamente un mercenario. En el otro extremo están los miembros de la Guardia Real, los capas blancas, que son empleados en relación de dependencia del rey.

Libro: Código Sostenible

Hace un par de días terminé de leer este libro escrito por Carlos Blé. Me pareció muy bueno y me gustó mucho.

El libro es un muy buen compendio de buenas prácticas de programación y diseño. Reúne temas ya tratados en otras publicaciones y agrega temas que personalmente nunca había visto en un libro. En cada tema, más allá de la explicación y algún ejemplo, se suma la opinión de Carlos, siempre pragmática, constructiva y basada en la experiencia.

El libro está escrito en castellano, lo cual también suma puntos, ya que no tengo presente otros libros de esta temática escritos en castellano. Un punto a mi parecer negativo es que los ejemplos de código están en inglés, lo cual me resultó molesto por tener que cambiar de idioma entre el código y la prosa, pero es un tema menor.

Varios de los temas que cubre el libro son temas de MeMo2, o mejor dicho, son temas que nos gustaría que los alumnos de MeMo2 ya tengan asimilados. Lamentablemente no siempre los tienen asimilados y por ello nos vendría muy bien contar con este libro como recurso de estudio. La editorial del libro (Savvily) tiene un acuerdo para que los estudiantes puedan acceder gratuitamente a sus libros, pero dada la burocracia de UBA, veo muy difícil que se logre firmar el acuerdo. De todas formas, no pierdo la esperanza.

Al igual que Code Complete y The Pragmatic Programmer, este libro tiene contenido que todo programador debería conocer.

Agradezco a Carlos por haber escrito este libro pues lo considero un gran aporte a la comunidad IT de habla castellana.

Jira no es el problema

Una y otra vez leo en redes críticas a Jira. Y no son críticas que tengan que ver con que el producto sea inestable. Es como que la gente «sufriera» al usar Jira. Algo así como que cada vez que hacen alguna acción en Jira recibieran una descarga eléctrica al estilo picana.

De entrada Jira es una herramienta y como tal no es intrínsecamente buena ni mala, todo depende de cómo se la use. Jira ofrece un conjunto de funcionalidades para dar soporte a equipos que pretenden trabajar en un contexto «agile». Una confusión muy habitual está dada por gente que cree que trabaja de forma «agile» por el solo hecho de usar Jira. Esto es sin duda una de las fuentes de crítica que recibe Jira, pero no es un problema de Jira sino de ese subconjunto de usuarios.

Algunas otras críticas que ha recibido Jira tienen que ver con «la interpretación» (o tal vez deba decir implementación) que hace Jira de «agile». Ejemplo: permitir hacer estimaciones en horas cuando la estimación en horas no es lo que se estila en agile, entonces algunos «extremistas» se agarran de esto para decir «Jira es anti-agile». Que la herramienta permita estimar en horas no significa que obligue a trabajar así (no estoy seguro que esto de la estimación en horas siga siendo así, pero no es relevante, es solo para ejemplificar).

Otras críticas vienen de gente que no le gusta «trackear su trabajo en Jira». Aquí hay 2 cuestiones: 1) No se la agarren con la herramienta sino con quien les exigió que la usen de esa forma y 2) En general a quien no le gusta trackear el trabajo, no le gusta hacerlo con Jira ni con ninguna otra herramienta.

Mi punto es: Jira es simplemente una herramienta que ofrece una serie de funcionalidades «más o menos» alineadas con una forma de trabajo «Agile».

A mi parecer el problema surge a partir de dos situaciones iniciales:

  1. gente que se pone a utilizar la herramienta sin hacer la correspondiente personalización. No diseñan su forma de trabajo, sino que simplemente ponen Jira y dejan que Jira defina su forma de trabajo. Dicho en criollo: ponen el carro por delante del caballo.
  2. gente que hace una personalización «inconveniente» de Jira en el sentido que la personalización realizada resulta incómoda para quienes luego deben usar la herramienta diariamente. Esto resulta muy curioso porque una de las premisas de Agile son los equipos autoorganizados y un equipo autoorganizado debería poder personalizar la herramienta de gestión a su gusto (o incluso elegir la herramienta de gestión), sin embargo en más de una organización, la personalización de Jira (o la herramienta de gestión que sea) la decide gente que luego no usa la herramienta diariamente.

Cierro con algunas preguntas para aquellos que no les gusta Jira (en realidad creo que aplica a cualquier herramienta de gestión):

  • ¿pensaste los tipos de los items de backlog de tu proceso y luego configuraste Jira? o ¿directamente te pusiste a utilizar lo que traia el template de Jira?
  • ¿pensaste los estados y transiciones de estados de los items de backlog de tu proceso y luego configuraste Jira? o ¿directamente te pusiste a utilizar lo que traia el template de Jira?
  • ¿pensaste los campos/datos de los items de backlog de tu proceso y luego configuraste Jira? o ¿directamente te pusiste a utilizar lo que traia el template de Jira?

Si realmente hiciste el ejercicio de «diseñar» tu proceso y luego lo plasmaste en la herramienta y aún así estas desconforme con Jira, entonces tal vez tu crítica este justificada. Pero si no hiciste el trabajo de «diseño» de tu proceso, entonces….

Docencia: vocación vs. obligación

En FIUBA la gran mayoría de los docentes en el área de computación son de dedicación parcial lo cual básicamente significa que van a la facultad a dictar una materia y listo. Esta dedicación parcial implica formalmente de ~10 horas semanales y un sueldo en sintonía con eso, con lo cual muchos de estos docentes ejercen la docencia más por gusto (¿vocación?) que por necesidad, ya que casi todos «viven» de su trabajo en la industria. Más aún, algunos ni siquiera tienen nombramiento formal, lo cual implica que no perciben un sueldo. Al mismo tiempo, en general no hacen investigación ni ninguna otra actividad en la universidad salvo tal vez colaborar en alguna cuestión como participar de una comisión asesora o dirigir los trabajos finales de los alumnos. Es posible que esta situación también ocurra en alguna otra institución pero no puedo asegurarlo. En lo personal, esta situación de FIUBA yo solía verla como «inconveniente» ya que a nivel institución esos docentes de dedicación parcial no generan conocimiento (publicaciones formales) pues no se hacen investigación. Esto hace que sean muy pocas las publicaciones formales en el área de computación con filiación FIUBA.

Por otro lado tampoco me parece conveniente que todos los docentes de una carrera sean de dedicación completa/exclusiva, porque en un área de ingeniería es necesario una dosis de «mundo real» que viene dada por el ejercicio en la industria.

Pero hace un par de meses tuve una charla con un docente investigador del área de computación de otra institución que me comentaba que gran parte de sus docentes son de dedicación completa/exclusiva y que como tales hacen hacen investigación. Y más aún, varios de ellos solo quisieran dedicarse a hacer investigación pero que por reglamentación están obligados también a dar clases. ¡Ooopss! docentes que no quieren hacer docencia.

Este me hace pensar que en la situación de FIUBA no es tan mala, al menos en términos de docencia pues como mencioné, gran parte de los docentes ejercen la docencia por «vocación»* . Sin embargo, creo que es necesario lograr una balance a nivel institucional para poder tener docentes que hagan investigación (lo cual requiere cargos de mayor dedicación) y docentes «de industria» (practitioners, como se les suele llamar a la gente de industria en los en ámbitos académicos).

* sin duda que hay más motivaciones que la pura vocación, algunos harán docencia para sumar antecedentes, otros para continuar aprendiendo, pero mi punto es que en general esos docentes no lo hacen «por necesidad» ni obligación.

Libro: Luis Scola, El abanderado

Estuve a punto de titular esta entrada como un offtopic, pero fue un pensamiento muy fugaz porque el hecho de que Scola sea un basketbolista es solo un detalle, Scola es mucho más.

Hecho el disclaimer, vamos al tema en cuestión. Hace un par de semanas terminé de leer este libro que curiosamente me regaló mi hermano. Digo curiosamente porque mi hermano no es regalarme libros, pero ¡que buen regaló metió!. En algún momento comenté en este espacio sobre mi afición al basket y quienes me siguen en Twitter seguramente han visto pasar algún like a alguna publicación basketbolística. Me sincero, estoy usando el hecho de haber terminado este libro para hablar sobre Luis Scola.

Creo que no me equivoco si digo que Luis Scola es un referente para todo aficionado al basket en Argentina, pero es posible que la audiencia de este espacio apenas haya escuchado alguna vez de Scola. De todas formas creo que hay algunas frases y ejemplos de Scola que son «para la vida».

Luis Scola es el jugador más importante del basket argentino y no tengo la más mínima duda de esto. Alguno dirá que no, que es Ginóbili, pero no. Ginóbili posiblemente sea al día de hoy el mejor jugador pero no el más importante. De hecho creo que el mismo Manu Ginóbili reconoció el lugar de Luis.

En fin, este libro cuenta la vida de Luis Scola, en cierto modo es una biografía y si bien tiene testimonios de mucha gente allegada a Scola, no es una autobiografía. O sea, Scola no participó de la escritura del libro. El libro es obra del periodista Mauricio Codocea. Está bien escrito y su lectura es llevadera. Está plagado de testimonios algunos obtenidos exclusivamente para el libro y otros tantos recolectados de entrevistas previamente publicadas. Obviamente hay muchas cosas que yo ya conocía de Scola, pero hay muchas otras que no, simplemente porque Luifa (como se lo suele apodar) es de perfil muy bajo. Hay varios gestos que Luis ha tenido a lo largo de su carrera que me hacen pensar que lo vamos a extrañar mucho más allá de su rol de jugador y capitán de la selección Argentina.

Les dejo aquí tres videos de entrevistas de Luis que lo pintan de cuerpo entero.

La primera es una entrevista que le hace Juampi Sorín como parte del ciclo Capitanes en 2017.

La segunda es la que le hace el periodista Luis Novaresio en agosto de 2019.

Y la tercera, la más reciente, la que le hace Julio Leiva en el ciclo Caja Negra.

Y cierro con una frase que si bien no es de Luis, se la escuché decir a él en una de estas entrevistas:

El trabajo mata al talento cuando el talento no trabaja.

Evento «avanzado» de desarrollo ¿interesados?

La gran mayoría de las conferencias abiertas de las que tengo conocimiento suelen apuntar a una audiencia masiva y variada y aún cuando hay algunas sesiones avanzadas, es muy limitada la posibilidad de ir en profundidad. Típicamente hay un orador en una sesión tipo clase magistral y hacia el final de la sesión hay un espacio de preguntas y respuestas. En algunos casos hay sesiones tipo «taller» en las que se puede ir más en profundidad pero tampoco demasiado. Estos eventos están muy bien y son muy necesarios, pero los que tenemos ya varios años de experiencia en ocaciones nos gustaría tener opciones de eventos distintos, más profundos, menos masivos y con contenido más curado.

El año pasado tuve la oportunidad de participar del WOPR y a partir de esa experiencia estoy pensando en organizar un evento con una dinámica similar pero enfocado en desarrollo de software y concretamente para desarrolladores: no gerentes, no gente que programó hace años, no consultores, no arquitectos, sino que gente que está metiendo commits en su día a día. La idea seria algo así:

  1. Dos días en modalidad «inmersiva», o sea, el evento sería en alguna locación retirada de cara a pasar los 2 días «internados» ahí (onda el Agile Open Camp). Se me ocurre que podría ser en algún alojamiento rural o bien en algún apart en alguna locación turística en temporada baja. Onda que llegamos un miércoles por la noche, hacemos check-in y jueves temprano largamos. Jueves y viernes a full. Hacemos el cierre el viernes por la tarde noche y quien guste se puede quedar a pasar el fin de semana por su cuenta.
  2. Participación por invitación con cupos limitados, 20 participantes máximo.
  3. Cada participante tiene que postularse enviando un resumen del contenido que va a presentar.
  4. La organización selecciona los participantes y envía las invitaciones.
  5. Cada participante debe pagar pagar su participación esto es: alojamiento, traslado, comidas, etc. Para simplificar la gestión seguramente la organización armaría un paquete incluyendo todo.
  6. No hay agenda predefinida sino participantes. O sea, no sabes de entrada exactamente de qué se va a hablar pero sabes que estarás compartiendo 2 días con determinadas personas.
  7. Los temas que se tratarán durante el encuentro serán en parte definidos por la organización y en parte por los propios participantes.
  8. Todo participante tiene que estar preparado para presentar un contenido pero no es seguro que lo presente, dependerá del fluir del evento.

Me gustaría mucho participar de una evento así y por ello estoy dispuesto a organizarlo, la pregunta es: ¿habrá otros interesados? Si lees este post y te interesado participar, contactame.

Sobre los resultados inconclusos de los estudios sobre TDD

Practico TDD, enseño TDD e investigo sobre TDD. Hoy 2023 TDD es bastante conocido pero bastante menos practicado. Yo tengo mis propias sospechas pero recientemente me he encontrado con dos posibles explicaciones adicionales. En este sentido quiero referirme aquí al trabajo de Ghafari y colegas.

Comienzo explicando el contexto: si buscamos estudios sobre los beneficios de TDD vamos a encontrar evidencia no concluyente, o sea: encontraremos algunos estudios que a partir de experimentos aseveran ciertos beneficios de TDD al mismo tiempo que otros estudios hablan de limitaciones o incluso que la técnica no goza de ciertos beneficios. Ejemplo: algunos estudios indican que TDD mejora la calidad del código pero al mismo tiempo empeora la productividad. Otros estudios dicen que TDD no tiene impacto en la calidad e incluso algún otro habla de que tampoco impacta en la productividad.

A partir de esto, Ghafari y compañía, en su trabajo «Why Research on Test-Driven Development is Inconclusive?«, se propusieron estudiar la razón de estos resultados inconclusos. Para esto analizaron diversos estudios existentes sobre TDD y básicamente identificaron 5 factores:

  1. Definición de TDD: según indican, en los distintos estudios que analizaron se utilizan diferentes definiciones de TDD. Esto en lo personal me resultó muy raro, al menos en el sentido que los autores lo indican. Al margen de lo que indican los autores, lo que personalmente me resuena es que en mi propio trabajo de investigación he notado diferentes concepciones de TDD. Hay gente que entiende por TDD puntualmente lo descripto por Beck en su libro Test-Driven Development by Example, lo cual se centra en aplicar TDD a nivel «diseño de clases», muy asociado a prueba «chica» (onda unitaria), mientras que otros toman TDD como una idea más amplia, aplicable a distintos niveles de abstracción como son BDD/ATDD/SBE y más en línea con lo que el propio Beck menciona en su entrevista a Software Engineering Radio.
  2. Selección de los participantes: muchos de los estudios se hacen con estudiantes o con gente de industria que ha recibido una breve capacitación en TDD. Ambas situaciones son al menos discutibles para poder sacar métricas concluyentes. Si queremos llegar al fondo del asunto debemos realizar estudios con gente experimentada en el uso de TDD.
  3. Selección de la tarea: en general los experimentos utilizan ejercicios/tareas que distan mucho en complejidad de lo que uno se encuentra en «escenarios reales»
  4. Tipo de proyecto: la mayoría de los estudios se enfoca en «proyectos nuevos» (green field) cuando en los contextos reales es habitual tener que lidiar con proyectos existentes (brown field)
  5. Comparación: TDD es una práctica de uso en contextos ágiles, con lo cual al hacer estudios comparativos debería comparar el uso de TDD vs. (No-TDD en un contexto ágil), cosa que no siempre es así. Hay estudios en los que se compara el «uso de TDD» vs. «No-TDD en contextos waterfall», los resultados de este tipo de comparación puede deberse tanto al No uso TDD como también al uso de Waterfall. Es fundamental al comparar tener presente el contexto. También resulta relevante considerar distintos escenarios de No-TDD: Test-Last, Iterative Test-Last, No-Test-at-All pues la implicancias de la comparación pueden resultar muy distintas.

En términos generales me parecen bastante razonables estos 5 factores y obviamente los tendré presentes en mi propios trabajos. Para quienes quieran profundizar en esta cuestión les recomiendo leer el artículo completo, es bastante corto y de lectura llevadera.

off-topic: Argentina Campeón 2022

Hoy salgo de la temática habitual de este espacio para referirme a un hecho sin precedentes: el mundial de fútbol 2022. Al escribir estas líneas dudo si el hecho es el «mundial de fútbol» o «que Argentina fue campeón». En lo personal creo que es el mundial porque la locura, ilusión, «nivel de manija» que despertó el mundial en el pueblo argentino creo que va más allá de haber ganado la final o no. Obviamente cuando Argentina ganó la final la cuestión explotó, pero incluso antes de eso, lo que se vivió en Argentina no tuvo precedente para mí.

Yo no soy futbolero. Obviamente como todo argentino he practicado fútbol y me he puesto la casaca de algún equipo. Siempre en la posición de arquero, pero ya a los 10 años quedó claro que lo que mio no era el futbol sino el basket. También he ido a la cancha y he vivido un partido en la bombonera, pero siendo sincero casi todas las veces que he estado en un estadio de futbol ha sido para ver una banda de rock y no un partido de futbol. Así y todo, siempre miro los partidos de la selección.

En el 78, cuando Argentina ganó su primer campeonato mundial, yo aún no había nacido. En el 86, cuando Diego levantó la segunda copa para Argentina, yo aún era muy chico. Ya para el 90 tenia suficiente conciencia para sufrir colgado del travesaño en aquel partido de octavos de final contra Brasil. Luego los penales atajados por Goyco, el triunfo contra Italia y el sabor amargo de la primera final perdida contra Alemania.

Después vinieron algunas copas América y la ilusión del 94 con el Diego, el Bati, el Burrito y tantos más. Y otra tristeza infinita cuando «nos cortaron las piernas» y ese dolor de saber que ya no tendríamos al Diego en la selección.

Hubo otras ilusiones de la mano de otros cracks como Aimar, Crespo, Higuaín, Tevez, Riquelme y el propio Messi. Se ganaron campeonatos juveniles e incluso juegos olímpicos. Pero no fue hasta 2014 que la selección mayor pudo llegar a otra final y sin embargo la emoción no fue ni remotamente comparable a este 2022. En aquel 2014 Alemania resultó nuestro verdugo igual que en 90. Luego tuvimos dos finales de copa América (2015 y 2016) que también resultaron derrota.

El punto de inflexión que marcó el inicio del ciclo actual fue la eliminación temprana (digo temprana porque había expectativas de llegar más lejos) en octavos de final de Rusia 2018. Esa eliminación determinó la salida del técnico Sampaoli y la toma de la dirección por Scaloni. Se dice que el nombramiento de Scaloni fue inicialmente provisorio hasta encontrar un técnico definitivo, pero la selección Argentina era una papa caliente que nadie quería agarrar. Fue así que Scaloni, que había jugado en la selección pero que nunca había ejercido como «head coach» quedó confirmado en el cargo. De esta forma surgió «La Scaloneta».

El primer logro fue la Copa América 2021 el cual vino con varios condimentos: fue el primer título de Messi con la selección mayor, fue en Brasil y fue con victoria en la final contra Brasil en el Maracaná.

Luego la Scaloneta ganó «La Finalissima», una copa que enfrentó Argentina como campeón de América con Italia, el campeón de Europa.

Con dos títulos en bolsillo y un invicto de 36 partidos la Scaloneta llegó a Qatar. El torneo comenzó con un tropezón, derrota ante Arabia Saudita pero el tropezón no borró la ilusión (y de hecho yo creo que vino bien). Partido a partido el equipo fue mejorando en su desempeño y la emoción del pueblo fue en aumento. Cada partido implicaba una parálisis del país. Para cuando el equipo llegó a la semifinal la locura era total, el equipo estaba jugando muy bien y muchos ya estaban endeudados: algunos nivel económico para costearse el viaje a Qatar pero muchos más a nivel promesas. La semifinal contra Croacia fue un martes, y para muchos argentinos los días siguientes hasta la final del domingo fueron como vivir en el limbo. No se podía hablar de otra cosa. La selección estaba en todos lados, mirábamos los partidos anteriores una y otra vez. Los supersticiosos buscaban coincidencias por doquier y en los medios y redes sociales todo era Messi, Argentina y la Scaloneta.

Llegó el gran día, con mucha expectativa y mucho nervio. Al final del primer tiempo el equipo estaba ganando muy bien, con 2 goles de ventaja y con un juego muy sólido. El planteo de Argentina había dejado a Francia y sus figuras como una pálida sombra. Es por esto que el empaté de Francia y todo lo que vino después resultó un sufrimiento extremo. Pero finalmente ganamos la tercera, estallaron los festejos y terminó el año. Si, aún faltaban varios días, pero ya todo lo demás había perdido sentido, claro que los problemas del país seguían ahí y cada uno aún tenía obligaciones pero todo pasó a segundo plano. Los festejos el día de la victoria y los días subsiguientes cuando el equipo llegó a Argentina fueron algo nunca visto en el país. Comparto algunas fotos que dan testimonio de ello.

En fin, hora de disfrutar, festejar y cumplir las promesas: ¡somos campeones otra vez!