Eh. Sometimes over-engineering is a matter of perspective. Take JSON API, a standardization of HATEOAS / REST principles around JSON and HTTP, for example. If

Eh. Sometimes over-engineering is a matter of perspective. Take JSON API, a standardization of HATEOAS / REST principles around JSON and HTTP, for example. If you just naively walk up to it you think to yourself: > Wait, what? Can't we just return the simple data we know we want? Why complicate this all with relationships, links, and meta data? But after a while you realize that 90% of what you're doing could be abstracted if only you had a predictable output. So EmberData comes along and you write a Rails backend that has the nice advantage of not needing to worry about HTML (outside of OAuth / emails, anyway) and you harmonize your API. You use Ember Fastboot for slow clients and call it a day. Someone else looking at what you've done may say: > Wait, what? Why don't I just create static HTML pages instead of using your over complicated service? And they're not completely off-base. In fact it's what I do for my own personal site. It's just that the context of their situation has different tradeoffs. The same thing is true for a lot of software. Excel is "over-engineered" for most people. So is HTML. So is Unix. But in general what happens is that the person with the most complex requirements usually wins because they usually have the fattest wallet and everyone else papers over the complexity with abstractions or uses something less complex that meets their needs.