Conway’s Law simply describes the natural gravity of software development teams and their systems.
Great summary there.
Over time I've come to think Conway's Law demonstrates a UX principle. Teams should be organized outside-in meaning from the use case(s) first. Conway's original observation was something like "if you have four teams working on creating a compiler you come out with a four-pass compiler." Of course nobody wants that. They want to compile their code, one pass. So you create one team from that one use case.
As for organization within an engineering team, there's some old research to suggest that the most productive team is one where there's one person who could build the entire thing that team needs to create alone, but instead works as a communication point between a number of actual implementers. I think that would naturally support the principle as well. If one person can keep the use case(s) in mind, then the problem is small enough for them to actually produce a solution.
Per the Agile Manifesto, "Working software" is the goal.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great summary there.
Over time I've come to think Conway's Law demonstrates a UX principle. Teams should be organized outside-in meaning from the use case(s) first. Conway's original observation was something like "if you have four teams working on creating a compiler you come out with a four-pass compiler." Of course nobody wants that. They want to compile their code, one pass. So you create one team from that one use case.
As for organization within an engineering team, there's some old research to suggest that the most productive team is one where there's one person who could build the entire thing that team needs to create alone, but instead works as a communication point between a number of actual implementers. I think that would naturally support the principle as well. If one person can keep the use case(s) in mind, then the problem is small enough for them to actually produce a solution.
Per the Agile Manifesto, "Working software" is the goal.