Why Experts Struggle With Known Problems in Software Architecture

How past experience holds you back

That may sound counterintuitive, but solving new problems is often easier. You do research, think carefully, learn from experts, build a plan, and then implement a solution tailored to the challenge at hand.

Solving known problems, however, can be trickier. Especially for experts.

Humans tend to rely on intuition — a kind of pattern-matching mechanism that helps us save energy. When we first face a problem, we think hard, do research, and in the end come up with a solution. But the next time a similar issue arises, we sense a strong temptation to reuse a past solution. And if a solution has worked multiple times before, we apply it automatically.

We build an emotional attachment to the solution. It becomes our go-to choice, and we feel uncomfortable and even defensive when someone challenges it.

Don’t get me wrong, this intuition-based shortcut is not inherently bad. It allows us to do more during the day without decision paralysis. But it can become problematic in two cases:
– When the context changes
– When the scale or complexity grows significantly

Let’s take a closer look at both using Clean Architecture as a familiar example.

1. When the Context Changes: One Architecture Doesn’t Fit All

Clean Architecture is the de facto standard in mobile application development. I hear that all the time that engineers use Clean Architecture as a synonym for architecture, as if it’s the only way to build scalable and maintainable apps.

But is it always the right choice?

Often, we forget that a banking app, a calculator, a weather app, and a social network all have very different needs. We reach for Clean Architecture not because it’s optimal for the app or the team, but because it’s familiar. It’s the default choice, not necessarily the right choice.

I’m not against Clean Architecture. It’s a solid solution in many contexts. But it’s a complex framework, and applying it universally can be wasteful or even harmful. The maintenance cost grows when complexity is introduced too early — more boilerplate, more overhead, and more effort just to stay in sync.

Every project is different. Every team is different. Let the architecture reflect that.

So, what can we do?

2. When the Problem Is Complex: Split It Instead of Over-Engineering

When complexity is unavoidable, the answer is not to meet it with an even more complex solution. Too often, we respond to complexity by adding more structure, more patterns, more abstraction.

But what if, instead, we simplified the problem?

Start small. Break the big problem into a series of small, understandable ones. Simple problems need simple solutions. This gives you a few big advantages:

• You avoid the “creativity tax”. I’m a big fan of experimentation, always searching for what’s better and optimal for this particular project and team. Blindly applying solutions from previous projects wouldn’t allow you to discover what works best for this particular app and this team.
• You allow your app to guide you to what’s best. Robert Martin once introduced the idea of “screaming architecture” — the idea that when you look at a codebase, it should scream what kind of app it is. Whether it’s a banking app, a calculator, or a tic-tac-toe game, that should be immediately visible. A lifeless, overly generic architecture hides your app’s identity and doesn’t allow you to find creative solutions.

Of course, there will always be voices insisting that an app without Clean Architecture is unmaintainable spaghetti code. But if possible, propose an experiment: build without the boilerplate for two months, and see what’s actually missing. Most likely, you’ll notice that your code becomes simpler and even cleaner. You can always add complexity later, especially now, when refactoring is easier than ever thanks to modern AI tools.

3. Making Architecture a Living Decision

It’s not easy to change the architecture of a project. However, it also shouldn’t be a one-time choice you make on day one and carry like a burden for the rest of the project’s life. It’s a living decision, which sometimes you revisit, reshape, and evolve as your understanding of the problem deepens.

Your intuition will fail you if you decide to predict the future. The solution — you just need to stay open to it. When the app grows, when the team grows, when the complexity becomes real, try to simplify instead of blindly copying solutions that “big teams” are using.

About the author

Oleksandr Leushchenko is a GDE in Flutter and Dart, and a seasoned mobile developer with more than a decade of experience in building cross-platform mobile applications. He is a Senior Staff Engineer in a UK fintech company called Tide where he helps a team of 80+ engineers build an international financial services platform.

Russia started an unfair and cruel war against my country. If you found this article interesting or useful, please, donate to Ukraine’s Armed Forces. I can recommend my friends volunteers — the “Yellow Tape”, you can be 100% sure that the money will support our victory. Thanks in advance to everyone who participated.
Glory to Ukraine! 🇺🇦