De la máquina del developer directo a Producción, sin escalas

Ayer estuve participando de un meetup donde Marcos Nils estuvo contando sobre su implementación de GitOps. Su presentación me pareció muy interesante pero lo que más me llamó la atención fue cuando comentó que en su organización no tienen ambiente de testing, ni staging, ni nada parecido, o sea: cada developer trabaja en su máquina, sube su código a Git y eso dispara una serie de pasos que terminan instalando una nueva versión en el ambiente productivo. No todos los pasos  son necesariamente automáticos, puede que haya algún trigger manual, pero el punto central es que la aplicación no es instalada en ningún otro ambiente más que el productivo.

Apenas escuché esto me resultó muy disruptivo, luego, en el intervalo hablé personalmente con Marcos y me siguió pareciendo disruptivo, ¡ja! Una estrategia de GitOps implica una alto de grado de automatización y el manejo de infraestructura como código, lo cual facilitaría mucho el armado de nuevos ambientes. Sin embargo, lo que me comentaba Marcos es que ellos hicieron un análisis y no encontraron la necesidad de un ambiente de prueba: tienen tests automatizados y algunas cosas las prueban directamente en producción utilizando usuarios particulares de forma de no interferir con los usuarios reales. La respuesta de Marcos me pareció razonable, pues tomaron las decisión con cierto fundamento y contando con toda una serie de medidas (automatización, monitoreo, alertas, etc) que les ayudan a mitigar algunos de los riesgos de no tener un ambiente de prueba.

Personalmente las veces en que me encontré con equipos/organizaciones sin ambiente de prueba, ha sido por la imposibilidad de armar dicho ambiente en lugar de ser consecuencia de una decisión analizada. Al mismo tiempo, en varios de los proyectos que he participado había un contexto de regulaciones que obligaban a contar con un ambiente de prueba/homologación, previo al ambiente productivo.

Pero quien sabe, tal vez algún día tenga la oportunidad de experimentar con una estrategia de este tipo.

El desafió de Enseñar a Diseñar

El desafió de Enseñar a Diseñar

Desde mi comienzo en la carrera docente siempre he estado en materias que en mayor o menor medida han incluido la temática de diseño de software. Cuando estaba en Algo3 y AyDOO era diseño a nivel de clases, ahora en MeMo2 cubrimos un poco de diseño a nivel de clases y también diseño de más alto nivel (arquitectura e infraestructura). Enseñar a diseñar es una tarea que me parece muy difícil. De entrada debemos decir que no hay diseños “malos” o “buenos”, sino que un diseño podrá ser más o menos conveniente dependiente del contexto. Un diseño es consecuencia de un conjunto de decisiones, diseñar es decidir, elegir. Pensando en el proceso de diseño veo al menos 3 pasos:
  1. Entender el contexto, el problema a resolver, las restricciones y necesidades. Esto es lo que Kazman denomina Architectural Drivers.
  2. Entendido el contexto hay que identificar las decisiones relevantes que deben tomarse.
  3. Finalmente para cada decisión relevante hay que analizar las posibles alternativas y elegir una. Esto puede implicar hacer algunas pruebas de concepto para poder tomar decisiones con evidencia que las respalde.
El punto 1 cae dentro del área denominada ingeniería de requerimientos y cuenta con un amplio cuerpo de conocimiento. El punto 2, ya es más complejo y más allá del cuerpo de conocimiento requiere de experiencia, lo cual es bastante difícil de transmitir. El punto 3 también reviste de complejidad pero creo que en general es más fácil que el punto 2. A mi parecer identificar opciones y evaluarlas para decidir es una trabajo en esencia muy ingenieril. A comienzo de año estábamos hablando con mi colega docente Diego Marcet sobre los criterios de corrección de un ejercicio de AyDOO y lo vimos:
Pretender que en un cuatrimestre académico alguien aprenda a diseñar es demasiado ambicioso, o sea, se puede enseñar algún método/heurística pero pretender dominarlo y generar buenos resultados puede ser difícil. Por ello ajustamos nuestro objetivo para centrarnos en dar a los alumnos herramientas para ser capaces de detectar las decisiones importantes y al mismo tiempo que sean capaces de detectar decisiones inapropiadas para un contexto dado.
De cara a este objetivo trabajamos bastante sobre código ajeno, o sea, analizando y extendiendo código existente. Continuará….

