Catedrales y bazares

En la tercera sesión del programa de dirección de producto del Instituto Tramontana exploramos una de las metáforas más influyentes en la historia del software: la catedral y el bazar. Esta fue una sesión enteramente práctica, con las manos en el código, porque algunas ideas solo se asimilan cuando se hacen.

La mayoría de los productos digitales —aunque los veamos como aplicaciones cerradas, limpias y uniformes— están formados por piezas pequeñas que se conectan entre sí. No son catedrales monolíticas: son bazares llenos de módulos que interactúan. Comprender esta diferencia, y saber cuándo aplicar cada modelo, es una de las habilidades más valiosas para quien dirige producto.

Dos maneras de construir

La metáfora viene de Eric S. Raymond y su ensayo The Cathedral and the Bazaar, publicado en 1997. Raymond observó que había dos formas radicalmente distintas de desarrollar software:

En la catedral, el software se construye de forma centralizada, planificada y cerrada. Hay un arquitecto (o un pequeño grupo) que diseña el conjunto. Los planos se completan antes de poner el primer ladrillo. El código se libera solo cuando está terminado. Es el modelo del software comercial clásico, pero también de muchos proyectos internos en empresas.

En el bazar, el software emerge como un mercado abierto. Piezas pequeñas, cambios frecuentes, aportaciones distribuidas. "Release early, release often" es el mantra. Los usuarios son co-desarrolladores. Los errores se encuentran rápido porque hay muchos ojos mirando. Es el modelo del software libre, de Linux, de los proyectos que crecen por acumulación de contribuciones.

El objetivo de la sesión no fue juzgar cuál es "mejor". Ambos estilos coexisten en todos los productos modernos, aunque no siempre de forma explícita. La tensión entre rigidez y flexibilidad aparece en cada decisión de diseño. Saber reconocerla es el primer paso para gestionarla.

La tradición UNIX

Antes de Raymond, había UNIX. Y UNIX nos dejó una filosofía de diseño que sigue estructurando el software contemporáneo. Tres ideas la resumen:

Haz una cosa y hazla bien. Cada herramienta, cada módulo, cada función debería tener una responsabilidad clara y acotada. No intentes resolver todo en un solo lugar.

Conecta piezas simples para obtener resultados complejos. La potencia no viene de construir componentes gigantes, sino de poder combinar componentes pequeños de formas inesperadas. El pipe de UNIX (|) es el símbolo de esta filosofía: la salida de un programa se convierte en la entrada del siguiente.

Trata todo como un flujo. Entradas que se transforman en salidas. Datos que pasan por etapas. Información que fluye. Esta forma de pensar —que ya exploramos en la sesión anterior con los paradigmas productor-consumidor— es el ADN del software modular.

The Art of UNIX Programming, también de Raymond, documenta esta tradición con detalle. Y The UNIX Programming Environment de Kernighan y Pike sigue siendo una lectura fundamental para quien quiera entender cómo se diseña software que dura.

El software como ensamblaje

A diferencia de las construcciones monolíticas, los sistemas modernos se ensamblan, no se "terminan". Son:

• colecciones de piezas con responsabilidades claras,
• componentes que evolucionan a ritmos distintos,
• subsistemas conectados por interfaces,
• partes reemplazables sin necesidad de rehacer el conjunto.

Esta idea tiene consecuencias profundas para producto. Significa que una buena dirección de producto consiste, en gran medida, en decidir dónde colocar los límites y qué forma tienen las interfaces. No es una decisión técnica que se delega a ingeniería; es una decisión de diseño que afecta a todo: qué se puede cambiar fácilmente, qué requiere coordinación, qué puede evolucionar de forma independiente.

Por qué la modularidad importa

La modularidad introduce ventajas concretas que afectan directamente a la capacidad de un producto para crecer y adaptarse:

Reduce la complejidad. Un sistema de cien mil líneas de código es inmanejable. Cien módulos de mil líneas cada uno pueden entenderse uno a uno.

Acota la responsabilidad. Si algo falla, sabes dónde buscar. Si algo hay que cambiar, sabes qué tocar. Los límites claros son también límites cognitivos.

Permite paralelizar trabajo. Equipos distintos pueden trabajar en módulos distintos sin pisarse. Esta es una de las razones por las que las arquitecturas modulares escalan mejor organizativamente.

Facilita la experimentación. Puedes cambiar un módulo, probarlo, y si no funciona, volver atrás. El coste del error está acotado.

Limita el impacto de un fallo. Un bug en un módulo bien aislado no debería tumbar el sistema entero. Los límites son también cortafuegos.

