Hi lmm, perhaps the world "architecture" has bad associations for you that I don't intend to imply. If you code anything non-trivial, you are doing architecture whether you like it or not. The only question is how well you do it.
Over-engineering is a real danger, to be sure, and terrible ideas can by justified in the name of "architecture," just as they can in the name of YAGNI.
Fwiw, I have personally seen costly decisions made in the name of YAGNI, literally. So I don't think it is the essentially "safer" default.
My view is that you can't always wish away complexity with heuristics. Often, you have to think through your special situation, weigh the factors, and make tough judgment calls without knowing if they'll be right.
I'd be interested to hear the specifics, or examples of the kind of "architectural decision" you're talking about. Let me tell my story of how architecture went wrong:
* We defined the data structures early on in a generic way, when we thought we were building a product for multiple regions. In fact we tried two regions and discovered it only sold in one of them, so we were producing a product that only actually needed to support a single region, with a massively overengineered generic data structure
* We defined component boundaries, saying that certain functions would live in certain modules. In fact these were not the correct boundaries, and simple operations involve several rounds of back and forth, exacerbated by:
* We built a "SOA" style system with multiple components on the grounds that we would need horizontal scalability. We never got to the level where we needed that kind of scale, and the architecture massively slowed down development/debugging.
* We decided that certain interfaces would use Java datatypes because we thought the system would primarily be written in Java. As we built the system it became clear that Scala was a better choice for many components, so we ended up with a lot of code that was converting scala objects to java just to send them through an interface, and then the system on the other side was converting them back to scala objects.
* We tried to make a choice of RPC system early on. We ultimately went through three iterations of different RPC systems, as the various approaches failed.
You could say these are just wrong choices, and there's an element of this. But I think in all of these cases we'd have made the correct decision had we been driven by use cases (YAGNI style) and deferred making decisions until we actually needed them.
Over-engineering is a real danger, to be sure, and terrible ideas can by justified in the name of "architecture," just as they can in the name of YAGNI.
Fwiw, I have personally seen costly decisions made in the name of YAGNI, literally. So I don't think it is the essentially "safer" default.
My view is that you can't always wish away complexity with heuristics. Often, you have to think through your special situation, weigh the factors, and make tough judgment calls without knowing if they'll be right.