Uploaded December 2019 | Updated September 2026, 3 weeks ago
Software projects often mistake organizational problems for technical issues and treat the symptoms instead of the root cause. The main reason is that the organization that builds the system is invisible in our code. From code alone, we cannot tell if a module is a productivity bottleneck for five different teams, or whether our microservice boundaries support the way our codebase evolves or not. This session closes that gap by taking a behavioral view of version-control data combined with insights from social psychology to measure aspects of software development that we haven't been able to capture before. You learn how this information lets you detect modules with excess coordination needs, measure how well your architecture supports your organization, suggest and guide refactorings, as well as why Conway's law is an oversimplification. To make it specific, each point is illustrated with a case study from a real-world codebase.
Software projects often mistake organizational problems for technical issues and treat the symptoms instead of the root cause. The main reason is that the organization that builds the system is invisible in our code. From code alone, we cannot tell if a module is a productivity bottleneck for five different teams, or whether our microservice boundaries support the way our codebase evolves or not. This session closes that gap by taking a behavioral view of version-control data combined with insights from social psychology to measure aspects of software development that we haven't been able to capture before. You learn how this information lets you detect modules with excess coordination needs, measure how well your architecture supports your organization, suggest and guide refactorings, as well as why Conway's law is an oversimplification. To make it specific, each point is illustrated with a case study from a real-world codebase.
