Pamplona Software Crafters 2022 y el coste basal del código

Después de dos años sin Pamplona Software Crafters, tocaba un evento por todo lo alto. Las ganas eran enormes, sobre todo para ir volviendo a esa normalidad de acudir a ferias y eventos, que es sin duda una costumbre saludable. Cada evento para con su fin, dicho sea de paso.

Acudí junto con @jbraz95, @Sr_Aburrido, @raquelbars y @jruiza por parte de @veridas, pero no me puedo olvidar a los organizadores del evento y a la gente de @540deg, entre los cuales no puedo dejar de mencionar a @javi_gut95, que cumplía años el fin de semana de la conferencia. Todos ellos han contribuido a la creación de un evento que siempre estuvo por encima de las expectativas.

Soy consciente de que me voy a dejar un sinfín de anécdotas por contar, pero partiendo de las notas que fui tomando a ratos, en este artículo voy a hacer memoria y a hacer hincapié en los momentos que más me llegaron.

El jueves, antes de incluso comenzar la conferencia, conversando con los compañeros de @AudienseCo salió el tema de la adopción del pair programming en los equipos de desarrollo. A mi me encanta ver esas iniciativas a nivel colectivo. Las ventajas más notorias, entre otras, son el training continuo y la eliminación de silos o mejor intercambio de conocimientos. La verdad que en equipos donde la brecha entre seniors y juniors es manifiesta, lo veo una práctica muy atractiva y sencilla para la mentorización.

En la primera presentación y una de las que más me gustó a mi, fue la de @fdiazgarrido sobre XP en entornos altamente operativos. Los mensajes transmitidos fueron similares a los que ya se escuchan en otras charlas de esta índole, pero matizando de forma sutil y con un trasfondo que de verdad me gustó, en cómo el entorno y ciertas prácticas tienen un impacto en la calidad de vida del desarrollador. Al margen del triángulo de la gestión de proyectos, me gustó la mención al coste basal del código. Para los que, como yo, lo primero que nos viene a la cabeza, le hemos dedicado unas horas al fitness y a la nutrición, es fácil entenderlo de forma análoga a la tasa metabólica basal que tiene el cuerpo. Para que os hagáis una idea, el cuerpo necesita X calorías simplemente para sobrevivir, es decir para realizar las funciones básicas como respirar, latir el corazón, etc. En el código, por la simple existencia del mismo, también existe un coste inicial o de base. El desarrollo final que necesita el cliente se va construyendo a partir de la misma.

Esto se produce por múltiples razones, entre otras:

• Por la necesidad de mantener el conocimiento de ese código (si el maintainer de ese código se va a otro proyecto o deja la empresa) es necesario que eso se traslade. Esto aplica también para nuevos miembros de los equipos.
• Nuevas prácticas de desarrollo, dependencias, agujeros de seguridad, coherencia con el resto de códigos del portfolio de productos.

Esto además puede incrementarse de forma exponencial, si hay un lenguaje o librería que es deprecada, entre otros.

Hablando de producto, @jrubr comentó el artículo de Ryan Singer, Options not Roadmaps que me parece super interesante. Al final, como se comenta en el artículo, cuando se tiene un commitment con algo que per se tiene incertidumbre, se generan unas expectativas al respecto, que en caso de no cumplirse acaban afectando al desarrollador (por no cumplir). Si bien es cierto, esto dependerá siempre de cómo se interactúa y el tipo de cliente, etc. En el mundo real, este siempre desea un roadmap, quiere y tiene expectativas con respecto al producto. Aquí es importante mantener un equilibrio entre esas features que se van a construir siempre, y todas las peticiones que van llegando.

Continuando con alguna conversación de producto, a raíz de la charla orientada a Product Managers, @MartaMans0 me recomendó el libro Escaping the Build Trap (Melisa Perri). Ahora mismo estoy terminando The Manager’s Path, luego me pondré con él. Luego en otra charla salió también el de The 7 Habits of Highly Effective People.

Por otro lado, en el taller de @MaitaneItoiz de example mapping hicimos unos ejemplos de casos reales, en grupos para entender ejemplos. La verdad que me pareció muy aplicable siempre que estén incluidos parte de negocio a la hora de definir las historias de usuario. En el taller realizamos grupos pequeños como si fuesen meetings de los three Amigos, que incluye un analista de negocios, un especialista en calidad y un desarrollador.

Ya en la charla de developer experience de @msanjuan, se habló desde el proceso de onboarding, incluyendo automatizaciones para configurar equipos, a la documentación que tienen los equipos y como unificar esto puede reducir silos en la empresa. En mi caso particular no suelo tener necesidad de esto, ya que tengo unos dotifiles configurados que se instalan en todos mis equipos.

Otra herramienta que me pareció sugerente, aún cuando a raíz de la pandemia y el teletrabajo se haya escrito de forma considerable acerca del tema, fue donut, que permite fomentar la colaboración y comunidad creando conversaciones aleatorias, no con miras a hablar de trabajo sino para hablar de lo divino y lo humano y pudiendo conectar con gente de otras áreas que podrías no conocer si no se habilitan los mecanismos para ello. Me suelen gustar este tipo de ideas verlas en forma de productos, ya que confirman de cierta manera ese nuevo negocio generado a raíz del teletrabajo.

En lo que respecta a la documentación, me llamó muchísimo el combo de gatsby (+plugins) para crear una documentación unificada, evolucionando sobre mkdocs y viendo como se puede quedar justo cuando intentas escalarlo más allá y hacerlo como un portal de documentación transversal y unificada para todas las áreas de la empresa, algo que evita silos y fomenta la transparencia.

Otra conferencia que me gustó personalmente mucho, fue la de antidogmas, por parte de @msanjuan y @flipper83. En esta se dilucidaban los ya conocidos dogmas en torno al software. Estos dogmas, muchas veces promovidos por ciertas personas de gran relevancia en el mundo del software, hacen que X metodología/tecnología/framework sea superior a los demás sin entender el rationale que hay debajo. La charla hablaba de como convertir esto en un framework para el ingeniero, ser capaz como ingeniero de sustentar ambas posturas (i.e. TDD si/no). Para transmitir el mensaje ambos estuvieron debatiendo varios temas conocidos, donde a cada uno de los dos le tocaba defender una postura.

Mientras he escrito esto me han venido a la mente más conversaciones que podría citar, pero creo que ya me he extendido bastante. De hecho, una vez terminada la conferencia, y ya habiendo pasado unos días, me pesa, como en este tipo de eventos, no haber conocido a más gente, interactuado más e incluso haber intervenido en muchas ocasiones que me he mostrado dubitativo. Entiendo que eso forma parte de mi personalidad ^^