There is an old saying with software that three years from now, no one will remember if you shipped an awesome software release a few months late. What customers will still remember three years from now is if you shipped a software release that wasn’t ready a few months too soon. It takes multiple product releases to change people’s quality perception about one bad release.
In drawing up an E-A-R diagram for a program (doing object-oriented design, if you must be seen at a table at Maxim's), you're led inexorably toward a study of the problem and its context and away from the solution and its technology. This--and not multiply inherited, polymorphic, virtual mix-in friends--is the key insight of object-oriented methodology: Use E-A-R diagrams to do program design. After all, the understanding of and insight into the problem is the wellspring of program simplicity and implementation efficiency. A good architect studies bricks once, but studies people every time he designs a new building.
Object-oriented programming methodology is an open invitation to gratuitous generalization and the growing of formal gardens of complexity kudzu. Indeed some OO wizards recommend that you add code and levels of generality to object-oriented programs simply on the grounds of completeness and possible future need. But the thrust of commercial programming is to do more with less, not less with more. The idea is to synthesize, to make programs smaller, to refine and focus them. If what you really want is an omelet, you don't start with a Faberge egg.
Programmers by disposition are enamored of technology. This is a strength when it comes to abandoning old, inefficient ways and adopting new, more efficient ways. But it's a weakness when new software tools arrive faster than we can learn to use them effectively and we spend too much time at the wrong end of their learning curves. The benefits of a truly effective new technology are foregone when, in the rush to try out the next shiny whiz-bang tool, we abandon the current one.