Este artículo, parte de una serie sobre lecciones aprendidas al financiar, escalar y vender empresas de producto SaaS, expone cómo una organización puede volverse incapaz de entregar cambios coherentes aun cuando cada decisión individual parezca razonable. El autor, que ya ha argumentado contra varias prácticas por separado —dividir el código en múltiples repositorios, usar ramas de larga duración, optar por microservicios de forma refleja, mantener un equipo dedicado de aseguramiento de calidad, exigir un porcentaje fijo de cobertura de pruebas y depender de la revisión de pull requests como control de calidad—, ahora advierte sobre el efecto compuesto de aplicarlas todas a la vez.
El texto sostiene que cada una de esas prácticas introduce una frontera de coordinación, y que dichas fronteras no se suman: se multiplican. Un cambio pequeño, como añadir un campo a un concepto compartido, puede acabar exigiendo cuatro pull requests revisados por separado, cada uno con su propia puerta de cobertura, sobrevivir fusiones con semanas de desfase y propagarse por una red de microservicios desplegados en combinaciones distintas, hasta llegar a un equipo de QA que no puede determinar qué versión exacta está probando. El artículo ilustra ese cálculo y lo compara con un manual de sabotaje organizativo de la Oficina de Servicios Estratégicos estadounidense de 1944, donde la diferencia con un pipeline moderno que nadie puede cruzar es solo la intención.
La solución propuesta es la resta: monorepositorio, desarrollo basado en trunk con feature flags, fronteras dentro del proceso en lugar de microservicios reflejos, calidad en manos del equipo, revisión sincrónica y cobertura decidida por fase. Cada recomendación elimina un multiplicador. La disciplina, dice el autor, consiste en negarse a añadir cualquier frontera que no se pague por sí misma, porque las que no lo hacen no son neutras: se multiplican contra todas las demás.