How a beautiful software system becomes Frankenstein(softwarecreation.org)
softwarecreation.org
How a beautiful software system becomes Frankenstein
http://softwarecreation.org/2008/how-a-beautiful-software-system-becomes-frankenstein/
5 comments
This is known as Conway's Law. Communication problems in a development organization manifest in the designs it produces (an N programmer compiler team needs an N+1 pass compiler). There is also a great passage from "Soul of the Machine" where the Data General guys open up the Vax and see the computer hardware design replicates DEC's organizational structure.
http://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/03807...
from "How Do Committees Invent?" by Melvin E. Conway at http://www.melconway.com/research/committees.html
The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.
http://www.amazon.com/Soul-New-Machine-Tracy-Kidder/dp/03807...
from "How Do Committees Invent?" by Melvin E. Conway at http://www.melconway.com/research/committees.html
The basic thesis of this article is that organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations. We have seen that this fact has important implications for the management of system design. Primarily, we have found a criterion for the structuring of design organizations: a design effort should be organized according to the need for communication.
I think it could happen either way, but it's certainly best for the team to structure itself to the project.
Very insightful article. Interesting that he never mentions standards. Failure to adhere to standards is a BIG source of problems.
(Of course, the only good standards are the ones that I make.)
(Of course, the only good standards are the ones that I make.)
How a beautiful software system becomes "Dr.Frankenstein's monster"
Is that really true? Couldn't it be the other way around? If I am designing a module that doesn't talk to Bill's module, then I have no real need to communicate with Bill, right?
I'd guess it's more that the communication structure of an organization mirrors the structure of what they're designing.