E-Book, Spanisch, 288 Seiten
Bonilla El algoritmo que cambió el mundo
1. Auflage 2025
ISBN: 978-84-18164-52-1
Verlag: Nola Editores
Format: EPUB
Kopierschutz: 6 - ePub Watermark
Y otras historias informáticas
E-Book, Spanisch, 288 Seiten
ISBN: 978-84-18164-52-1
Verlag: Nola Editores
Format: EPUB
Kopierschutz: 6 - ePub Watermark
David Bonilla (Madrid, 1977) es graduado en Desarrollo de Aplicaciones por el mítico y extinto CDTI. Su carrera profesional ha estado siempre dedicada a la industria informática, donde ha trabajado en todo tipo de empresas -desde grandes corporaciones hasta startups de Silicon Valley-, ha vivido la salida a Bolsa de dos de ellas y ha fundado y vendido otras dos. Al margen de su carrera profesional, David Bonilla escribe una Newsletter semanal sobre tecnología, la Bonilista, que ha conseguido alcanzar una inesperada difusión entre la comunidad técnica en español. También organiza uno de las principales conferencias del sector, la TRGCON o «Tarugoconf», que se celebra cada año Madrid, y cuenta con casi 1.000 asistentes. En sus propias palabras, David es, sobre todo, «el marido de Candela, el papá de Irene y Dani, del Atleti, gallego militante, programador y corredor -lento- de maratones», y, como este libro demuestra, una persona profundamente enamorada de su profesión.
Autoren/Hrsg.
Weitere Infos & Material
3. Revisando la Ley de Conway
13 de agosto de 2023
En 1967, el informático Melvin Conway llegó a la conclusión de que «las organizaciones están abocadas a producir diseños que se estructuran de la misma forma que se estructura la comunicación en dicha organización».
Vamos, básicamente, que —por ejemplo— si una empresa tecnológica se estructura en equipos autónomos que se coordinan entre sí, es más que probable que acaben desarrollando un software modular. Si, por el contrario, se organiza como un único gran equipo con grupos especializados para la parte de y de , lo más normal es que cada una de esas capas se desarrolle de forma independiente y acaben integrándose con mejor o peor fortuna.
Lo que ha llegado a ser conocido como «la Ley de Conway» es uno de los axiomas más importantes de la industria informática, pero —también— de los más desconocidos y, sobre todo, malinterpretados. Porque, aunque Conway habla de «estructuras de comunicación», solemos quedarnos únicamente con la parte de estructuras y pasar por alto la parte de comunicación.
La confusión puede venir en parte porque en el 1 —una obra seminal de la cultura informática— se simplificó la Ley como «la organización del software y del equipo que lo produce serán congruentes», pero también porque —frecuentemente— los programadores minusvaloramos la importancia de la comunicación en el desarrollo de software.
El principio de «software funcionando antes que documentación completa» —introducido por el 2 y que fue mal traducido como «documentación extensiva»— ha confundido a mucha gente. Hasta el punto de creer que lo más importante es aporrear teclas hasta que algo «funcione», antes que entender, consensuar y explicar cómo se debe hacerlo y por qué.
Y cuando hablamos de «comunicación», solemos acotarla a nuestra interacción con proveedores o clientes, no a la transmisión de información y toma de decisiones entre los actores más relevantes de nuestro proceso productivo: los miembros de nuestro equipo. La última vez que comprobé cuánto invertía una empresa —la mía— en comunicación externa e interna, la proporción era de 8 a 1.
Otro problema de la Ley de Conway es que no se puede demostrar. De hecho, el rechazó el artículo que la contenía con el argumento de que Conway no presentaba ninguna evidencia que probara su tesis. Así que, finalmente, las cuatro páginas de 3 se publicaron en el número de abril de 1968 de la revista .
Pero Conway no sugiere causalidad, sino correlación. No da por hecho que una empresa produce productos o servicios de una determinada manera por sus procesos de comunicación interna, sino que entre unos y otros hay una correspondencia.
En 1997, un interesante estudio de Nigel Bevan sobre problemas de usabilidad en el diseño de webs4 concluyó que «a menudo, las organizaciones producen sitios web con un contenido y estructura que reflejan más las preocupaciones internas que las necesidades de sus usuarios».
En 2008, después del fracaso que supuso Windows Vista, Microsoft financió una investigación de la Universidad de Maryland que demostró la influencia de la estructura de una organización en la calidad del software que produce5. Usando el proceso de desarrollo de Vista como caso de estudio, concluyó que «la complejidad de la estructura organizativa de una empresa predice de forma estadísticamente significativa la tendencia al fallo de la misma».
Finalmente, no deja de ser paradójico que —en 2012, cuarenta y cinco años después de rechazar el artículo original de Conway— Harvard publicara un texto sobre la dualidad entre la arquitectura de un producto y la organización que lo desarrolla6, en el que se constatan las evidencias sobre «el impacto de las decisiones de diseño organizacional en la estructura técnica de los productos que estas organizaciones desarrollan posteriormente».
Pero más allá de sesudos estudios y complejas investigaciones, hay algo dentro de nosotros —nuestro «test de tripas»— que nos dice que Conway tenía razón.
Que si una empresa crea dos equipos —uno para iOS y otro para dispositivos Android—, aunque en teoría desarrollen la misma aplicación, la similitud de las dos versiones tendrá una relación directa con la comunicación que exista entre un grupo y otro. Que si los bugs y problemas reportados por los usuarios se comunican de forma efectiva y constructiva al equipo de desarrollo, este tendrá aún más cuidado en la calidad del código que lleva a producción.
Cómo sobrevivir a la Ley de Conway
Un buen primer paso para aplicar la Ley de Conway para nuestro propio beneficio sería dejar de ignorarla. El segundo —como apunta Martin Fowler— podría ser no luchar contra la misma.
El simple hecho de tener dos equipos en distintos pisos del mismo edificio ya impacta significativamente en la comunicación entre los mismos. Aún más si trabajan en distintas oficinas o poblaciones alejadas. En vez de continuar obviándolo, podemos asumirlo.
En el ejemplo que menciona Fowler7, la responsable técnica de un equipo que tenía que diseñar la arquitectura de un nuevo proyecto que iban a desarrollar 6 equipos diferentes en distintas ciudades por todo el mundo, decidió que iba a tener 6 subsistemas. Aún no sabía que iba a hacer cada uno, pero sí que iban a ser 6.
Otra opción, más extrema, es modelar la estructura de tu equipo y sus procesos de comunicación para que se adapten al tipo de productos o servicios que quieras desarrollar, lo que se conoce como Maniobra Inversa de Conway. Algo más fácil de decir que de hacer.
Conway y el trabajo remoto
Igual de estúpido que circunscribir la Ley de Conway a la industria informática sería pensar que solo aplica a las empresas que desarrollan un producto propio en vez de proporcionar un servicio a terceros, que las obligue a adaptarse a la estructura y procesos de sus clientes.
En realidad, siempre existe un núcleo organizativo y unos procesos de comunicación propios —parte de eso que, a veces, se llama «cultura»— que permanecen, independientemente de con quien se trabaje.
Da igual si nuestros clientes usan Scrum o Kaban. Si en nuestra empresa se comunica con total transparencia toda la información relacionada con el proyecto o la gestión de la cuenta, es muy probable que nuestro equipo encuentre nuevas oportunidades para aportar valor. Da igual si se organizan en equipos autónomos o en departamentos horizontales, si todos nuestros empleados saben lo que hacen sus compañeros y se comparten tanto los éxitos como las dificultades, es muy probable que nuestro grupo encuentre la forma de colaborar entre sí.
También sería bastante torpe usar el evidente impacto que tiene la ubicación para la comunicación cara a cara como argumento en contra del trabajo remoto. Precisamente, una de las ventajas del remoto es que permite que todos se comuniquen en igualdad de condiciones, independientemente de su ubicación. Solo tenemos que asegurarnos de que esas condiciones sean las mejores posibles.
Por el contrario, el remoto exige definir de forma explícita esos procesos de comunicación que tendrán una correlación directa con el trabajo que desarrollemos, según Conway, en vez de improvisarlos o asumir su diseño de forma implícita. Y, en el caso de que quisiéramos hacer una Maniobra Inversa de Conway, una organización completamente remota será mucho más adaptable que una distribuida en diferentes espacios físicos.
En cualquier caso, da igual que trabajemos de forma remota o presencial, desarrollando un producto o prestando servicios. Lo que Conway nos enseña a todos es que una de las mejores inversiones que una empresa puede hacer es asegurarse de que su comunicación interna se alinea con su misión y propósito. En 2023, la mayoría sigue viéndola como poco más que un gasto y un trámite molesto.
4 <https://assets.publishing.service.gov.uk/media/57a08da640f0b652dd001abc/Usability-issues-in-website-design.pdf>.
5 <https://www.semanticscholar.org/paper/The-influence-of-organizational-structure-on-Nagappan-Murphy/cc52bfc42571c3caa33f1348cc814ce168639837>.
...
