El otro día estaba dando vueltas por la web, y en un artículo me encontré que mencionaban a la Ley de Conway (pondría el link al artículo si recordara cuál era...). En todo caso, me causó curiosidad: ¿qué es la Ley de Conway? ¿A qué se refiere? ¿Cuál es su consecuencia para el liderazgo de equipos de desarrollo?
La Ley de Conway
La Ley de Conway es una frase de "sabiduria popular", que hace referencia al programador Melvin Conway, que introdujo la idea por primera vez en 1968. La Ley de Conway dice:
Las organizaciones que diseñan sistemas están limitadas a producir diseños que son copias de las estructuras de comunicación de estas organizaciones.
Hay algunas variantes a esta ley, que apuntan al mismo concepto:
- Si tenemos cuatro equipos trabajando en un compilador, obtendremos un compilador de 4 pasadas.
- Cualquier pieza de software refleja la estructura organizacional que la produjo.
Aunque pueda parecer un chiste (por el uso de la palabra "Ley"), lo cierto es que la Ley de Conway no es una broma ni un sarcasmo, sino una observación sociológica válida. Es una consecuencia del hecho de que dos módulos de software A y B no pueden comunicarse correctamente entre si a menos que el diseñador e implementador de A se comunique con el diseñador e implementador de B. Luego, la estructura de la interfaz de un sistema de software necesariamente mostrará alguna congruencia con la estructura social de la organización que la produjo.
Ejemplos de la Ley de Conway
Consideremos un sistema grande S que el gobierno quiere construir. El gobierno contrata a la empresa X para construir el sistema S. Digamos que la empresa X tiene 3 equipos de trabajo (E1, E2, E3) que participan en el proyecto. La Ley de Conway sugiere que es probable que el sistema resultante consiste de 3 subsistemas principales (S1, S2, S3), cada uno construido por un equipo de trabajo. Más importante, las interfaces resultantes entre los sistemas (S1-S2, S1-S3, S2-S3, etc) van a reflejar la calidad y naturaleza de las comunicaciones interpersonales reales entre los equipos de trabajo (E1-E2, E1-E3, E2-E3, etc).
Es decir, que los equipos que logren una buena comunicación en el mundo real tendrán más probabilidades de crear interfaces de software de mejor calidad entre sus subsistemas. Por otro lado, los equipos que tengan problemas de comunicación interpersonal construirán interfaces entre los subsistemas que reflejarán enstas dificultades.
Otro ejemplo: consideremos un equipo de software de dos personas, A y B. Supongamos que A diseña y codifica una clase de software X. Más tarde, el equipo descubre que la clase X necesita nuevas características. Si la persona A añade estas características, es probable que simplemente expanda a la clase X para incluir estas características nuevas. En cambio, si la persona B es quien hace el agregado, B podría tener miedo de romper a X, por lo que es probable que decida crear una nueva clase X2 que herede de X, y ponga las cosas nuevas en X2. Entonces, en este ejemplo, el diseño final es un reflejo de quién implementa la funcionalidad.
Un ejemplo de la vida real: el Orbitador Climático de Marte de la NASA se estrelló porque un equipo utilizó unidades de medidas comunes en Estados Unidos (pulgadas, pies y libras) mientras que el otro equipo usó unidades métricas para ciertas operaciones clave de la nave. Esta información era crítica para mantener a la nave en una órbita correcta alrededor de Marte. "Las personas comente errores", dijo el Dr. Eward Weiler de la NASA. "El problema no fue el error, sino que fue una falla en el sistema de ingeniería de la NASA, en las verificaciones y en nuestro proceso para detectar este error. Por eso perdimos la nave".
Conclusión
La Ley de Conway es una interesante observación sobre el comportamiento humano, sus relaciones interpersonales y sus consecuencias en el trabajo en equipo y la creación de software. La consecuencia es ya conocida: los buenos equipos generan buen software. Es por esto que la problemática real del desarrollo de software es la creación de grandes equipos humanos, que colaboren y se comuniquen entre si para luego poder crear el mejor software posible.
Las organizaciones rígidas que no están dispuestas a reorganizarse para crear diseños óptimos (usualmente por miedo a crear una organización peor) terminan produciendo diseños pobres que reflejan la organización pre-existente.
Las técnicas y prácticas ágiles aputan justamente a esto: valorar más a las personas y sus relaciones que a las herramientas y los procesos. Las organizaciones deben tener como meta crear grandes equipos humanos, quienes entonces podrán producir grandes productos.