Mis notas de la 10Pines Conf 2018

Una casa con 10 pinos hacia el sur hay un lugar….

Así comienza la canción que da nombre a 10 Pines, esa empresa de la que son parte varios amigos y que ayer realizó su primer conferencia. La idea inicial de la conferencia fue de Ale Alfonso y luego hubo un grupo de varios pinos que se entusiasmaron y le dieron forma.

La conferencia fue interna pero con la participación de algunos amigos de la casa (como yo). La fecha elegida no fue casual, fue el día 256, el día del programador.

La jornada comenzó minutos antes de las 10 con la apertura de @lucas_giudice y cerró alrededor de las 18 con la certeza de una edición 2019. A lo largo del día participé de 5 sesiones cada una más interesante que la otra:

  • La de Nico PaPagna en la que compartió varias recomendaciones para hacer TDD
  • La de Fede Zuppa sobre Performance de Equipos
  • La de Nico Derecho sobre React Native
  • La de AgusGS sobre arquitectura Serverless
  • La de DarioG sobre Java-Spec

Adicionalmente a esto, también di una sesión sobre construcción de aplicaciones escalables (aquí están las diapositivas). Más allá de las sesiones en las que participé, creo que el programa ha sido de lo mejor que he visto en el último tiempo en Argentina (y tal vez incluso en la región).

Le agradezco a los pinos por haberme invitado a participar y al mismo tiempo los felicito por la movida.

Primeras Jornadas de Ingeniería de Software del Uruguay

Los días 16 y 17 de Octubre se realizarán en Uruguay las Primeras Jornadas de Ingeniería de Software y tengo el honor de haber sido invitado como orador.

En ese contexto estaré hablando sobre unos de los temas “calientes” de la actualidad: DevOps. Concretamente el título de mi disertación será “DevOps, myths and facts of a new paradigm“. También estaré dando un taller enfocado en Test-Driven Development, Continuous Integration y Pair-Programming.

Las jornadas son de entrada libre y gratuita pero es necesario registrarse. Pueden encontrar más información en la página del evento y siguiendo la cuenta oficial de twitter.

Nuevo proyecto: Arquitectura de Prueba

Una vez más me meto es cuestiones de automatización de pruebas y una vez más en un contexto bancario. Esta vez junto a mis estimados colegas de Grupo Esfera. Ayer hicimos el kickoff del proyecto y a continuación tuve una de las mejores sesiones de trabajo del año junto a mi amigo Diego Fontdevila. Estuvimos unas 2 horas revisando código, hablando de diseño, trade-offs y herramientas 😉

En términos genéricos el objetivo del proyecto es armar una arquitectura de prueba para facilitar/guiar a los equipos de desarrollo de la organización que trabajan en aplicaciones de canales y que deben integrarse con los sistemas core.

El stack de tecnologías con el que voy a estar trabajando incluye: Cucumber, Selenium, Pact, Java y AS400 entre otros.

Agile, leche de almendras y negocios

Hace un tiempo (unos 2 o 3 años), en el contexto de una de las Jornadas Ágiles Latinoamericanas se creo un grupo de Telegram para coordinar actividades y compartir recursos/inquietudes/etc.  En ese grupo hubo en estos días un hilo de discusión muy interesante sobre la evolución de Agile, el uso del término Agile, etc, etc. La discusión me resultó muy interesante y por ello quiero compartir algunas de las reflexiones y argumentos que vi pasar. Aclaro que voy a copiar textualmente varios mensajes incluso cuando no estoy de acuerdo con algunos de ellos.

El tema comenzó de la siguiente forma:

A: En muchas partes he visto “Agilidad Impuesta”, es decir por mandato. ¿Cómo llamarían al caso contrario?

(varias respuestas de distintas personas)

P: … Y si la llamamos “Agilidad” y listo? lo otro es “cómo intentar que equipos que no tienen ganas, usen Agilidad”. Esa Agilidad la Agilidad forzada/impuesta? … mepa que no.

A: El mercado y las mega consultoras ya ensuciaron el término

