I guess I don't see the harm in spending a little extra time up front to design things properly rather than just jumping in and writing code, hoping to stumble upon the correct design pattern. I've found it much easier to find and solve problems up front rather than waiting for potential landmines, at least, the time required to fix those problems is less if they're exposed earlier in the process. It's certainly possible to over-engineer a solution if you select a design pattern up front, but maybe you'd be better suited by having a rule against over-engineering.
It's hard to define a rule against over-engineering. The only approach I've seen that has any success is to ban any and all design up front, and only ever write code to implement user-facing features.
We "spike" stuff i.e. do a quick sanity check before we commit to something. A pattern will become apparent there and then if there is one. Sometimes this spike is re-factored into the product or is scrapped and rethought. Multiple eyes see every design - that is more important than anything.
You can't quantify over-engineering until it is done unfortunately.
