TDDeando la arquitectura

El viernes pasado estuve dando una charla titulada así en el contexto del meetup online de ArqConf.

Había más de 370 registrados pero como suele ocurrir con los meetups gratuitos, rara vez se llega al 50 %. Cuando comencé a hablar había alrededor de 120 personas y me consta que luego se fueron sumando más pero no tengo presente cuántos.

Dado que la charla trataría sobre TDD, comencé haciendo una breve encuesta a los presentes sobre su conocimiento de TDD. Si bien más del 90 % conocía TDD, tan solo el ~17 % dijo utilizarlo a diario. Personalmente no me sorprende, porque según estudios formales que hemos realizado en los últimos años, el uso consistente de TDD ronda el 20%.

La presentación fue grabada y está disponible en YouTube y los slides están disponibles aquí.

Estos son algunos de los libros en los que me basé para armar la charla:

  • Growing object-oriented software guided by tests, de Freeman
  • Designing Software Architectures: A Practical Approach, de Cervantes y Kazman
  • Just Enough Software Architecture: A Risk-driven Approach, de Fairbanks
  • Building Evolutionary Architectures: Support Constant Change, de Ford
  • Specification by example, de Adzic

Agradezco a Gus Brey y demás organizadores por la invitación.

#HistoriaDeTrinchera: equipo completo

Al cabo de 6 iteraciones hemos completado el equipo. Resulta que al comenzar la sexta iteración se sumó el miembro faltante. Tenemos ahora cubiertos todos los roles/habilidades que consideramos necesarios para llevar adelante el proyecto y al mismo tiempo hemos alcanzado, a mi criterio (no estoy seguro que mis colegas compartan) el número máximo de personas que el equipo puede tener.

Nuestra expectativa es poder tener dentro del equipo todas las habilidades (y autorizaciones) para operar en un esquema de entrega continua dentro de ciertas restricciones organizacionales que por el momento no parecen estar abiertas a negociación (tema de otro post). En este sentido tenemos los siguientes roles/habilidades:

  • Developer
  • Tester
  • Diseñador de UI/UX
  • Facilitador
  • Product Owner
  • Infraestructura

Estos roles/habilidades son ocupados por personas que están en el día a día del proyecto y que como tal participan diariamente de las reuniones de sincronización (daily standups). Algunas aclaraciones que pueden resultar relevantes para el lector:

  • Developers: apuntamos a que puedan desarrollar una funcionalidad de punta a punta, lo cual implica tanto hacer tanto front (angular) como back (netCore) y tocar algunas cuestiones de infra como pipeline de CI/CD y generación de los correspondientes contenedores.
  • Testers: en el sentido de Agile, trabajan muy de la mano de la gente de negocio y con una visión funcional. Colaboran en la identificación/definición de casos y también en su automatización.
  • Diseñadores de UI/UX: diseñan/validan la experiencia del usuario y definen las pantallas. Trabajan muy de cerca con la gente del negocio y los usuarios. No codean, su trabajo llega hasta el maquetado con alguna herramienta tipo Miro, Marvel y Zeplin.
  • Facilitadores: llamados a veces Scrum Masters o coaches, ayudan a que el equipo mantenga el foco en el proceso y la entrega de valor, destraban impedimentos y mantienen los diálogos abiertos con otros equipos/áreas.
  • Product Owners: es gente con perfil de negocio que define el norte del producto, concentra los pedidos de los usuarios y los prioriza.
  • Infraestructura: más allá del control que tenga el equipo sobre la infraestructura es fundamental que el equipo entienda (y pueda definir y discutir) ciertas cuestiones de infraestructura porque pueden impactar en la implementación de algunas características/funcionalidades de la aplicación. En este caso particular, la organización tiene un área de DevOps con la cual nosotros como equipo de desarrollo trabajamos muy cerca en un ida y vuelta constante. Luego ese equipo de DevOps se encarga de la interacción con el resto de los sectores de infraestructura como seguridad, networking, etc.
    (este es un punto que puede resultar polémico y por ello le dedicaré un post aparte)

Todo este conjunto de roles/habilidades está repartido entre 12 personas, varias de ellas con asignación parcial (yo entre ellas). Para mi gusto ya son demasiadas personas y como algunos colegas coinciden con esto, es muy posible que en el corto/mediano plazo sumemos más gente y partamos el equipo en 2.

Próximas charlas sobre TDD

En las próxima semanas voy a estar participando de eventos virtuales con dos nuevas charlas sobre TDD que vengo trabajando desde hace un tiempo. Aún no tengo confirmadas la fechas (en cuanto las tenga las compartiré en redes) pero igualmente comparto la temática de las mismas.

