Conway's Law: when best practices aren't enough
summary
Conway's Law: how product structure and code reflect organizational communication and why good engineering practices alone don't prevent bad architecture. Presents concrete evidence (e.g., Windows Vista modularity, a 2008 Microsoft/University of Maryland study showing org structure predicts failures better than code coverage) and real failures (a consultancy site mirroring company hierarchy, a travel platform duplicating per‑country code). Advises concrete fixes: event storming, context mapping, Domain‑Driven Design, and Team Topologies/inverse Conway to align teams, interfaces and architecture.
AI-written summary · about
chapters (15)
- 0:00Dystopian introduction
- 1:36Education reform chaos
- 6:59Consulting firm problems
- 9:43Windows Vista failure
- 14:18Terrible software architecture
- 17:27Conway's Law explained
- 22:53Origins of Conway's Law
- 24:59Silos and poor communication
- 28:09SAFe and monolith limits
- 30:57Inverse Conway and DDD
- 34:29BAPO model limits
- 35:51Domain-Driven Design in practice
- 39:04Team Topologies for orgs
- 43:18Handling Conway effects
- 44:40Conclusion and limits
related talks
49mConway's Law: When Best Practices Are Not Enough
50mConway's Law: When Best Practices Are Not Enough
24mThe (too) Many Faces of Architecture
31mHow and Why to Design Your Teams for Modern Software Systems
39mConway’s Law and Sociology in Software Architecture
25mThe (too) Many Faces of Architecture
01h 02mThrough the Looking Glass
35mOrganization: A Tool for Software Architects