The software architect who memorizes patterns and the one who understands the principles behind them deliver completely different results. The difference between the two is the same as the one separating a football coach who copies formations from one who understands the game. And this difference has a name: first principles thinking.
The coach who copies and the coach who understands
In football, there’s a type of coach who sees Guardiola’s 4-3-3 working at Manchester City and decides to apply the same formation to his team. He places players in positions, draws the pitch on the whiteboard, and waits for results to appear. When it doesn’t work (and it almost never works), it’s the players’ fault, the pitch’s fault, the schedule’s fault. Never the decision.
The other type of coach understands why the 4-3-3 works in that specific context. He understands that Guardiola has fullbacks who play as midfielders, a defensive midfielder who drops back as a center-back, and forwards who constantly swap positions. The formation is a consequence of a playing model, not the playing model itself. And when this coach builds his own, he starts from the squad he has, the league he plays in, the characteristics of his players. And arrives at a formation that makes sense for that context.
Software architecture works exactly the same way.
First principles: the bare minimum
First principles is a mental model. The idea is simple: break down a problem until you reach fundamental truths and rebuild your reasoning from there. Without inheriting assumptions, without carrying over suppositions from contexts that aren’t yours.
Most people reason by analogy. “Netflix uses microservices and it works well, so let’s use microservices.” That’s pure analogy. Reasoning by first principles would be: what are the real requirements of my system? How big is my team? What’s my organization’s operational maturity? What trade-offs am I willing to accept? And from those answers, arrive at the architecture.
Elon Musk did this at SpaceX. The market said a rocket cost 65 million dollars. Instead of accepting it, he decomposed the rocket into raw materials and discovered that material costs represented about 2% of the final price. The rest was accumulated inefficiency and assumptions nobody questioned. The first principle wasn’t “rockets are expensive.” It was “rockets are made of materials that cost X, and everything beyond that is an engineering decision.”
Image generated by Nano Banana Pro
The architect who applies patterns
There’s a profile of architect I come across in almost every project: the one who collects patterns like trading cards. Knows all their names, draws the diagrams, cites the right books in the right forums. But when it’s time to justify why he chose a particular approach, the answer is some variation of “it’s what the market uses” or “I saw it in a case study from company X.”
This is the architect who reasons by analogy. He takes a solution that worked in another context and transplants it into his own, without decomposing the problem. He’s the coach who copies Guardiola’s formation without having Guardiola’s squad.
The result is predictable: microservices where a monolith would suffice, event-driven architecture where a synchronous call would do, Kubernetes to run two instances of an API. Accidental complexity born not from a real requirement, but from a decision based on the wrong reference.
Mark Richards and Neal Ford, in Fundamentals of Software Architecture, make a point that should be tattooed on every engineering team’s wall: architecture is about trade-offs. Every architectural decision has a cost. The architect’s job is to understand that cost before making the decision, not after, when the system is already in production and the entire team is paying for a choice nobody questioned.
In my experience, most architectural problems I find in projects don’t come from technical limitations. They come from decisions made by analogy. Someone read a post, watched a talk, saw a nice diagram on a slide. And adopted it without decomposing whether it made sense for the actual context. The coach copied the formation.
The architect who thinks from first principles
The architect who thinks from first principles takes the opposite path. Instead of starting from the solution, he starts from the problem. He decomposes requirements until reaching the real constraints of the system: performance, availability, consistency, operational cost, team size, deadline. And from those constraints, builds the architecture.
When someone suggests “let’s use CQRS,” his first reaction isn’t to evaluate whether it’s a good pattern. It’s to ask: do we have a read volume significantly different from write volume? Does the read model need to be different from the write model? Does the additional complexity justify the real gain we’ll get? If the answer is no, CQRS is over-engineering, regardless of how many large companies use it. If it’s yes, then it makes sense. And it makes sense because the reasoning started from the problem, not from the pattern.
Richards and Ford insist on this point in Software Architecture: The Hard Parts: the most important decisions in architecture are precisely those involving trade-offs between competing architectural characteristics. There is no silver bullet. Every choice favors something and sacrifices something else. The architect who thinks from first principles knows exactly what he’s sacrificing and why. The one who applies patterns often doesn’t even know he’s sacrificing anything.
I can tell you the difference is visible in design review meetings. The architect who started from first principles can defend every decision with a logical chain going from requirement to pattern. The one who copied a reference gets stuck when someone asks “what if we don’t need this?”
In practice: three questions before any decision
Thinking from first principles isn’t a philosophical exercise. It’s a practice built through deliberate questions. Before adopting any pattern or technology, three questions cut most bad decisions:
What problem am I solving? Not what problem the pattern solves in general, but what concrete problem exists in my system, with my requirements, with my team. If you can’t articulate the problem clearly, you’re not ready to choose the solution. It’s like the coach who can’t explain why he’s playing with three center-backs, he probably shouldn’t be playing with three center-backs.
What are the trade-offs? Nothing is free. Microservices buy deploy independence and pay with operational complexity. With event-driven architecture, you gain decoupling, but when an event gets lost across five services, good luck debugging. If you don’t know what you’re paying, you’re making the decision in the dark.
Does this work for my context? The case study from a big tech company with thousands of engineers and virtually unlimited budget doesn’t apply to a 15-person startup. It seems obvious, but the number of projects that adopt planetary-scale architectures to serve hundreds of requests per minute is staggering. A Novorizontino coach doesn’t have Real Madrid’s squad, and there’s no point playing as if he did.
Image generated by Nano Banana Pro
Now, an honest warning: first principles isn’t for every decision. If you need to choose between two logging frameworks, you don’t need to decompose the problem down to thermodynamics. There’s a real risk of analysis paralysis, endlessly deconstructing when the decision has low impact and is easily reversible. The point is knowing when the decision deserves that decomposition and when a pragmatic choice is enough. In the vast majority of cases, the effort is justified for structural decisions, those that are expensive to reverse and will define the system’s path for months or years.
Back to the pitch
Guardiola didn’t invent the 4-3-3. But he understands the game at a level that allows him to adapt any formation to the context. At Barcelona, with Messi, Xavi, and Iniesta, he created the tiki-taka that revolutionized football. At Bayern, he adapted the style to German football, more vertical, more physical. At Manchester City, he built yet another completely different team and kept winning. Because his principle was never the formation. The principle is the playing model: ball possession, numerical superiority, high pressing. The formation is just the current implementation.
In software architecture, the principle isn’t the pattern. The principle is the set of requirements, constraints, and trade-offs of your system. The pattern is the implementation. And implementations change. In fact, they should change when the context changes.
The architect who understands this doesn’t become hostage to a technology or a hype cycle. He solves problems. And when the context changes, and it always changes, he adapts, because his reasoning starts from fundamentals, not from references.
If you want to develop this, I recommend a concrete exercise: take the next architectural decision you need to make and, before researching which pattern to use, write down the real constraints of your system. What needs to scale? What needs to be consistent? Where does the team have maturity and where doesn’t it? Only after having those answers, go after the pattern. I guarantee the decision will be different. And better.
Stop copying formations. Understand the game.