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.

Cierre de cuatrimestre en Ing-Soft @ UNTreF

Ayer terminamos Ingeniería de Software en UNTreF, fue la primera edición de la materia con el nuevo plan de estudio. Este cambio de plan de la carrera no trajo muchos cambios a nuestra materia particularmente, pero si hubo importantes cambios en la materias previas y posteriores a la nuestra, lo cual nos llevó a ajustar algunas clases y la profundidad de algunos temas.

Otra novedad de este cuatrimestre fue que contamos con un alumno en el equipo docente (FerGainey), lo cual a mi entender siempre es un aporte de valor pues aporta una visión distinta a la que tenemos los que dejamos de ser alumnos hace mucho tiempo.

Comenzamos la materia con 10 alumnos y la terminamos con 8, todos aprobados. La nota promedio de aprobación fue 9 (con desvío 1).

Comparto algunos números de la encuesta de fin de curso:

  • Evaluación general de la materia: 8,5 / 10
  • Claridad de los docentes 4,5 / 5
  • Conocimientos de los docentes sobre los temas de la materia 4,8 / 5
  • Dinámica de las clases 4,6 / 5
  • Materiales de estudio (textos y videos) 4,8 / 5
  • Dedicación promedio semanal extra-clase: 7,8 horas

Comparativamente este cuatrimestre ha sido el mejor puntuado desde 2016 que fue cuando yo me sumé a la materia.

Entre los ítems destacados que surgieron de la retrospectiva de cierre con los alumnos están:

  • Mejorar la consigna y material de estudio de algunas de las tareas
  • Mejorar el feedback escrito en la corrección de las tareas individuales
  • Mejorar el feedback al final de cada iteración del trabajo grupal
  • Incluir clases sobre nuevos temas (por ejemplo seguridad informática)
  • Hacer actividades técnicas/de programación en clase

Personalmente me voy muy conforme con el resultado del cuatrimestre y con varias ideas para el próximo año. Creo que logramos una muy buena química alumnos-docentes a lo largo del cuatrimestre.

El lado B de la profesión

Hoy en día tengo 3 profesiones: consultor, profesor e investigador. Cada una de estas tres profesiones tiene un lado B que no siempre vemos.

Como consultor trabajo de forma independiente y eso implica que más allá de hacer el trabajo para el cual los clientes me contratan tengo que encargarme de una serie de cuestiones no tan divertidas pero necesarias que podrían resumirse como: ventas y cobros. Muchas veces, cuando uno trabaja en relación de dependencia, no se preocupa por estas cuestiones porque en general hay alguien más que se encarga. Pero trabajando de forma independiente es uno mismo quien debe encargarse de vender. La venta en general implica alguna reunión de relevamiento a partir de la cual uno arma una propuesta de servicio. Si la propuesta es aceptada entonces se procede a la realización de trabajo y posteriormente a la facturación y cobro del mismo.

Como docente a cargo de una materia tengo que dictar clase y evaluar a los alumnos. Esto implica la preparación de clases, materiales de estudio, ejercicios, etc. Pero adicionalmente a todo esto están las cuestiones administrativas de la materia: gestión de actas, verificación de correlatividades, coordinación del equipo docente, resolución de pedidos de equivalencia, etc, etc.

Como investigador uno lee, analiza, lee, experimenta, lee, escribe, asiste a conferencias, lee, etc. Pero también hay una parte administrativa que tiene que ver con la formulación de proyectos, la gestión de presupuesto y la rendición de cuentas.

Escribo de esto porque mis fines de año tienen mucho de estas tareas “lado B” y no son de lo más divertido (por eso hago un poco de procrastinación escribiendo en el blog 🙂 )

Cosecha de libros 2019 (en papel)

De mi reciente viaje a Barcelona me traje algunos libros en formato físico.

Refactoring to Patterns es un clásico que tenia pendiente hace mucho tiempo. Había leído capítulos sueltos y me habían gustado mucho, así que finalmente decidí comprar un ejemplar el papel. En términos estéticos el libro es fantástico: es tapa dura y tiene dos piolines para usar de señaladores.

Building Evolutionary Architectures es un libro relativamente nuevo y lo compré porque el planteo me resultó muy interesante. Cuando trabajamos en la definición de una arquitectura lo hacemos prestando atención a la funcionalidades y a ciertos atributos de calidad. El libro plantea que en los tiempos que corren resulta cada vez más importante poder plantear arquitecturas que puedan evolucionar, o sea: agregar “la capacidad de evolucionar” a los posibles atributos de calidad. Al mismo tiempo esa capacidad de evolucionar debe ser acompañada por cierta guía de cómo hacerlo.

Lecture Notes in Computer Science es un serie de libros de la editorial Springer que agrupa artículos científicos publicados en conferencias. En este caso me trabaje el libro de esta serie correspondiente a la conferencia Profes 2019 que contiene el artículo de usabilidad de procesos que publicamos con DiegoF y el mini artículo de mi Tutorial de Prácticas DevOps.

Practices for developing maintainable infrastructure code

Este es el título de la charla que expuse el martes pasado en el Meetup de Infra as Code en la UTN.BA. Los slides están disponibles aquí. La idea de la charla estuvo motivada por el hecho de que en los últimos año el uso de esta práctica se ha popularizado mucho y en varios casos he visto que no se la ha prestado la suficiente atención a la forma de escribir el código. El código “no cuidado” puede no tener efectos negativos en lo inmediato, pero en el mediano/largo plazo puede representar un dolor de cabeza. Dicho esto, la idea de la charla era llamar la atención sobre la importancia de escribir “código feliz” y junto con ello compartir algunas técnicas y herramientas para poder hacerlo.

Al comienzo de la charla, hice un breve encuesta de un par de preguntas para entender la audiencia, por un lado pregunté el rol de los participantes y por otro pregunté quién escribía el código de infraestructura. Los resultados a estas preguntas se ven en los gráficos a continuación.

Un dato que me parece interesante analizar es que el ~35 % de los participantes indicó no estar usando InfraAsCode aún. Por otro lado el ~17% indicó que dicho código lo escriben los developers, en este grupo me encontraría yo :-).