This text was generated using AI and might contain mistakes. Found a mistake? Edit at GitHub
When we talk about software architecture, we often focus on managing dependencies, creating abstractions, and organizing code into modules. But what if this entire approach is fundamentally flawed? In a thought-provoking discussion with James Coplien, a legendary figure in software engineering, we explore why traditional architecture thinking might be missing the point entirely.
The Problem with Dependency Management
The conventional wisdom tells us to reduce dependencies through abstraction layers, interfaces, and message buses. Yet Coplien challenges this premise directly: managing dependencies is a “doomed approach.” He points out that history repeatedly shows these strategies fail. The famous example of microservices — designed to be the epitome of independence — demonstrably don’t work. Such systems create hidden dependencies around code reuse, performance, and data consistency that abstractions cannot eliminate.
The real issue is that we’re trying to solve a problem that was relevant 40 years ago. When recompilation took weeks, minimizing dependencies mattered. Today, we chase the same patterns out of habit, not necessity. More problematically, we hide real dependencies behind abstractions, making systems harder to understand and change.
It’s About People, Not Code
Coplien advocates for a paradigm shift: instead of managing code dependencies, we should focus on building stable teams with deep domain knowledge. He references Peter Naur’s concept of “theory” — the team’s shared understanding of why the system works the way it does. This theory, built through long-term collaboration and learning, is the actual asset. The code? It’s a liability.
This explains why companies like Nintendo kept the same small team for 40 years building the Super Mario games. They developed profound domain knowledge and intuition about their problem space. When the team understands the system deeply, they can navigate complex dependencies intuitively, making informed changes without elaborate documentation or design tools.
The Real Architecture Question
True architecture, like building design, isn’t about walls and modules. It’s about creating space — the emergent features that result from how parts interact. Trying to hide these interactions behind abstractions creates more problems than it solves. Instead, we should embrace visible dependencies that reflect essential business complexity, not accidental technical choices.
The path forward requires organizations to prioritize team stability and domain expertise over maximizing productivity metrics. This flies against industry trends but aligns with what actually produces valuable software.
Conclusion
Software architecture isn’t fundamentally a technical problem — it’s a human and organizational one. Rather than obsessing over dependency graphs and design patterns, we should invest in building teams with deep knowledge, clear communication, and the stability to develop shared understanding over time. Code is temporary; the team’s collective theory is permanent.