Agilidad, purismo y pragmatismo (II)

En el artículo anterior hacía una introducción al camino que la mayoría de los que llevamos ya unos años programando en PHP hemos vivido: desde el código espagueti más terrorífico -pero efectivo- del mundo, hasta donde nos encontramos hoy aplicando DDD, CQRS, Event Sourcing,… desarrollando con TDD y realizando despliegues automatizados a producción. En este camino ha surgido un punto de fricción entre el purismo y el pragmatismo que resulta interesante analizar.

Según a quién le preguntes, soy un auténtico pureta o un basuritas al que no le gusta hablar de arquitectura. La verdad, como en casi todo, está en el punto medio.

El pureta

Me gusta hablar de arquitectura. Tengo el gustazo y el orgullo de haber introducido CQRS y Event Sourcing en Ulabox en un proyecto crítico que lleva funcionando sin mayores hipos casi dos años, y durante los aproximadamente seis meses que duró su desarrollo los que estuvimos trabajando en él hablamos largo y tendido sobre todos los problemas que nos íbamos encontrando, sobre cómo mejorar un aspecto u otro del proyecto, sobre las cosas que nos rascaban en el modelo o en la forma que habíamos decidido implementarlo. Captura de requisitos con Event Storming y discusiones frecuentes con pizarra, rotuladores, post-its,… el paquete completo. La promesa de poder plantear la arquitectura de este proyecto como quisiera, con total apoyo para lanzarnos a usar CQRS y Event Sourcing, el reto técnico y personal de hacer algo desde cero que suponía un elemento crítico para la empresa fue una de las cosas que me convenció para unirme a Ulabox. Y lo disfruté como un enano. Con multitud de dudas y con bastante estrés a veces, pero disfruté de lo lindo, el proyecto pasó a producción y salvando los primeros días del natural bug-fixing y alguna tontería menor ha funcionado como un tiro durante estos dos años. Me siento muy orgulloso de aquel proyecto y de aquel equipo.

La entrega de aquel proyecto tenía un deadline claro: Chango, como llamamos internamente a este gestor de almacén, tenía que estar en funcionamiento para comenzar la venta de productos frescos de Ulabox en Barcelona y Madrid. Y cuando el calendario comenzó a apretar, cuando el estrés se fue acumulando, cuando teníamos que comenzar a meter más horas de las deseables en garantizar que alcanzábamos ese deadline y buscamos un procedimiento de seguridad en caso de que hubiese algún fallo durante su funcionamiento en los primeros días… a alguien se le ocurrió que por si algo fallaba podíamos generar el listado de preparación en una hoja Excel y pasársela a los operarios de almacén por si, en el peor caso, tenían que seguir a mano. Tras treinta segundos de un incómodo y revelador silencio, nos dimos cuenta de que hacía seis meses que podíamos haber hecho esto y, aún con una velocidad mucho menor y una capacidad muy limitada, haber comenzado a preparar frescos en almacén mientras continuábamos con el desarrollo. Pero nadie se había cuestionado antes de esa epifanía cuál era el objetivo de negocio que tenía que cubrir el proyecto y cómo podíamos entregar valor lo antes posible. Nos lanzamos como buenos techies de cabeza a nuestras pizarras, nuestros rotuladores, nuestros post-its y nuestros teclados.

Y el problema es que, más a menudo de lo que nos gusta reconocer, caemos en ese mismo error una y otra vez.

El basuritas

En el extremo opuesto, en otras empresas eso de la arquitectura, las buenas prácticas y los refactors es un capricho de los frikis de IT. Algo que hay que dejarles hacer de vez en cuando para que no se deshidraten de tanto llorar. Pero lo justo y sin pasarse, porque aquí lo que cuenta es meter mandanga de la buena, producto a piñón, sacar cosas y si explota algo ya lo arreglaremos. Si se puede hacer en diez minutos, mejor que en media hora.

El problema de esa forma de trabajo es que es una máquina incansable de generación de bugs y acumulación de deuda técnica, por no hablar de la forzosa rotación de plantilla a medida que la gente se quema de hacer chapuzas un día sí y otro también. Pero también tiene sus virtudes: es imposible ser más rápido llevando cosas a producción, y a veces una chapuza a tiempo es suficiente para validar una hipótesis de negocio. El basurismo habita un par de pasos más allá de la frontera del pragmatismo y se camufla astutamente bajo su pellejo. Pero antes o después, si las cosas van bien, deja de funcionar.

Aunque desde nuestra perspectiva techie normalmente vemos la deuda técnica como algo malo, no siempre es así. En “economía para torpes”: la deuda buena te abre posibilidades reales de incrementar el ratio entre ingresos y gastos, supone aprovechar oportunidades de obtener ingresos extra o reducir gastos actuales, mientras que la deuda mala atiende generalmente a deseos o caprichos que no responden a una necesidad y que reducen tu capital sin ofrecer nada tangible a cambio.

Cada dólar ahorrado a base de introducir deuda técnica supone cuatro gastados en eliminarla más adelante.