TDD al banquillo

Test-Driven Development (TDD) es una práctica creada por Kent Beck a finales de los 90. En 20 años ha cosechado varios practicantes, algunos “fanáticos” y algunos detractores. Definitivamente es una práctica muy conocida pero…¿cuan utilizada es? ¿cuanta gente usa TDD?.

Al mismo tiempo los practicantes de TDD hablan de un conjunto de beneficios que ellos mismo han obtenido, pero en términos formales/científicos ¿cuales son la mejoras que nos trae el uso de TDD?

TDD claramente impacta en la forma en que trabajamos, pero ¿tiene algún impacto en el resultado de nuestro trabajo? ¿el software resultante es “mayor calidad”?

TDD surgió en el contexto de Extreme Programming junto con otras prácticas como Integración Continua, Pair-Programming y Collective Ownership ¿es posible utilizar TDD en forma “aislada” sin incorporar estas otras prácticas? ¿Es igual de efectivo?¿Cuales serían los riesgos?

En la charla planeo recorrer todos estos interrogantes e intentaré darles respuestas desde la formalidad de varios estudios, libros y obviamente también con un condimento de experiencia personal. No es una charla introductoria a TDD en el sentido que no voy a detenerme a explicar en detalle cómo es la dinámica de TDD, creo que ya hay bastante de eso. La charla está dirigida a gente que ya conoce la propuesta de TDD independientemente de que la este usando o no.

TDDeando la arquitectura

Los cimientos de TDD se establecieron a finales de los años 90 en el contexto de Extreme Programming pero podríamos decir que, recién en 2002, Kent Beck formalizo la técnica en su libro Test-Driven Development by Example. En ese libro Kent explica la técnica y muestra ejemplos trabajando a nivel de prueba unitaria, haciendo TDD sobre clases. Sin embargo el mindset de TDD puede aplicarse a otros niveles de abstracción como el mismo Beck lo ha admitido. En esta charla veremos cómo utilizar TDD para guiar la construcción de una arquitectura en forma emergente. Esta charla no es charla introductoria a TDD, voy explicar muy brevemente la dinámica propuesta por TDD pero no será ese el foco. La charla está dirigida a gente que ya conoce la propuesta de TDD independientemente de que la este usando o no.

Sobre por qué la programación orientada a objetos perdió relevancia

Erase una vez cuando se desarrollaban aplicaciones grandes, con decenas o incluso cientos de entidades. Era una época donde se esperaba que cada pieza de software viviera por muchos años y los ciclos de release podían extenderse por muchos meses excediendo incluso el año. Era una época donde la programación orientada a objetos y sobre todo un buen modelo de objetos podía marcar una diferencia relevante en la construcción, evolución y mantenimiento de una pieza de software[1].

Pero esa época ha quedado atrás, cada vez son más las demandas del negocio por dar respuestas rápidas a las situaciones cambiantes del mercado. Los ciclos de release se han acortado radicalmente y de mano de ello también alcance de cada aplicación. Los avances en virtualización y la popularización de los contenedores han habilitado el surgimiento de prácticas como infraestructura como código y continuous delivery. En este contexto, propuestas de diseño como la de microservicios han probado ser muy efectivas. Cada microservicio es una aplicación de un tamaño acotado, no hay un regla fija de esto pero se suele usar como referencia un bounded context [2]. En este hilo de razonamiento cada aplicación no tiene ya tantas entidades y tampoco se espera que un microservicio “viva por siempre”. Dado que los microservicios son relativamente pequeños no resulta impensado que luego de un tiempo sea reemplazado por una nueva versión que podría estar incluso desarrollada con una tecnología distinta.

Esto me lleva a pensar que en cierto modo la importancia de la programación orientada a objetos ha perdido cierta importancia relativa. En un punto cuestiones como la arquitectura de runtime (que impactan en la posibilidad de escalar) han tomado mayor relevancia (posiblemente porque la necesidad de escalar está mucho más presente ahora que hace 15 años).

Sin embargo estoy convencido que los principios de la orientación siguen completamente vigentes porque muchos de ellos son aplicables más allá de la programación. De hecho, los principios de diseño de los microservicios no son más que “refraseos” de los principios de orientación objetos. Un caso es el principio de Responsabilidad Única (Single Responsibility Principle): un objeto debe hacer UNA cosa y hacerla bien, eso mismo aplica a los microservicios. De hecho creo que perfectamente uno podría tomar los principios de orientación a objetos, aplicarlos al diseño de microservicios y luego programar internamente el microservicio utitilizando objetos pero de una forma más “procedural” utilizando alguna estrategia del Transaction Script. en lugar de hacer un Domain Model.

