Jeff Moden (7/15/2013)
L' Eomot Inversé (7/15/2013)
and yes I've met one or two (certainly fewer than three) in almost half a century or working in computing/compute science/IT/whatever you want to call it who are indeed utterly stupid about the boundaries between what should be in the database, what should be in the server component of the app, and what should be on the client side. But the vast majority of software engineers are, in my experience, concerned with effectiveness, efficiency, and (as an ideal difficult to achieve) verifiability;
BWAAA-HAAA!!!! So THAT's what happened! All the "utterly stupid" ones migrated to Detroit leaving only the good ones behind for you. :-D
I make a distinction between utterly stupid (like anyone who, as Robin describes, actively perpetuates bad practice for the purpose of ensuring that far more code will be written that need be) and being utterly ignorant. I've met utterly ignorant devopers, but they were not utterly stupid.
I think that what mostly happened was that I met developers who were easy to educate, even if utterly ignorant at first they certainly weren't utterly stupid so they rapidly stopped being ignorant when I made the effort to educate them. I found that people who are acquainted with declarative styles of programming (functional programming, logic programming) and some of the old-fashioned ideals like modular programming with clean and narrow boundaries, built-in error management, and diagnostic logging just about inevitably think that having a really solid boundary between the data handling components and the rest of the system is too obvious a requirement to need comment, and that moving data management functions outside the DBMS is insanity - but that didn't mean they could do the RDBMS work if they hadn't learnt how. The only difficulty with people with that background is that when you introduce them properly to Codd's model and then to SQL they recognize that SQL is a horrible kludge and want to invent their own relational data language based on Codd's ideas instead of using IBM's badly bodged up compromise with the extra screw-ups added by ANSI, which of course is what I was working on for quite some time before economic reality forced a switch to SQL so that my sympathy for that point of view can hamper my education efforts.
I have of course met a large number of people calling themselves DBAs who were utterly stupid: some who advocate things like ORMs (a sin of the same magnitude as advocating edit generators for non-trivial application work), some who were taught to do everything with cursors on DBA courses run by incompetents and to whom set-oriented queries are anathema (mostly because they don't understand how to do them, I think), some who want to prevent normalisation because it often means more joins, some who insist that normalisation is a mistaken act because it's all about implementing business rules in the database instead of in the app (of course that is exactly what normalisation is about; the data is useless if it is not consistent with the business rules, and normalisation is about data integrity - ensuring that the schema itself enforces those rules as far as is practical; but handling business rules in the database is most certainly not a bad thing), some who would throw away the representation principle so that everything should be normalised to BCNF (or 4NF, or 5NF) regardless of whether that normal form is compatible with EKNF, some who insist on using a wide-open embedded SQL approach to the DBMS interface in case where it makes no sense to provide access to anything but stored procedures, some who think NOLOCK or READ UNCOMMITTED is the answer to all performance problems (and correctness of results is of course far less important than performance), some (Chris Date is a prime example) who are so anti-Codd as to want for ignore reality and forbid nulls altogether, some who want to use NUlls not as Codd wanted them but for all sorts of things forbidden by 1NF (nulls as a means of having a variable number of columns, nulls to something other than ignorance of a datum, with what they indicate depending on what column they are in and on values in other columns in the same row, and so on), or so anti-Codd as to want to abolish the atomicity principle altogether (another one sometimes advocated by Date), and even DBAs who want to avoid use of N(VAR)CHAR because "it's storage inefficient" even though they have to represent West European, Greek, Arabic, Russian, and Japanese text. Many DBAs that I've met have had several of these attributes, often in combinations that are mutually contradictory. No surprise, they've had no proper education on the relational model; unfortunately they've been told that what little they've learned about SQL has given them a full understanding of the relational model, and many of them believe it, which makes them impossible to educate.
I have, on the other hand, some across databases which were built by developers and were a complete shambles because those developers had had no training at all in relational principles. These people clearly also had no training on the classical development principles (modularity, error management, verifiability, minimising computational complexity, strong abstraction) or they would have made less of a mess. If they were still around when I became involved with their DB, they became educated. If they weren't still around, maybe they were as Robin describes, maybe they weren't - I never met them, so I wouldn't know, but I suspect that people take pride in their app development work so will not as Robin suggests deliberately perpetuate bad practise just to ensure that there is more coding work than necessary (particularly since a developer generally spends far less of his time coding than he does thinking about how to do things or what to code). The ones I met were certainly not as Robin described (with two exceptions), they could be educated and had no utterly stupid axe to grind about keeping the volume of app code high.
Up until my current job (and there's still one that I have to contend with), all I've run into are folks that don't understand anything of what you've just said.
I've run into plenty too - but the ones who didn't understand and weren't going to understand because they didn't want to were not developers, they were accountants, bankers, marketeers, and salesmen. At least one company that used to employ 23000 people worldwide now employs less that 5% of that because people who were not engineers or developers and didn't understand those things were given control of it by the shareholders.
I have worked with plenty of people that think that Agile Development requires no planning or documentation
Some managers never learn TINSTAAFL; but I've never met a developer who thought Agile could work without planning and documentation.
people that think Knuth's statement about "pre-optimization is the root of all evil" means that it's ok to promote tables than use NVARCHAR(4000) for all columns
That's amazing. It's a basic principle that if we know the maximum possible length of a variable length column we specify it as part of the type so that attempts to insert out or range values are detected straight away.
people with a hefty dose of the "I don't need to test my code" syndrome
First time they do that they should be told they'll be fired next time they do it.
people who think the ORMs write perfect code
but were those people developers or DBAs? I've know some DBAs who believe that, but never a developer.
and people that think stored procedures should be replaced by embedded code
trying to push my go button? Oh, just take those ones out and shoot them, please!
but not so many that understand the goodness that you speak of.
That's sad - you deserve better coleagues.
I've even run into SQL Developers that have said things like "I don't need to talk to you because I'm a developer... go backup a database or whatever it is you do"
That sort of thing can sometimes happen with young kiddies fresh out of school, who are still wet behind the ears. It's definitely a sackable offence if done by anyone who hasn't got that excuse, except in cases where it's absolutely clear that there was provocation sufficiently extreme to excuse it (in which case that provocation may well be a sackable offense).
So I'm thinking that there are shops where the divide is quite large and even hostile.
I'm surprised that such shops exist. But I have to admit that I was surprised any time I found a developer with that sort of attitude, even the ones (the vast majority) who could easily be educated out of it, and extremely surprised when I found someone who couldn't be educated out of it (which didn't happen often enough to matter).
The good thing is that it's been an exciting life and I've learned more about how to do things right from people doing it wrong than I can shake a stick at. :-P
Dealing with the consequences of peoples' errors (including my own) has been educational and exciting for me too. :-D
Sometimes I even think that I prefer being up to my neck in trouble with plenty of stuff that needs fixing, but then I remember that the fun is to do the learning and the fixing and make the environment sane so that no-one is up to their neck any more; besides which, doing something completely new is as at least as much fun and provides as much learning opportunity as fixing a mess.