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.