Mejora la capacidad de explicar. Cuando puedes describir tu producto como una composición de piezas con responsabilidades claras, puedes comunicarlo mejor —a usuarios, a inversores, a nuevos miembros del equipo.

Pero la modularidad también tiene riesgos. Demasiada fragmentación conduce al caos. Heterogeneidad sin criterio produce sistemas donde nadie entiende el conjunto. La modularidad es una disciplina, no una ausencia de reglas.

Interfaces como herramienta de pensamiento

Un módulo se entiende por lo que hace visible:

• qué recibe (entrada),
• qué hace (transformación),
• qué devuelve (salida).

No por lo que ocurre en su interior. El interior es la caja negra de la que hablamos en la primera sesión.

Esta forma de pensar es especialmente útil para producto. Ayuda a describir funcionalidades sin entrar en detalles de implementación. Permite delimitar responsabilidades entre equipos: "vosotros os encargáis de que este módulo reciba X y devuelva Y; cómo lo hagáis es vuestra decisión". Reduce las dependencias que ralentizan el desarrollo.

Las APIs son la expresión más visible de este principio. Una API bien diseñada es una interfaz clara: documenta qué entra, qué sale, y qué garantías ofrece. Pero el principio se aplica a cualquier escala, desde una función hasta un sistema distribuido.

Cuándo la catedral tiene sentido

El enfoque catedral no es obsoleto. Hay contextos donde la planificación centralizada y el control estricto siguen siendo la mejor opción:

• Cuando se necesita coherencia férrea. Sistemas de seguridad, plataformas de pago, infraestructura crítica. Aquí las sorpresas son inaceptables.

• Cuando el dominio requiere pocas variaciones. Si el problema está bien definido y no cambia mucho, el coste de la flexibilidad no se justifica.

• Cuando la independencia entre piezas no aporta valor. A veces la integración tight es exactamente lo que necesitas.

• Cuando la evolución debe ser muy controlada. Regulación, compliance, auditorías. Hay industrias donde "release early, release often" no es una opción.

Entender cuándo el modelo catedral es apropiado evita el error de aplicar el bazar por defecto, como si fuera siempre superior.

Ejemplos modernos de modularidad

La tradición modular está presente en casi todo el software contemporáneo:

• APIs como fronteras entre sistemas, contratos que permiten que piezas desarrolladas por equipos distintos (o empresas distintas) trabajen juntas.

• Webhooks como mecanismos de extensión: "cuando pase X, avísame en esta URL". El sistema se abre sin exponer sus internals.

• Pipelines que transforman datos en etapas, cada una con una responsabilidad clara.

• Microservicios, con todas sus complejidades, son una expresión del principio de hacer una cosa y hacerla bien.

• Herramientas CLI que se combinan en scripts, exactamente como en los años 70.

• Integraciones que amplían capacidades sin tocar el núcleo del producto.

Todos estos patrones ilustran cómo la filosofía del bazar sigue siendo relevante, aunque ahora la llamemos arquitectura de servicios o diseño orientado a API.

Pensar en módulos

La sesión terminó con una reflexión sobre por qué la modularidad es un marco útil para las decisiones de producto:

• Obliga a simplificar. Si no puedes describir qué hace un módulo en una frase, probablemente hace demasiado.

• Ayuda a explicar. "El producto tiene tres partes: X hace esto, Y hace aquello, Z conecta X con Y" es más útil que un diagrama de mil cajas.

• Delimita responsabilidades. Tanto técnicas como organizativas.

• Reduce sorpresas. Los límites claros son también expectativas claras.

• Permite explorar sin rehacer todo. Puedes experimentar con una pieza mientras el resto sigue funcionando.

En un entorno donde los sistemas son cada vez más complejos, pensar en módulos es pensar mejor. No es una técnica; es una forma de ver el mundo. Y, como vimos en esta sesión con las manos en el código, es una forma de ver que convierte la complejidad en algo manejable.

---

Práctica de la sesión

Ejercicio práctico: Modularidad en acción. Toda la sesión fue práctica, trabajando sobre el repositorio del programa. El ejercicio de la sesión 3 consistía en analizar un sistema existente, identificar sus módulos, mapear sus interfaces, y proponer mejoras en la separación de responsabilidades. Trabajamos en parejas, con el código delante, discutiendo dónde estaban los límites y dónde deberían estar.

Para casa: Continuación del ejercicio, ahora trabajando con modelos y entidades de datos. El objetivo era aplicar los principios de modularidad a la capa de datos: identificar las entidades del dominio, definir sus límites, y diseñar interfaces claras entre ellas. Una introducción práctica al Domain-Driven Design de Eric Evans.