People ask questions about architecture and reason about it even before asking what software they are building, what goal they are trying to achieve, and what metrics they will use to measure success.

It’s the same as asking about ingredients before even looking at a dish or tasting it. One person says there is too much salt, another says there is too much sugar.

Without overgeneralizing, I can clearly describe a syndrome among developers who treat architecture patterns as the yardstick for everything — as the measure of all things.

One developer declares MVVM the best architecture, backed by an argument from authority. Another rejects everything except their favorite pattern (MVC, VIPER, MVP, TCA, CIRCUIT, RIB, MVI, MVU), giving “valid” reasons the way a chef explains why pepper ruins a dessert.

Even when someone considers all aspects of their setup — their challenges and resources (human, time, technological) — and chooses an architecture, it’s unclear whether they succeeded or failed.

If they succeed, they brag about it, praising their solution as the ultimate pill.

If they fail, they blame the developers, the tight deadlines, ambiguous business requirements, or the technology.

There is no scientific way to reproduce the result — not only because environments differ, but also because there are no metrics that allow comparison.

But wait. Do we really need to reproduce the result? Didn’t we just fall into the rabbit hole again?

“Far west, across the sea, there is a land called Vinland. It’s warm and fertile. A faraway land where the flames of architecture wars never reached.”

Are we truly seeing beyond architectures — toward software development free from holy wars, blind worship, and cargo cults?

Many years ago, when I first had control over a project with multiple feature teams working on it, I was excited and already knew how I wanted to improve it. I knew what libraries, what approaches, and of course what architecture I was going to apply.

Chapter 1: Nobody measures it.

I don’t clearly recall whether I was a middle or senior developer, since those titles are vague and often overlap. I had my favorite libraries and approaches and knew exactly when to apply them.

After working on a project for a week or two, I could easily find the “weak points” of the existing architecture and declare:
“Code smells. We need refactoring. We can’t work with this.”
If there were a lot of closures, someone might say RxSwift is the best solution. If there was reactiveness, someone else would say:
“Oh, those idiots didn’t know how to use it. Reactiveness is everywhere, but the implementation is wrong. They’re shooting themselves in the foot.”
Then they would replace it with Closures.

Always same story. Always same statement: “If we continue, we will stuck in development. This architecture is not scalable, testable. We need refactoring.“

I could confidently say in interviews:
“MVC is bad because of Massive View Controllers,”
or
“When the team is big, use VIPER; when small, use MVVM.”

When tasks were assigned, I was the one who could start quickly and finish fast. I was the best performer. But… we had a lot of bugs. I fixed them quickly, yet new ones kept appearing — cut off one head of the monster, two more grew. PO, Scrum Master, and teammates couldn’t identify the root cause. Sometimes it was me, sometimes backend, sometimes unclear business requirements. It was “normal.” Nobody measured anything.

Looking back, I can say I had too many library initializers in didFinishLaunchingWithOptions, too many data fetches during app launch, hitches and hangs, ever-increasing app size, and circular dependencies leading to memory leaks.

But these issues were not fatal. In fact, based on Survivorship bias, they often didn’t prevent success. I’ve worked on many successful apps — profitable, growing, expanding — whose technical implementations were far from perfect.

That’s why I always stick to the Pareto law:
80% of refactoring leads to only 20% real improvement.

And the lesson is a question: “What are your metrics?”

Developers use architecture as a metric, but it isn’t. If you think for a moment, you’ll see how many biases we carry.

“Massive View Controller” — some say it’s about the number of lines. But you’ll find non-MVC files with even more lines. Others say the problem is violating SOLID principles. And yet others argue that you shouldn’t be too religious about SOLID, and some principles are misunderstood (even Uncle Bob confirms this).

Before falling into the rabbit hole again, ask:
“What are your metrics?”
You’ll soon find that none of the above are true metrics.

There are many real metrics:
Lines of code, code coverage, mutation index, time per task type, compile time of a file, full build time, test duration, app launch time, app size, number of specific bug types, hitches and hangs (count and duration), memory consumption, etc.

It sounds obvious, but people forget:
metrics must be measurable.

Refactoring must have a clear goal:
“Our current situation is X, our goal is Y. It’s important because {link the technical metrics to business need}.”

This way, 20% of refactoring brings 80% real change.

If we eliminate metrics and make decisions based on emotion or politics, we end up treating irrelevant things — architecture, frameworks, tools, languages — as “metrics.”

They say: “You get what you measure.”

We should face the truth — even if everyone else goes crazy.
That, my friends, is conscious engineering.

Chapter 2: It doesn’t matter.

