> Thus, if an organization is poorly-structured, it will produce poorly-structured software. Conway's law doesn't carry good or bad connotations for organizati

> Thus, if an organization is poorly-structured, it will produce poorly-structured software. Conway's law doesn't carry good or bad connotations for organizations or software, its simply a belief that software is designed first by managers writing down the org chart. There's three moving parts in Conway's Law: 1. The problem to be solved 2. The organization that will produce software to solve it 3. The software produced What Conway says is that organization structure is not a design neutral decision. So 'poorly structured' has to be evaluated in the context of the problem. Which, you, as a junior engineer, are the least qualified in the room to evaluate -- you've studied the problem space the least. In the years since Conway published in the 60s, we've seen a lot of industry changes. In his paper he states "there's always enough time do to it again, but never enough time to do it right," referring to the way teams would start from scratch for new clients. In today's marketplace, software is sold to multiple customers, and more often reused & improved over time. This leads to what some call "Conway's Nightmare" -- the software reflects not just today's org chart, but represents a mixture of all org charts ever. In general I don't think you can evaluate an org structure and make any prediction about software quality. Instead, you might be able to predict quality from how closely the org matches the software product. A team that doesn't match will have endemic communication problems, fix bugs slowly, and introduce new ones between components more often. And applying this to the modern era, the more often you reorg, the more tech debt you need to pay down.