3 ms·

How do Committees Invent? (1968) [pdf]

37 points by arkj 5y ago

drallison 5y ago
Back when figuring out software engineering and systems design was all the rage, Mel Conway's paper was a fave. His observation--that system designs tend to mimic the social structure of the development team--was critical when it came to understanding systems and their development. Now, I suspect that, 52 years later, the observation (based upon longitudinal studies) still holds and that the ways committees invent are still not understood. Mel wrote an influential paper on coroutines and compilers, "Design of a Separable Transition-diagram Compiler", which included the first published explanation of the concept proposed organizing a compiler as a set of coroutines. Several compilers based upon his approach were built in the early 1970s at SRI and at consulting firm Polymorphic. Mel also applied for and received US Patent 6272622, Dataflow Processing With Events, which expired in 2019. The patent is very broad and insightful.
- cryptonector 5y ago
  A great example of Conway's law is Active Directory. Someone at Microsoft figured out that they needed a) new authentication technology (Kerberos, which was new in the sense of "better than NTLM"), b) a general-purpose directory that (a) could use, c) also a general-purpose directory that could be used to serve DNS. What's surprising is that this then led MSFT to create a team to do all three things rather than have disparate, far-flung teams to do it. AD was a huge reason for MSFT's success in the oughts, and still is. The competition completely failed to see the advantage of that approach, and so failed to compete. At Sun Microsystems, for example, the directory server team was very far-flung from the Solaris Security team that owned Kerberos support, and neither had anything to do with DNS in any Sun products, and Sun never did anything about that in part because Solaris was seen as a cost center while the Directory Server product was seen as a profit center.
fuzzfactor 5y ago
>How do Committees Invent? In many different ways throughout this seminal paper, he seems to be saying they don't. An important enough question raised by Conway's Law to merit the title of the piece. "To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces." "The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon." Or maybe he is saying good luck, you've got me and pleading for help. "philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence." in his final sentence.
iamwil 5y ago
Funny, just watched Casey Muratori cover the same topic on his channel: https://youtu.be/5IUj1EZwpJY?t=699 https://youtu.be/5IUj1EZwpJY?t=699 I thought he covered it well. He considered the temporal aspect of orgs, which meant that software, over the years not only mimic the org, but every org that had ever been there over time. edit: oh, and unexpectedly, he's still around and on twitter. https://twitter.com/conways_law https://twitter.com/conways_law
- deleted 5y ago
  [deleted]
jadbox 5y ago
The only way to reduce complexity in a long running project is: - diligence to propoerly research the domain and provide defined solution(s) - leadership with courage to make the right choice that may have risk - comittment from stakeholders to fund the scope of the initiative - the team's grit to see projects through to the end (and not leave things half-refactored) If any of the above breaks down, you get the problem of half-baked solutions that only end up making things worse by adding additional complexity.

37 points by arkj 5y ago

Back when figuring out software engineering and systems design was all the rage, Mel Conway's paper was a fave. His observation--that system designs tend to mimic the social structure of the development team--was critical when it came to understanding systems and their development. Now, I suspect that, 52 years later, the observation (based upon longitudinal studies) still holds and that the ways committees invent are still not understood. Mel wrote an influential paper on coroutines and compilers, "Design of a Separable Transition-diagram Compiler", which included the first published explanation of the concept proposed organizing a compiler as a set of coroutines. Several compilers based upon his approach were built in the early 1970s at SRI and at consulting firm Polymorphic. Mel also applied for and received US Patent 6272622, Dataflow Processing With Events, which expired in 2019. The patent is very broad and insightful.

cryptonector 5y ago
A great example of Conway's law is Active Directory. Someone at Microsoft figured out that they needed a) new authentication technology (Kerberos, which was new in the sense of "better than NTLM"), b) a general-purpose directory that (a) could use, c) also a general-purpose directory that could be used to serve DNS. What's surprising is that this then led MSFT to create a team to do all three things rather than have disparate, far-flung teams to do it. AD was a huge reason for MSFT's success in the oughts, and still is. The competition completely failed to see the advantage of that approach, and so failed to compete. At Sun Microsystems, for example, the directory server team was very far-flung from the Solaris Security team that owned Kerberos support, and neither had anything to do with DNS in any Sun products, and Sun never did anything about that in part because Solaris was seen as a cost center while the Directory Server product was seen as a profit center.

fuzzfactor 5y ago

>How do Committees Invent? In many different ways throughout this seminal paper, he seems to be saying they don't. An important enough question raised by Conway's Law to merit the title of the piece. "To the extent that an organization is not completely flexible in its communication structure, that organization will stamp out an image of itself in every design it produces." "The larger an organization is, the less flexibility it has and the more pronounced is the phenomenon." Or maybe he is saying good luck, you've got me and pleading for help. "philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence." in his final sentence.

iamwil 5y ago

Funny, just watched Casey Muratori cover the same topic on his channel: https://youtu.be/5IUj1EZwpJY?t=699 https://youtu.be/5IUj1EZwpJY?t=699 I thought he covered it well. He considered the temporal aspect of orgs, which meant that software, over the years not only mimic the org, but every org that had ever been there over time. edit: oh, and unexpectedly, he's still around and on twitter. https://twitter.com/conways_law https://twitter.com/conways_law

deleted 5y ago
[deleted]

jadbox 5y ago

The only way to reduce complexity in a long running project is: - diligence to propoerly research the domain and provide defined solution(s) - leadership with courage to make the right choice that may have risk - comittment from stakeholders to fund the scope of the initiative - the team's grit to see projects through to the end (and not leave things half-refactored) If any of the above breaks down, you get the problem of half-baked solutions that only end up making things worse by adding additional complexity.