Tal vez este razonamiento genere alguna crítica y ante ello debo aclarar que he estado enseñando Programación Orientada a Objetos por más de 15 años y aún lo hago. Pero desde hace un tiempo vengo con la sensación de que en la medida en que podamos hacer aplicaciones/servicios pequeños, con pruebas automatizadas y prácticas de configuración management, la forma interna en que programemos las aplicación, resulta menos relevante.

[1] Posiblemente en algunos contextos esto siga ocurriendo
[2] Bounded Context es una idea desarrollada por Eric Evans en su libro Domain-Driven Design

Consideraciones para elegir un trabajo final de carrera

En las carreras de informática en Fiuba no hay, a mi entender, una definición lo suficientemente clara sobre los trabajos finales de carrera. Hay documentación, pero no hay una materia (como ocurre en otras universidades) donde los alumnos sean asesorados o tengan algún tipo de seguimiento. El alumno debe encontrar un director para su trabajo y acordar con él un tema.

En este contexto suelo recibir varias consultas de los alumnos y uno de los primeros consejos que les doy es que dejen en claro el objetivo personal que persiguen con el trabajo. Con esto no me refiero a la temática del trabajo sino a su expectativa personal, doy tres posibles ejemplos:

  • Recibirse y listo: la realización del trabajo final es requisito para recibirse y puede que el alumno quiera puntualmente eso. No tiene ninguna expectativa adicional. En este sentido el trabajo final es, en términos de transcendencia, como cualquier otro trabajo práctico de la carrera: una vez evaluado, ha cumplido su objetivo: la aprobación; entonces se archiva y nunca nadie lo vuelve a tocar.
  • Iniciar un emprendimiento: dado que el trabajo final requiere típicamente al menos un cuatrimestre de trabajo, puede ser una oportunidad interesante para aprovechar y hacer que ese trabajo final sea el puntapié inicial de un potencial emprendimiento.
  • Hacer un aporte a la comunidad: otra opción interesante para aquellos con intención de que su trabajo final tenga transcendencia más allá de la aprobación de la carrera es hacer algún tipo de aporte ya sea desarrollando una aplicación para una alguna institución, colaborando con un proyecto open source existente o incluso generando un nuevo desarrollo open source.

Esta es una clasificación muy genérica que no cubre todos los casos. De hecho mi propio trabajo final no entra en ninguna de estas categorías. De todas formas creo que plantearse la pregunta de las expectativas personales puede ser muy útil para definir el tema y sobre todo para armar el plan de trabajo.

Comienzo del cuatrimestre online en MeMo2@fiuba

El lunes pasado comenzamos las clases de MeMo2 con un hecho muy particular: asistencia perfecta. ¡ja! seguro que más de uno pensó en la clase remota como hecho particular (lo cual es correcto), pero también resulta que a la primera clase asistieron todos los inscriptos. Aunque suene raro, todos los cuatrimestre nos veníamos encontrando gente que faltaba la primera clase.

En fin, comenzamos oficialmente las clases, en modalidad 100% online. Utilizamos la herramienta Jitsi Meet que funcionó a la perfección. De cara a poder dar más interactividad a clases estamos experimentando con algunas nuevas herramientas, esta semana probamos con Kahoot y Mentimiter, ambas nos dieron muy buenos resultados.

Como de costumbre les pedimos a los alumnos completar una breve encuesta sobre su perfil. Comparto algunos datos:

  • El 72,7 % de los alumnos están inscriptos en la carrera de Ingeniería Informática, mientras que el 22,7 % está en la carrera de Licenciatura en Sistemas. El resto tiene simultaneidad entre ambas carreras.
  • El 81,8 % de los alumnos trabaja en una actividad afín a la carrera mientras que el 13,6 % no trabaja. El resto trabaja en alguna actividad no afín a la carrera.
  • El 68,2 % tiene la expectativa a largo de desempeñase en el rol de arquitecto/desarrollador, mientras que el 18,2 % aspira a líder de proyecto. Finalmente el 13,3% apunta a un rol de SysAdmin / DevOps / SRE.

Pero por lejos lo más sorprendente de este relevamiento es la gran dispersión que hay en la cantidad de materias aprobadas: en un extremo hay alumnos con menos de 20 materias aprobadas (uno con 15) y en el otro tenemos alumnos con más de 35 (uno con 42). Yo estimo que aquí la diferencia la hacen las materias de ingeniería (principalmente matemáticas, físicas y electrónica)

Seminario en Software Delivery

