Tabla de contenidos
Introducción y planteamiento del problema
A principios de este año se publicó el libro Software Architecture Metrics: Case Studies to improve the quality of your architecture fue publicado. Este libro es muy especial para Apiumhub, ya que Christian Ciceri, cofundador y arquitecto jefe, es uno de los coautores.
Christian escribió un capítulo que es particularmente útil en contextos en los que la arquitectura y el entorno todavía tienen muchas oportunidades de mejora. Hace hincapié en la importancia de las compilaciones privadas en el proceso de desarrollo, con el principio subyacente de su razonamiento que es fácilmente comprensible – debes hacer uso de las compilaciones privadas y ejecutar tus pruebas en tu máquina local, en un entorno lo más cercano posible a la producción, para obtener retroalimentación de tu construcción tan pronto como sea posible.
Esto permite que todos los miembros de un equipo de desarrollo envíen código fiable a la cadena de producción, minimizando el número de errores y su impacto en las fases posteriores, es decir, el control de calidad y la producción, como se ve en la siguiente imagen:
Gráfico de Christian Ciceri, de la presentación de Private Builds and Metrics en GSAS’22
La idea conceptual del capítulo de Christian me hizo pensar, y finalmente llegué a la conclusión de que no utilizar estas construcciones privadas era un caso particular de algo que ocurre en muchos equipos de desarrollo.
No utilizar las construcciones privadas puede considerarse un tipo de de deuda de proceso, y de eso trata este artículo.
Al prepararlo, traté de averiguar quién sería el actor que podría tener más impacto en su mejora dentro de una empresa, y por eso este texto se dirige principalmente a los directores técnicos (gerentes, directores de ingeniería, y vicepresidentes de ingeniería).
¿Qué es la deuda de proceso? Deuda técnica y deuda de proceso
La deuda de proceso es el coste implícito de tener que realizar trabajo o acciones adicionales causadas por no tener los elementos adecuados en nuestro proceso de desarrollo, entorno y/o flujos de trabajo.
Puede verse como una analogía (o extensión) de la deuda técnica (un concepto acuñado por Ward Cunningham), que es el coste implícito de rehacer una parte de nuestro software como resultado de elegir un enfoque limitado que podemos codificar más rápido ahora para resolver una necesidad inmediata, en lugar del enfoque que mejor se adaptaría al proyecto a medio/largo plazo.
La deuda técnica es una elección consciente del equipo. La deuda técnica no es código desordenado (el tío Bob habla de esta diferencia); es una decisión informada tomada por el equipo que consiste en implementar una solución técnica subóptima en un momento dado para priorizar algunos otros factores (normalmente minimizar los tiempos de entrega de las características).
El mayor problema de la deuda técnica es que implica un peaje que se paga hasta que se arregla.
Al crear una deuda técnica, elegimos construir una casa sobre unos cimientos que necesitarán mejoras en el futuro; y al hacerlo pagamos un precio, doble.
En primer lugar, pagamos un precio con frecuencia: Cuanto más construyamos sobre unos cimientos que no son óptimos, más esfuerzo tendremos que invertir a diario para asegurarnos de que todo lo que estamos construyendo funciona bien a pesar de no contar con la solución que debería haber estado ahí en primer lugar.
En segundo lugar, pagamos un precio acumulativo: Cuanto más construyamos sobre los cimientos y más tiempo pase sin arreglarlos, más esfuerzo tendremos que invertir para arreglarlos en el futuro. Paradójicamente, es probable que tengamos que refactorizar todos los gastos adicionales que hemos estado haciendo a diario mientras construíamos sobre nuestra deuda técnica.
La deuda de proceso es bastante similar a la deuda técnica. Los equipos deciden no preparar y mantener adecuadamente ciertos elementos de su entorno o proceso para favorecer la entrega de características, y pagan un precio hasta que esta deuda se soluciona, normalmente en términos de tiempo y/o fiabilidad de la entrega de valor.
Deuda de proceso y dinámica diaria del equipo
Según mi experiencia, la deuda de proceso está muy extendida en muchas empresas, y a menudo es mucho más perjudicial que la propia deuda técnica. Esta última suele conocerse y reconocerse, y a menudo se asigna para ser abordada en el futuro, pero la deuda de procesos es algo con lo que un equipo de desarrollo «aprende a vivir» sin darse cuenta la mayoría de las veces del impacto negativo en su ritmo de entrega de valor.
Algunos ejemplos de lo que puede considerarse deuda de proceso podrían ser:
- No disponer de conjuntos de datos similares a los de producción para realizar pruebas adecuadas en el control de calidad
- No usar construcciones privadas para ejecutar la mayoría de las pirámides de prueba en local
- No disponer de registros, herramientas de supervisión y métricas para detectar problemas en un entorno
- Utilizar pasos manuales que podrían ser automatizados
- Saber que algunas cosas no funcionan en un entorno y tienen que probarse en otros entornos
- Tener incoherencias entre entornos
- No tener formas rápidas/estandarizadas de desplegar nuevas instancias o contenedores
- No tener diseñadas baterías de pruebas de carga o estrés
En general, la deuda del proceso es todo lo que difiere de lo que un equipo de desarrollo consideraría un flujo de trabajo y un entorno ideales dado el contexto del proyecto.
Soy consciente de que a veces es casi imposible tener un entorno o un proceso 100% ideal, pero eso no significa que el equipo de desarrollo deba conformarse con cualquier cosa y no esforzarse por mejorarlo.
He visto y experimentado muchos de los problemas anteriores trabajando con diferentes empresas Como he mencionado antes, el mayor desafío que he encontrado al abordar estos problemas es que la mayoría de los desarrolladores son conscientes de que la situación está lejos de ser ideal. Sin embargo, lo aceptan estoicamente, sobre todo porque las prioridades que se establecen por el lado del producto siempre se centran en la entrega de valor y ven el tiempo destinado a arreglar los procesos o la deuda técnica como algo que impedirá o retrasará las entregas de características, en lugar de una inversión que mejorará el ritmo de entrega de valor en el futuro.
Aquí es donde los directores de ingeniería deben intervenir e impulsar.
El papel de la gestión tecnológica
Los puestos de dirección técnica, los jefes técnicos, pero sobre todo los directores de ingeniería o los vicepresidentes de ingeniería son las figuras clave que implementan la solución a la deuda de los procesos.
En los entornos ágiles, los equipos de desarrollo se autogestionan y su foco principal es la implementación de valor, el foco de los directores técnicos debería ser mejorar los procesos. Nunca debemos microgestionar a las personas, sino que debemos buscar siempre formas de mejorar la forma de hacer las cosas para que los equipos puedan trabajar de forma más eficiente y tengan una mejor experiencia de trabajo en el proyecto.
El equipo de desarrollo y los directores técnicos siempre deberían cuestionar y desafiar los procesos de la empresa, pero los desarrolladores tienen mucha carga sobre sus hombros, al fin y al cabo son los que están aportando valor. Es responsabilidad de los puestos de gestión tecnológica impulsar y facilitar este tipo de mejoras o reducir la deuda de los procesos.
Siguiendo esta idea, los directores técnicos deben abogar dentro de la empresa y educar al resto del equipo directivo sobre lo importante que es la inversión de tiempo en la mejora de los procesos.
La falsa dicotomía entre valor y proceso/herramientas
Salgamos por un momento del desarrollo de software e imaginemos que estamos en la cocina de un restaurante de alto nivel, con un jefe de cocina y un equipo de chefs.
¿Te los imaginas pidiendo tiempo o permiso para afilar sus cuchillos?
¿O pidiendo permiso para limpiar el aceite y los restos de comida de la encimera?
La respuesta es no, obviamente.
A pesar de que todo el mundo sabe que cuando un chef está afilando un cuchillo no está cocinando ningún plato, nadie discute el hecho de que, para obtener el mejor producto final, hay que invertir tiempo en mantener las herramientas y los procesos del chef lo mejor posible.
Otro ejemplo de este principio, mucho más directamente relacionado con el desarrollo de software, es el que predican los desarrolladores de juegos.
El tipo de la foto de arriba es John Romero, fundador de Id Software y cocreador de algunos de los juegos más exitosos de la historia (Wolfenstein 3D, Doom y Quake) en una reciente charla sobre los principios de desarrollo de software en sus días (por cierto, la sesión se puede encontrar aquí).
En cualquier empresa de desarrollo de software, la afirmación anterior tiene una traducción directa. «Los grandes flujos de trabajo hacen grandes productos. Cuida tus procesos tanto como cuidas tu código». Aceptaré que me he tomado alguna libertad en la analogía, pero creo que es bastante válida.
Lamentablemente, esta cultura no suele mantenerse en la mayoría de las empresas de desarrollo de software hoy en día: hay muchos entornos en los que el mantra es siempre «entregar nuevas características lo antes posible», minimizando y descartando cualquier iniciativa que tenga que ver con mantener un flujo de trabajo saludable que ayude al equipo a realizar sus tareas.
El problema de este enfoque es que degenera rápidamente. Cuanto más tiempo se pase sin prestar atención al entorno y a las herramientas, más tiempo se necesitará para ponerlo en forma una vez que se empiece a abordar, y más resistencia encontraremos en otros departamentos para invertir este tiempo en el proyecto. Este es el precio que pagamos, como ya hemos dicho.
Cultura de CI/CD
Mantener su proceso en forma debe seguir la misma filosofía que sigue la IC. Utilizando las palabras de Martin Fowler, si duele, hazlo a menudo. ( La frecuencia reduce la dificultad ).
El equipo de desarrollo debería plantearse las siguientes preguntas de forma periódica para hacer frente a los dolores indicados en las secciones anteriores:
- ¿Tenemos una pirámide de pruebas significativa?
- ¿Disponemos de conjuntos de datos adecuados para ejecutar la pirámide de pruebas tanto a nivel local como en otros entornos?
- ¿Estamos utilizando construcciones privadas que nos permiten ejecutar la mayoría de las pirámides de prueba localmente?
- ¿Disponemos de registros, herramientas de supervisión y métricas significativas?
- ¿Hemos automatizado todos los pasos manuales que se pueden automatizar?
- ¿Son nuestros entornos coherentes? ¿Se comportan todas nuestras pruebas de la misma manera independientemente del entorno?
- ¿Tenemos las pruebas de carga y estrés al día?
Para impulsar las mejoras, los directores técnicos deben estar siempre atentos a las preguntas anteriores y descubrir las áreas de dolor de los equipos de desarrollo, ofrecer ritmo y fiabilidad.
Conclusiones
Hoy en día, las organizaciones más importantes despliegan software a un ritmo casi demencial. Según el libro Phoenix Project, las organizaciones más valiosas despliegan con una frecuencia considerablemente mayor que cualquier otra empresa.
Esta frecuencia de despliegue es posible no sólo por la antigüedad del equipo de desarrollo, sino también porque los procesos dentro de las empresas son excepcionalmente saludables, eficientes y se mantienen continuamente.
La cultura de IC, pero también las capacidades de prueba, las políticas de reversión, los conjuntos de datos similares a los de producción, etc… suelen ser la diferencia clave entre una empresa típica o una startup y una empresa de alto rendimiento.
Si tenemos en cuenta el tiempo perdido debido a las pruebas poco fiables, los pasos manuales, los despliegues manuales, los errores detectados en etapas posteriores de nuestra tubería, etc., podemos admitir que algunos de los proyectos en los que hemos trabajado podrían haber durado unas semanas menos, y la experiencia del desarrollador habría sido mejor.
Aquí es donde la gestión tecnológica puede marcar la diferencia. Los directores técnicos deben esforzarse siempre por conducir a sus equipos hacia este nivel de perfección, que a menudo se pasa por alto.
