Over engineering is the result when you focus too much on “future” needs.

And under-engineering is the result when you don't sit down at the beginning of the project and plan for the known scope and requirements of that project. They are both bad ways to go about it. So, like the title says: "just enough", so not more, but also not less.

It also doesn't always have to be a dedicated architect in a proverbial ivory tower. It can be an informal meeting of developers around a whiteboard. Don't get scared by the word "architecture".

While I agree that under-engineering can be a problem, it's generally very easy to fix by doing what's now clearly identified as missing/needed. Fixing over-engineering is always a nightmare and rarely a success.

IHMO the experience, the pragmatism and the soft skills needed for a successful/productive informal architectural meeting are too rare for this solution to work consistently.

Personally I've abandoned all hope and interest in software architecture, while on paper it makes a lot of sense, in practice (at least in what I do) it just enables way too many people to throw imaginary problems in the mix, distracting everyone from what matters with something that may eventually be a concern once/if a system hits a top-1% level of criticality/scale.

> throw imaginary problems in the mix

Yes, this happens too easily. It's the crux of Ward Cunningham's original observation on tech debt discussed recently [1]. He basically said: all of you thinking you can use waterfall to figure it all out up front are deluded. By getting started right away, you make mistakes and you avoid working on non-problems. I can fix the mistakes with refactoring but you can't ever get your time back.

Most teams live in his world now. Few do too much up-front design, most suffer from piled up tech debt.

I hope you give architecture another chance. Focus on the abstractions themselves [2] and divorce that from the process and team roles [3].

[1] https://news.ycombinator.com/item?id=40616966#40624446

[2] Software Architecture is a Set of Abstractions, George Fairbanks, IEEE Software July 2023. https://www.computer.org/csdl/magazine/so/2023/04/10176187/1...

[3] JESA section 1.5, https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft... "Job titles, development processes, and engineering artifacts are separable, so it is important to avoid conflating the job title “architect,” the process of architecting a system, and the engineering artifact that is the software architecture."

In my own gut, I have a sense of the right amount of time to spend on design. Assume (falsely) for a moment that I'm right: How can I transfer that gut sense to you or anyone? Chapter 3 of the book is my attempt to share that gut feel [3].

Even if you clone us, our gut feel doesn't transfer to our clones. So, we can recognize under- and over-engineering in our guts, but how can we help someone else? Is there a better way than the risk-driven model?

  1. Identify and prioritize risks
  2. Select and apply a set of techniques
  3. Evaluate risk reduction

[1] JESA Chapter 3: Risk-Driven Model. https://www.georgefairbanks.com/assets/jesa/Just_Enough_Soft...

It's not always a balancing act, it implies that everything has a good side and you just need to know what to focus on.

It's not true, there are architectures that are a waste of time today, and a waste of time in 5 years, too.

If that architecture has no value in any circumstances at the beginning of a project and no value once the code base has matured, it’s an anti pattern.

Most devs / architects which initially designed the system then to not stick around and find out if what they did actually worked.

Pre-mature optimization and over-engineering are a greater issue than the opposite.

Generally, clever architecture at the right stages can beat clever code and leave flexibility to pivot.