Bueno, finalmente y a pesar de la pandemia ya tenemos fecha para el seminario de Postgrado en Software Delivery de UNTreF.

La temática de este seminario está centrada en el proceso de desarrollo y entrega de software, cubriendo diversas prácticas tanto a nivel técnico como de gestión. El contenido está estructurado sobre la base de un conjunto de estudios formales y casos de estudio en torno a organizaciones de alta performance.  En especial se destacan las ideas desplegadas por Forsgren, Humble y Kim en su libro Accelerate, The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations (IT Revolution, 2018). Los objetivos del seminario son:

  • Entender el impacto de las capacidades de Software Delivery en la performance del negocio
  • Entender las prácticas técnicas y de gestión que mejoran la performance de delivery
  • Conocer posibles estrategias para la adopción de las mencionadas prácticas

El curso está estructurado en cinco encuentros online. Está destinado a graduados universitarios de títulos vinculados con la informática o profesionales que acrediten experiencia de al menos 5 años de trabajo en la disciplina.
En el primer encuentro se presentará la dinámica del seminario y se compartirán los materiales de estudio sobre los que se trabajará en los siguientes encuentros. Los siguientes encuentros estarán dedicados a presentación de casos, actividades de debate e intercambio. Para completar el seminario los participantes deberán realizar un trabajo de final que deberán presentar en el último encuentro del seminario.
Los encuentros online se realizarán con la herramienta Google Meet y adicionalmente se utilizará un campus virtual para compartir los materiales y atender consultas fuera del espacio de clase.

El calendario de encuentros es:

  • 20 de Mayo
  • 17 de Junio
  • 24 de Junio
  • 22 de Julio
  • 29 de Julio

Todos los encuentros serán de 2 horas.  La dedicación estimada es de entre 3 y 4 horas semanales durante toda la duración del seminario.

Este seminario está dirigido a:

  • Profesionales informáticos involucrados en procesos de Software Delivery independientemente del rol que tengan en ese proceso
  • Profesores y/o Investigadores en el área de ingeniería de software

En ambos casos es imprescindible contar con un título de grado en el área de informático y tener al menos 5 años de experiencia profesional comprobable en la industria del software.

Los interesados en pueden completar el formulario inscripción en la página de la universidad.

Iniciativa Online: #HablemosDeSoftware

A partir de la actividad “Consultorio DevOps” que hice el martes pasado se me ocurrió armar un espacio recurrente de encuentro y debate: #HablemosDeSoftware.

La idea es conectarnos mientras dure este tiempo de aislamiento para tratar distintas temáticas y compartir experiencias. La participación es abierta y la idea es que cada encuentro este centrado en una temática particular. Algunos de los temas que tengo en mente son:

  • ¿Resulta conveniente hacer TDD?
  • Solo-Programming vs Pair-Programming vs Mob-Programming
  • Sobre cómo Trunk-based development cambiará tu vida
  • Prácticas modernas de desarrollo en aplicaciones legacy
  • Alternativas para implementar CI/CD
  • ¿De verdad hay que automatizar las pruebas?

A esto se suman los temas que los participantes quiera traer.

La propuesta para la semana próxima (martes 7/4, 19.00 hs ARG) es hablar sobre Roles y Estructura de equipo.

El con el siguiente link puedes agregar el evento a tu calendario:

El mejor libro de arquitectura

La semana pasada terminé de leer el libro “Building Evolutionary Architectures” y me resultó posiblemente el mejor libro de arquitectura que lei en mi vida (y eso que he leído varios libros sobre el tema).

Compré el libro porque me atrapó el título y ya había leído otras cosas de los autores. El libro no delira con definiciones abstractas, es muy concreto y el planteo de “evolvability” como propiedad de la arquitectura me resultó muy novedoso y super apropiado en la actualidad. Si bien por momentos me hizo un poco de ruido el tono “grandilocuente” con el que se refiere a los arquitectos corporativos, finalmente me terminó convenciendo el lugar y las responsabilidades que les asigna (que lejos está de lo que suelo ver cotidianamente en la industria).

Algunos otros puntos que me parece vale la pena destacar son:

  • La idea de usar fitness functions para verificar el cumplimiento de ciertas propiedades de la arquitectura
  • ¡Habla de testing! Lo cual no es común en los libros de arquitectura
  • Trata diversas cuestiones de negocio/organización que no siempre están presenten en los libros de arquitectura. Entre estas cosas habla de la estructura de equipo.
  • Toma muy en cuenta la arquitectura física y el potencial acoplamiento que esta puede generar.
  • Cubre cuestiones tanto de green field projects como de brown field projects

Si tienen la oportunidad, bien merece dedicarle un tiempo.