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.
No hay posts relacionados.