Fundamentally its about a lack of qualified professionals that are willing to think through their application in detail. As a by product people slavishly foll

Fundamentally its about a lack of qualified professionals that are willing to think through their application in detail. As a by product people slavishly follow concepts and ideologies as opposed to thinking through which concepts actually apply to their current use case. People can't be fucked to do that. In their minds a simple "this good, that bad" construct pops into their heads. "Waterfall bad, agile good" without asking themselves what the trade-offs of either pattern provide. I'm currently living on the flip side of this article. A company that decided to give their clients the ability to have a completely free schema for their data backed by a real-time CRUD architecture which follows an EAV pattern so every column value is represented by a database row. Its inherently flexible but it doesn't scale. What would be a single row select in any "sane" database retrieval routine is a multi-row and multi-table join on ridiculously tall tables. Nobody thought through the implications of providing the customer with that free schema and nobody ever closed the loop on that problem set. Ideas like CQRS (who the fuck named that pattern so awfully btw?) or even things like NoSql would be preferable to the architecture but they're somewhat slaves to the notion of ORMs and RDBMS. As a product, we try to spin on a dime and an optimisation for client A's infrastructure will result in a detriment to client B. Staff remain convinced that its an issue with the transport protocol chosen or ORM used but really its a problem with the feature set we chose to offer and failing to architect the solution to that problem created by our feature into the project.