Cuando sacamos a relucir esa contundente cita sobre el coste de la deuda técnica olvidamos el coste de pérdida de oportunidad y el incremento de riesgo que supone dedicar más tiempo del estrictamente necesario a validar una hipótesis o a descubrir el mundo real a través de las primeras entregas tempranas. Puede que necesitemos cuatro dólares para rehacer aquella chapuza que hicimos por un dólar, pero ¿cuánto nos hubiera costado realmente hacerla por tres? ¿Y si hubiéramos tenido que tirar a la basura ese trabajo en caso de que la hipótesis no se cumpla? ¿Y si el tiempo de más invertido en ponerla en producción nos hace perder la ventana de oportunidad?

El punto medio

Si nos cegamos desde el primer momento en la arquitectura, en el purismo extremo y la perfección techie “de libro” y olvidamos que es su aportación de valor a negocio la que le da sentido -y nos paga la nómina- no estamos haciendo bien nuestro trabajo. Entre otras cosas porque sabemos, aunque preferimos olvidar, que la incertidumbre inicial en todo proyecto hace inevitable el cambio más adelante. Cuanto más tarde tomemos decisiones, sin que suponga perder alternativas, más contenemos el riesgo y más probable es que tomemos la decisión correcta al contar con mucha más información. Cuanto antes entreguemos un producto mínimo, antes podremos validar sus hipótesis. Si hay una constante en el desarrollo de software es el cambio, la incertidumbre, por más que analicemos y detallemos libros de requisitos de quinientas páginas: no tiene sentido dedicar meses a definir la arquitectura perfecta, porque tendremos que cambiarla antes o después. Es normal dedicar más tiempo a infraestructura en el inicio de un proyecto, pero desde la primera iteración debemos intentar entregar algo de valor a negocio, por mínimo que sea, que nos permita aprender sobre lo que el proyecto necesita y aprovecharlo para refinar las próximas iteraciones. Y, pensando fuera de la caja, esta solución temprana no tiene por qué ser estrictamente tecnológica.

Por otro lado, si nos enfocamos en la entrega extrema chapuceando día sí y día también sin mirar atrás, tampoco estaremos haciendo bien nuestro trabajo. Tiene sentido aceptar un compromiso de deuda técnica en productos en fase temprana de evolución, para validar hipótesis, para alcanzar ventanas de oportunidad que no podríamos alcanzar de otro modo,… pero para que esa deuda sea una deuda buena tenemos que pagar las cuotas de la hipoteca que acabamos de contratar con ella. Si dejamos que se acumulen y pervivan en el código para siempre funcionen o no, si seguimos hipotecándonos en cada nueva funcionalidad, tendremos un verdadero problema con el paso del tiempo.

El punto medio se basa en entregar, desde el inicio, un mínimo de funcionalidad de la que ya podamos obtener feedback de negocio. En asumir que la arquitectura emerge desde la evolución del producto, que inevitablemente cambiará a lo largo del desarrollo. En hacer siempre aquello que sea lo más sencillo posible para cumplir con la necesidad del producto, porque cuanto más sencillo sea más fácil será cambiarlo después. En saber también que un compromiso no es una chapuza, ni da libertad para saltarse los acuerdos de calidad a los que ha llegado el equipo.

El punto medio se basa en el sentido común. En no ser más papistas que el Papa, pero tampoco caer en la sumisión ciega a la chapuza por sistema. En no entender nuestro trabajo como una obra de arte digna de un museo o una ofrenda sagrada al arcano dios del código, ni agachar la cabeza y aceptar sumisamente que nunca dejaremos de hacer chapuzas porque así es como se ha hecho siempre. En poner los pies en la tierra y entender que nuestro trabajo no es elaborar una tesis académica sobre el hype de moda ni remendar jirones y poner un parche sobre otro día tras día, y que sólo tiene sentido en la medida en que sirve a la misión y objetivos de la empresa. En el espíritu crítico y la profesionalidad entendida de forma global. En la entrega de valor temprana y la contención del riesgo. En la inspección, adaptación y transparencia.

  • La arquitectura emerge del desarrollo. Plantear una arquitectura cerrada desde el inicio supone dedicar tiempo y esfuerzo a algo que sabemos que tendremos que cambiar o desechar, y retrasa la validación y entrega de valor de negocio.
  • Retrasamos las decisiones arquitectónicas todo lo posible mientras no suponga renunciar a alternativas, maximizando el conocimiento que tendremos en el momento de tomarlas y reduciendo con ello el riesgo de error.
  • Proporcionamos la solución más sencilla posible que cumpla con las necesidades del producto. No sólo por agilidad de desarrollo, si no porque sabemos que el producto cambia a lo largo del tiempo y, cuanto más sencilla sea la solución, más sencillo será adaptarla al cambio.
  • Desde la primera iteración entregamos un mínimo de valor a negocio. Pensamos fuera de la caja para ver si es posible entregar valor y validar hipótesis de forma sencilla y no necesariamente tecnológica. Hacer esto nos permite obtener información sobre las necesidades del producto lo antes posible y adaptar la solución a ellas.
  • La deuda técnica es un compromiso a veces bueno y necesario. Permite validar hipótesis rápidamente y alcanzar ventanas de oportunidad que de otro modo podrían perderse. No supone libertad para saltarse los acuerdos de calidad del equipo. Somos conscientes de que tendremos que eliminar esta deuda en el futuro, y lo aceptamos como un compromiso con la oportunidad de negocio y la contención de riesgo.

Y todo esto sólo tiene validez si nos apoyamos en valor, foco, compromiso, respeto y transparencia.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.