Physics, Engineering, and Architecture in Software Systems and the obsession with Architecture

 Something that has been bothering me for a while in the software industry is how disproportionately obsessed we became with architecture. Not engineering. Not systems. Not the underlying mechanics of computation itself. Architecture. You can see it everywhere. Developers spend endless amounts of time discussing microservices, event-driven systems, clean architecture, CQRS, service meshes, orchestration layers, domain boundaries, and abstractions on top of abstractions on top of abstractions. Entire teams can spend months debating the “correct” architectural shape of a system that barely has users yet. And the strange part is that most of these conversations happen completely disconnected from the actual physical realities of software. Because underneath all the diagrams and patterns, software is still constrained by physics. Memory access still has a cost. Network calls still take time. Cache misses still exist. Serialization still burns CPU cycles. Distributed systems are still ultimately bounded by latency and coordination overhead. A request traveling across five services is still fundamentally slower than a function call inside a process, regardless of how elegant the architecture diagram looks in a presentation. Physics does not care about our abstractions. That is why I think there is a meaningful distinction between physics, engineering, and architecture in software, and I increasingly feel that the industry approaches them in the wrong order. Physics comes first. Physics defines the immutable constraints of the system. The things you do not negotiate with. The speed of light is not a suggestion. Memory bandwidth is not a suggestion. Disk throughput is not a suggestion. The behavior of queues under load is not a suggestion. Eventually every sufficiently scaled system crashes into these realities whether the engineers understand them or not. Then comes engineering. Engineering is where trade-offs happen. It is the art of navigating constraints while balancing reliability, simplicity, scalability, cost, operational burden, and business reality. Good engineering is deeply pragmatic. It is not ideological. A good engineer understands that sometimes duplication is cheaper than abstraction, that sometimes a monolith is the correct solution, and that operational simplicity is often more valuable than theoretical elegance. Only after those two layers comes architecture. Architecture is important, but architecture is downstream from reality. It is the organizational shape that emerges from constraints and trade-offs. The problem is that the software industry often treats architecture as if it were the foundation instead of the consequence. I also think part of the confusion comes from the word “architecture” itself. In traditional architecture, like civil architecture, the architecture is actually part of the final product. The shape of the building matters. The aesthetics matter. The structure itself creates emotional and experiential value. A beautiful building is, in many ways, the product. Software is very different. The user almost never experiences the architecture directly. Nobody opens an application and says, “Wow, this system uses beautifully designed bounded contexts.” Nobody pays more because your internal services follow clean architectural principles. The customer experiences latency, reliability, usability, speed, stability, and features. They experience outcomes. The architecture is mostly an internal implementation detail. And I think this subtly changes the incentives in a dangerous way. In civil architecture, investing heavily in architectural beauty can directly improve the value of the thing being built. In software, architectural beauty often becomes something engineers are mostly creating for themselves. That does not mean architecture is useless. Internal structure absolutely matters. A badly organized system becomes impossible to evolve. But software architecture should exist to serve engineering goals, not the other way around. A beautifully architected system that is slow, fragile, expensive, and operationally painful is still a bad product. Sometimes I feel like the industry treats software architecture almost like an art form, when in reality it should behave more like infrastructure engineering. The goal is not to produce the most intellectually elegant internal structure possible. The goal is to produce systems that survive contact with reality. And I think that inversion explains why so many modern systems feel overbuilt. A lot of developers learn architecture before they learn engineering. They learn patterns before they learn systems. They learn frameworks before they learn operating systems, networking, databases, memory behavior, or performance analysis. They become fluent in abstraction without becoming fluent in constraints. As a result, many systems are optimized for conceptual purity instead of practical effectiveness. They look beautiful in diagrams and become nightmares in production. Every layer introduces another retry policy, another queue, another serialization format, another network hop, another operational dependency, another failure mode. Complexity grows geometrically while the actual business problem often remains embarrassingly simple. At some point, especially at scale, software stops feeling like pure abstraction and starts feeling closer to applied physics. The engineers who build high-performance databases, trading systems, browsers, operating systems, rendering engines, or globally distributed infrastructure tend to understand this instinctively. They think in terms of latency, throughput, contention, scheduling, probability, cache locality, and resource allocation. They understand that every abstraction leaks eventually because underneath every abstraction there is still a machine doing work. And I think that mindset is becoming increasingly rare in mainstream software culture. We became extremely good at discussing the shape of systems while becoming strangely disconnected from the forces acting underneath them. The industry rewards architectural sophistication far more visibly than engineering restraint. Adding complexity often looks impressive. Removing complexity often looks invisible, even when it is the harder and more valuable work. But the longer I work on systems, the more I feel that the best engineering usually looks deceptively simple from the outside. Not because the problems are simple, but because the people building them deeply understand the underlying constraints well enough to avoid unnecessary complexity in the first place. Maybe that is the real difference. Physics defines the limits. Engineering navigates the trade-offs. Architecture is merely the shape left behind. Software is still bound by reality. Rodrigo Vidal