When I analyzed software delivery and operational performance across different projects I’ve worked on, it turned out:

Architecture doesn’t matter at all.

One can pick any architecture — or none at all — or many in the same app. MVC, MVVM, VIPER — it doesn’t matter.

With AI and developers’ ability to copy/paste existing patterns, architecture becomes fragile.

Teams often work “on autopilot.” They follow patterns without asking “why.”Architecture becomes habit, not strategy.

You’ll find logic where it shouldn’t be. You’ll find new patterns that contradict the existing architecture because a new use case needs a new solution.

We’ve all been there: you need to implement something, but there’s no example or reference to copy or learn from.

If the person who designed the architecture is still around, there are two options:

1. Extend the existing architecture to support the new case.
2. Modify the architecture to create a perfect place for the new case.

Both are fine. They’re just efforts to remain consistent.

I once read:
“It doesn’t matter what the architecture is, as long as it’s consistent.”

I agree only with the first part: “it doesn’t matter.”
Because consistency doesn’t help if the architecture doesn’t solve the problems it was designed for.

There can be one architecture per feature.
Have you ever tried building a white-label super-app with Telegram-like chats, Instagram-like stories, TikTok-like videos, Facebook-like feeds, YouTube-like videos, Stripe-like wallet? I have — and there was more than one architecture.

Because consistency doesn’t matter. Architecture doesn’t matter.

So what does matter?

Chapter 3: The Early Feedback Loop Problem.

In almost every WWDC session about performance, user experience, or debugging, you’ll hear about the feedback loop. And it is the key to everything you write in your code.

Once, a developer in my company introduced a new design pattern to solve a problem while implementing a feature. He opened a PR. But here’s the thing: I’ve added around 100 comments. I said:
“You could’ve saved a lot of time and energy if we discussed your solution before writing code.”

That’s late feedback.

Listen:
One can work with the worst architecture, but if it compiles fast and developers can deliver features quickly, it’s a good architecture.
If it’s the “best architecture in the world” but newcomers struggle and no one can help — they get stuck — it’s a bad architecture.

Why?
Because of the feedback loop.
Because we build products for users.
Because nobody cares about an architecture.

When a user reports a critical bug — it’s already late.
When QA finds it — late.
When a PR review reveals an invalid state — late.
When you notice strange behavior on a device or on a simulator — late.

When tests fail — fine.
When the compiler errors — perfect.
When you eliminate invalid states during the “solutioning” phase before writing code — amazing.

Your architecture must shorten the feedback loop.
The shorter the loop, the better the architecture.
If you catch issues instantly during a task discussion, your architecture is ideal.
If users discover bugs after release — it’s the worst architecture possible.

If you can’t explain your implementation to a kid — even with the best architecture — you lose.

That’s why the “write-read” tradeoff matters.

But in perfect architecture there is no tradeoff.
The developer who cuts the feedback loop writes code that’s easy to read.
Because the mental model is already complete — code merely reflects it.
That’s why we write in programming languages: transforming human logic into machine logic.

Chapter 4: It’s not about architecture. It was never.

When people talk about architecture, they talk about design patterns — predefined solutions to typical tasks. I call this “unconscious engineering.”

There’s nothing wrong with it. It’s natural not to question something the team already agreed on. It’s like brushing your teeth — you do it automatically. That’s why we all converge toward some version of “architecture.” It’s a map, a shelf where things have labels and places. It enables teams.

But usually architecture is always a consequence of circumstances.

Take Conway’s Law:

Conway’s Law is a principle that states organizations will design systems that mirror their own communication structures.

Architectures are doomed to have long feedback loops if nobody questions them.
Not because of the architecture itself, but because of the unconsciousness around it.

If communication problems cause long feedback loops — and nobody addresses them — your architecture is already doomed.

The true cause of “bad architecture” is rarely the pattern itself — it’s almost always communication, team structure, and missing feedback, not the code.

It’s not about code. It never was.

TLDR;

• Nobody measures whether an architecture is good or bad.
• Over time, good architecture becomes bad under new conditions.
• Without metrics, 80% of refactoring results in only 20% real improvement.
• With metrics, 20% of refactoring results in 80% real improvement.
• Architecture doesn’t matter. Consistency doesn’t matter.
• Good or bad depends on the metrics you choose.
• Feedback loop matters.
• Good architecture shortens the loop; bad architecture lengthens it.
• Conscious engineering requires questioning, measuring, and keeping your hand on metrics.
• Unconscious engineering leads to doomed architectures.

An Architecture Is Not a Metric was originally published in Conscious Engineering 🌊 on Medium, where people are continuing the conversation by highlighting and responding to this story.