A partir de aquí la discusión transcurrió sobre el uso del término Agile/Agilidad y los usos del mismo y yo agregué mi opinión:

N: “Agile manifesto for Software Developement”, entonces si queres utilizar agilidad fuera del desarrollo del software => buscate otro nombre“.

Algunos colegas manifestaron su acuerdo con mi visión y agregaron:

U: “Si cambias el texto del manifiesto y le pones otras palabras para tu conveniencia o rama ponle otro nombre y no lo llames Agile, porque eso ya es otra cosa

Esto me resonó con una situación que he visto recientemente en otro ámbito. Resulta que en Argentina, hace un tiempo se empezó a popularizar la “leche de almendras”. La primera vez que escuché el término me llamó mucho la atención pues en mi concepción la leche sale de una teta. De hecho la definición de wikipedia indica que es una secreción nutritiva producida por las celulas secretoras de las glándulas mamarias.  Dicho esto, lo que sale de una almendra no es leche. Este mismo fenómeno se repite con “la hamburguesa de soja” y el “alfajor de arroz”. Para mi todos estos casos son claros ejemplos de publicidad engañosa, se utiliza el nombre de un producto fuerte establecido en el mercado para vender algo distinto.

Volviendo a la conversación de telegram, con el correr de los minutos/horas la charla fue pasando por distintos temas y gradualmente subiendo el énfasis de las opiniones. Se hablo de “agile coaches” y diversas interpretaciones del manifiesto ágil. Un  comentario que me resultó muy razonable y me parece puede ayudar a zanjar algunas de las diferencias del debate:

G: “…Últimamente me suma valor diferenciar “Agile” de “agility”. El primer término lo veo con mucha carga (ni buena, ni mala) de sus orígenes (software development). El segundo lo veo expresado en nuevos conceptos: organizational agility, business agility, enterprise agility.

Otro mensaje que me resonó fuerte fue:

J: “…nos (hablando de los developers) estamos alejando de todo lo que tenga Agile como título y nos acercamos más a grupos como el Socrates..

Un mensaje que me resultó muy en línea con mi realidad fue:

O: “El punto es, que como consecuencia de la expansión, hacer agilidad ya no es una manera de hacer mejor software… cada vez se comparte menos al respecto, entonces es mejor buscar otros espacios

En un momento de la discusión compartí dos artículos escritos por firmantes del manifiesto ágil que a mi parecer están muy relacionados con el tema en cuestión:

Para cerrar este artículo comparto mi parecer:

  • El origen de “agile” es El manifiesto ágil para el desarrollo de software
  • La propuesta tuvo cierto éxito, se hizo mainstream y con ello aparecieron innumerables oportunidades de negocio (empezando por certificaciones, cursos y servicios de consultoría). Con las oportunidades de negocio aparecieron personas/organizaciones más interesadas por el negocio que por el desarrollo ágil de software. Al mismo tiempo el mainstream hizo que algunos tomen “agile” y lo intenten llevar a otros contextos. (nobleza obliga: yo soy parte de este negocio también)
  • Todo bien con utilizar “agile” en N contextos distintos, pero me gustaría que utilizara otro término para evitar confusiones (¿agility?). Todo bien con la leche de almendras, pero no le llamen leche, es engañoso, mete ruido y genera falsas expectativas.
  • Como consecuencia de los negocios, aparecen servicios brindados por organizaciones/individuos que no siempre tienen la preparación suficiente.
  • Como consecuencia de estas organizaciones/individuos no suficientemente preparados y de este uso de “agile” fuera del software, la parte del manifiesto ágil que busca asegurar la excelencia técnica del software queda marginada/olvidada.
  • También como consecuencia del negocio y del “agile no software” empezamos a ver “coaches/facilitadores/consultores” hablando de agile sin mucha idea de desarrollo de software, trabajando con equipos de software y haciendo software de baja calidad.
  • Las reuniones/eventos de agile se ven invadidos por cuestiones no relacionadas al software y eso hace que quienes nos dedicamos a desarrollar software perdamos interés por esas reuniones/eventos.
    (varias de estas ideas  ya las había vertido en mi capítulo del libro Ensayos Ágiles)

Continuará…