Yes, absolutely. I had an experience where the design was dictated by an architect who cared more about the theoretical and having UML diagrams looking nice than about actual business requirements and having the code be lean, clean, simple and efficient.
TDD and also code analysis tools can help highlight what you actually need and what you don't.
The converse is true too, if you under-engineer you run the risk of not easily being able to scale up to new requirements.
Over-engineering creates an albatross where you'll fall under your own weight (too much code, slows down development, possibly bad performance, harder to debug).
Under-engineering creates a house of cards that is fragile (more buggy, code gets duplicated and patched on, frustrating to work on, hard to refactor).
TDD and also code analysis tools can help highlight what you actually need and what you don't.
The converse is true too, if you under-engineer you run the risk of not easily being able to scale up to new requirements.
Over-engineering creates an albatross where you'll fall under your own weight (too much code, slows down development, possibly bad performance, harder to debug). Under-engineering creates a house of cards that is fragile (more buggy, code gets duplicated and patched on, frustrating to work on, hard to refactor).