Conway's Law and Separation of Concerns in Web Development

Conway's Law, which states that software systems tend to mirror the communication structures of the organizations that build them, plays a crucial role in the way modern web development is structured. The evolution from early practices to today’s more complex systems, like micro-frontends and component-based architectures, has been largely shaped by this principle. By looking at how concerns were historically separated in web development, we can better understand how current practices emerged and why they look the way they do today.

In the early days of web development, different teams were often responsible for specific technologies. One team handled the HTML, another was in charge of CSS, and yet another team took care of JavaScript and server-side logic, such as PHP. This clear separation of responsibilities, or "separation of concerns," was driven by the distinct skills each team possessed. Designers would hand over pixel-perfect Photoshop files to one team, who would then turn those into HTML and CSS templates. Once the templates were done, the next team would integrate them into the app, often encountering friction when things didn’t fit perfectly.

A designer might deliver a .psd file with all nine corners of a table meticulously designed, and the HTML/CSS team would slice it into a working layout. But they were largely disconnected from the app's actual logic or user interactions. Their job was just to make sure the visuals worked. The backend team, dealing with PHP and JavaScript, would then integrate these static templates into the functioning app, often finding the solutions presented by the earlier teams weren’t ideal for the application’s needs. This was a reflection of how organizations were structured, with each team owning a different part of the process without much cross-communication.

The Shift to Component-based Architecture

Today, the way we separate concerns has changed dramatically. Instead of splitting responsibilities by technology—such as one team for HTML and CSS, and another for JavaScript and PHP—modern teams are more likely to be responsible for the entire stack of specific parts of the application. Each team typically owns a vertical slice of the application, including everything from frontend components to backend logic. This shift is driven by the rise of component-based architectures, where reusable, self-contained components are the building blocks of the system.

For example, instead of one team focusing on all the HTML and CSS across the entire site, and another team handling the JavaScript and server-side integration, you now have teams that are responsible for distinct features or components, such as <Article>, <ChatWidget>, or <MainLayout>. Each team manages their component or part of the application from top to bottom, including both the frontend and backend logic. This allows teams to work more autonomously, reducing bottlenecks and miscommunication that often occurred in the old separation model.

This new separation of concerns, by feature or component rather than by technology, allows teams to iterate faster. A team responsible for a chat widget, for example, can implement changes to both the UI and the backend API without waiting for another team to handle one part of the system. The key difference now is that instead of having specialized teams focused only on HTML or JavaScript, you have cross-functional teams that take ownership of their components or features in their entirety.

Micro-frontends and Independent Team Ownership

One of the most significant results of this shift is the rise of micro-frontends, where different teams own different parts of the frontend, just as they own parts of the backend. This allows for a level of independence that wasn’t possible in the early days. A micro-frontend architecture mirrors the independence teams now have in managing their components.

For example, a team responsible for <MainLayout> might own everything from the UI structure to how it interacts with the data fetched from APIs. Another team responsible for <Article> will have full control over how articles are fetched, rendered, and interacted with, from frontend logic to database queries. This level of autonomy means that changes can be deployed independently, without needing to coordinate with other teams as much as in the past.

In contrast, in the old HTML+CSS vs. JS+PHP separation model, changes to any part of the system required coordination between multiple teams. If the frontend needed a new feature, the HTML/CSS team would have to work with the JavaScript team to ensure the new layout or functionality worked as intended. Today, with teams owning specific components or features from top to bottom, this need for inter-team coordination is greatly reduced, allowing for more rapid development and deployment cycles.

Conway's Law in Action

Conway’s Law remains as relevant as ever. The way we build software today still reflects the way our teams are organized, but the difference is that modern team structures are more feature-focused and less technology-siloed. The old method of splitting responsibilities by technology (HTML+CSS vs. JS+PHP) has given way to a model where each team is responsible for a complete feature or component.

This modern separation of concerns allows for better communication within teams and more focused ownership. Micro-frontends, component-based architectures, and feature-focused teams are all reflections of Conway’s insight: that your software will inevitably reflect the structure of your team. As our team structures evolve, so too do the systems we build, becoming more flexible, modular, and independent.

Conclusion

The shift from technology-based separation of concerns to feature-based separation has revolutionized how we build web applications. Conway's Law explains why this evolution happened: as teams have become more autonomous and feature-focused, the architecture of our systems has followed suit. Micro-frontends, internal component libraries, and component-based development all reflect the modern need for independent, cross-functional teams that own both the frontend and backend of their specific features or components.

While the tools and frameworks have evolved, the fundamental principle remains the same: the way teams are structured directly influences the software they build. By understanding Conway’s Law and the history of separation of concerns, we can better appreciate the systems we work with today and anticipate how they might continue to evolve.