The problem with this is that those cobbled-together SQL queries are precisely the kinds of things good programmers either replace or automate away; you can automate away an assembly-line job, but not as cheaply, and not as easily.
There might not be any such thing as a 100x programmer or whatever, but the value proposition for replacing a few sub-par programmers with one better programmer and a framework is a lot clearer than the one for replacing a handful of assembly line workers with a more complicated and more expensive piece of machinery.
Hmm, I don’t think so. If you have a dozen similar queries, then you can factor out the similarity (say, into a view, or a Ruby subroutine that generates the SQL). If you have a thousand that vary in a lot of different ways, a few subroutines isn’t enough; you need a DSL to factor out the similarity, aka “automate away” the queries.
But then you need someone to write down the idiosyncratic bits of each query, the thing that makes it different from the other thousand, in your DSL. For a lot of systems, the right DSL is in fact SQL itself, but even if it’s not, you still need people to write in it.
In short, nonprogrammers writing cobbled-together SQL queries are the result of automating away the non-idiosyncratic aspects of the queries.
Software (in the Turing sense), removing the material complexity, accelerated the notion of automation. Easy things can be, medium-complexity too, only leaving the NP-complete stuff to be done by hand. Jobs are an endangered species.
There might not be any such thing as a 100x programmer or whatever, but the value proposition for replacing a few sub-par programmers with one better programmer and a framework is a lot clearer than the one for replacing a handful of assembly line workers with a more complicated and more expensive piece of machinery.