Según la Wikipedia, la Ley de Conway dice que las organizaciones que diseñan sistemas sólo pueden producir diseños que repliquen las estructuras de comunicación de la propia organización.
Quizá la forma más gráfica de verlo es este ejemplo de Eric S. Raymond:
Si tienes cuatro equipos de trabajando desarrollando un compilador, lo que conseguirás es un compilador de 4 fases.
Es razonable. Para hacer que un sistema funcione, todos los que participan en su desarrollo deben comunicarse para poder colaborar y los canales de comunicación marcarán mucho lo que se puede hacer y lo que no. Si quieres poner tres equipos separados a trabajar en el proyecto, no te quedarán muchas más opciones que dividirlo en, al menos, tres bloques independientes en los que puedan trabajar esos equipos, desacoplando al máximo esos bloques y estableciendo unos interfaces rígidos entre ellos.
No hace falta pensar en empresas muy grandes para que ocurra esto. Cualquiera que haya tenido que integrar su software con el de otras empresas lo habrá vivido. Acabas colaborando con distintos departamentos de desarrollo y eso te lleva a diseños que permitan acotar muy bien la responsabilidad de cada uno. Es mucho más fácil coordinarse entre varias empresas para desarrollar un sistema distribuido que para hacer una aplicación monolítica, incluso aunque la solución más simple al problema fuese hacer una única aplicación monolítica.
Todo esto además se manifiesta en los distintos niveles del diseño, desde la arquitectura general el sistema, hasta la separación del código en módulos, clases, métodos o funciones. Si estás programando por parejas con un compañero en la implementación de un módulo y decidís que es mejor poder avanzar en paralelo, acabaréis acordando alguna estructura (por ejemplo, clases) con un interfaz fijo que os permita separaros y seguir programando cada uno por vuestro lado. Si os hubieseis mantenido juntos, tal vez no hubiera sido necesaria ese interfaz y el diseño podría haber sido diferente.
Las consecuencias negativas
En ocasiones se percibe la Lay de Conway como algo negativo, y lo cierto es que puede llegar a serlo.
Un caso claro es el que comentábamos antes de la coordinación de varias empresas, donde llegar a una colaboración muy estrecha a nivel de código es sumamente complejo y la única opción viable muchas veces es partir el sistema en tantos subsistemas como empresas estén colaborando, independientemente de que sea la mejor opción.
Otro caso frecuente se produce cuando tenemos equipos muy especializados. Por ejemplo, muchas veces la gente encargada del diseño gráfico no es la misma que la encargada del desarrollo, y si analizas el código casi puedes ver una línea clarísima que separa las partes hechas por cada uno. Esto hace que cuando hay que realizar cambios sea todo mucho menos ágil y que la experiencia de usuario se resienta porque hace falta separar muy bien la parte de diseño de la parte de implementación para que ambos equipos puedan trabajar por separado.
Pero el caso más paradigmático es, sin duda, el de las empresas formadas por «expertos» en determinadas tecnologías, que además suelen son «Golden Enterpise Partner» de los fabricantes de turno. Si una empresa tiene un equipo de SharePoint Ninjas, otro de Dynamics Samurais y algunos Azure Rockstars, puedes estar seguro de cuál será la solución que darán a cualquier problema. Ley de Conway en su máxima expresión.
Asumir lo inevitable
Tampoco hay que ver la Ley de Conway como algo necesariamente negativo. Más bien hay que verlo como algo inevitable. Algo que no es ni bueno ni malo, simplemente, es, y hay que aprender a vivir con ello.
En un mundo ideal, cada vez que afrontásemos un desarrollo podríamos reconfigurar la organización que lo lleva a cabo para alinearla con los requisitos del desarrollo y alcanzar la solución óptima de la manera más eficiente posible.
Pero claro, eso es en un mundo ideal.
En el mundo real, trabajamos en estructuras ya creadas que no podemos cambiar de la noche a la mañana, y es mejor ser consciente de los puntos fuertes y débiles de estas estructuras para intentar aprovecharlos a nuestro favor, o al menos intentar que nos frenen lo menos posible.
Eso no quiere decir que no puedas o no debas intentar mejorar la estructura de la organización para adecuarla al tipo de productos o proyectos que desarrollas, pero igual que reescribir una aplicación desde cero suele ser una mala salida y es mejor ir haciendo mejoras incrementales, en este caso suele ser más fácil realizar cambios graduales que montar una revolución.
En función de cómo esté organizada la empresa, hay arquitecturas que pueden resultar más adecuadas que otras. Por ejemplo, una arquitectura basada en microservicios puede ser muy práctica cuando necesitamos repartir el trabajo entre muchos equipos casi independientes. Sin embargo, si se trata de un equipo pequeño, que mantiene una comunicación muy estrecha, apostar por un monolito majestuoso puede suponer un sistema más sencillo de comprender y desplegar.
Es similar a lo que ocurre con lenguajes de programación. Puede que tu proyecto se preste especialmente a desarrollarlo sobre Erlang, pero si tienes un equipo de 20 personas para hacerlo y ninguno tiene ni idea de Erlang, tal vez sea preferible buscar otra alternativa antes que despedir a todo el equipo y contratar un grupo de expertos en Erlang.
Por otra parte, ir ajustando la estructura de la empresa al tipo de desarrollos que suele realizar permite mejorar la eficiencia. Por ejemplo, si nuestros desarrollos implican el desarrollo de backends y aplicaciones para dispositivos móviles, parece razonable poder trabajar en paralelo en ambas y tener equipos preparados para ello. O si desarrollamos 4 productos diferentes, poder avanzar en todos ellos simultáneamente.
Ello no tiene por qué acabar en una especialización excesiva de los miembros del equipo (de la que no soy muy partidario, por aquello de tener equipos tolerantes a fallos). Es posible que las mismas personas asuman (o compartan) distintos roles en función del proyecto.
Conclusiones
La estructura del sitio en que trabajamos va a afectar a la forma en que desarrollamos. Eso es algo inevitable y que debemos tener en cuenta a la hora de tomar decisiones sobre el diseño de una aplicación.
No podemos pretender cambiar por completo la estructura y la forma de trabajar de un sitio sólo porque se haya puesto de moda una arquitectura o metodología de trabajo determinado, pero tampoco debemos ser excesivamente conformistas y, si la entorno existente no permite resolver los problemas de manera eficiente, habrá que buscar la forma de cambiarlo.
Al final, como siempre, se trata de buscar un compromiso que nos permita sacar partido a lo que ya tenemos mientras lo vamos mejorando. Nadar y guardar la ropa, que diría mi abuelo.
El artículo excelente como siempre! Pasé por una farmacéutica que desarrolló la receta electrónica para España y envió cada desarrollo a equipos específicos de cada comunidad sin una base común. El desastre era previsible y así ocurrió. Pero… (lo has pedido)
Con ese ejemplo «de pasada» en cuanto a la elección de arquitectura de micro-servicios o monolítica, dejas fuera a un equipo SCRUM: entre 7 y 10 personas (equipo pequeño) con daily, sprint planing y restrospective (muy comunicado). No creo que en la elección de una arquitectura, el tamaño del equipo o su comunicación, sea un elemento a tener en cuenta.
Los costes devops en Microservicios (por si fuera otro inconveniente) los cubres con tiempos de respuesta (quien da primero, da doble!)
:)
Gracias, Omar :-)
Yo sí creo que la configuración de los equipos puede afectar a la elección de una arquitectura o, al menos, que hay arquitecturas que se prestan mejor para determinadas configuraciones de equipos. Eso no quiere decir que esas arquitecturas no sean prácticas también en equipos pequeños, co-localizados y con una comunicación excelente, sino que en otras circunstancias son casi imprescindibles.
Pasa con todo tipo de herramientas o metodologías. Por ejemplo, el sistema de control de versiones. Si todo el equipo trabaja siempre en red local, utilizar algo arcaico como Subversion puede ser bastante viable, pero si necesitas dar soporte a usuarios desconectados, GIT es una solución mucho mejor. El equipo que trabaja siempre en red local también puede aprovecharse de GIT, claro, pero para el que trabaja desconectado es mucho más necesario.
Seguramente tengas argumentos de peso para pensarlo ;-)
Yo, basado solo en los proyectos por los que he pasado, el conocimiento del equipo sí puede influir, pero no me viene a la cabeza un caso en que la composición afecte.
En mi opinión, la validez de la ley de Conway es directamente proporcional a la ineptitud de quienes diseñan las estrategias de dichas organizaciones y en mucha menor medida de quienes las ejecutan.
Argumentar sería largo (y mi experiencia es limitada como para tanto) pero gráficamente podría apuntar a que ni la Gran pirámide de Guiza, ni las normas de circulación, ni los rascacielos, las misiones Apolo, etc… se perciban constituidas por multitud de pequeños equipos sino todo lo contrario.
Pero está bien tener una ley a la que achacar nuestra ineptitud (incluyo aquí la mía propia).
En el mundo del desarrollo de software es peor todavia puesto que tenemos un sistema (estructuras de comunicacion entre procesos) para desarrollar software cuya salida es otro sistema; el que estamos modelando como software; y a este ultimo tambien se le aplica la ley de conway.
Continuando con la metafora: Si le pasas tu compilador de 4 fases, para ser usado, a una organizacion que tiene una estructura de comunicacion totalmente diferente tienes el poyo asegurado.