[pfarrell]

Thought the exact same thing. Abstract early is not good in practice. You can't understand what problem you are solving until, as the last architect I worked with would say, n is 3. When you have three consumers of a feature, then you start to have an understanding of what the needs are.

To put it in another anecdote. I dealt with a SOAP api for a successful company that was purposefully designed to have no versioning. This meant that every decision that went into the API had to live forever and be backwards compatible with every decision that had ever come before.

This leads to the form of architecture I find to be the least useful. One where the architect tries to anticipate and solve all future problems. In my experience, this never leads to software that can grow or evolve. It's fine if you are solving a known problem and can set known boundaries around which your solution will never be applied. I, personally, have never encountered problems like that in the field.

[Chyzwar]

I agree. Good architecture is something that can naturally emerge. You start with a simple and less abstract solution and gradually evolve when requirements are better understood. Upfront design mostly does not work.