Excellent extension of Conway's Law - precisely the word used here to describe the c*** frequently encountered, authored by devs at customer sites. But why? Perhaps a major contributor is the failure on the part of upper management to understand the imperative nature of in-vocation education in technological disciplines. C*** code, born and bred in SQL 2000, being churned out in 2019, and a face-palm is inevitable. Reach down the wire and give that dev a slap, comes to mind.
As a hybrid DBA-DEV, embedded alongside most of the dev and QA team, we all get along really well, and information/education-materials, are well-received. So, part of the solution, i.e, cutting down on c*** code, is for those with appropriate skills to brown-bag-session, or write single-topic bulletins, or code-coach alongside Devs, not just in T-SQL, but like Brent O's course, "Think like the Storage Engine". These help non-DBA-skill folk to get at least a 101-level covering what it takes outside Dev-land, to host and support their code and schema designs.
Both roles can benefit from cross-pollination. I'd venture that a Dev with DBA knowledge is a better Dev, and a DBA with Dev knowledge likewise is a better DBA. Wholeheartedly support the bringing down of silos - embed, and assimilate skills by osmosis at the very least!
While we're here, it really wouldn't hurt Product personnel to get in on the 101-level stuff, too. Far too often, Product-chasm-Dev, and Product-chasm-DBA, un-bridged voids lead to c****y Product designs, which inevitably cascade, like that-which-runs-downhill, into manifest c*** code and schema.