July 15, 2013 at 11:36 am
patrickmcginnis59 10839 (7/15/2013)
RobertYoung (7/15/2013)
patrickmcginnis59 10839 (7/15/2013)
Vila Restal (7/12/2013)
That's a sweeping generalisation of 'coders' (or perhaps more respectfully called software engineers or developers). Do you really have so little respect for them all, even those you've never met, or just the ones you've ever worked with?The dba/developer divide is probably something we'll have to live with. I don't really subscribe to it except to acknowledge the existance of the divide for the purposes of navigating the various logistics of getting things done, and maybe occasionally expend some effort occasionally to ruminate on its cause.
But lets not pretend that the disdain for developers expressed by one poster is a fluke, a significant percentage of DBA's do seem to have this adversarial point of view.
The first shot in the "adversarial point of view" was fired by coders. If you were around, or have read the history, you well know that Codd was vilified by the coding camp. The RM/sql database blew a large hole in IMS, which was Codd's explicit agenda. For those who don't know, IMS was/is IBM's hierarchical datastore, aimed mostly at COBOL copybooks, and requires a lot of coding just to keep breathing. IBM didn't take kindly to Codd; which is how Ellison beat them to a working product.
That doesn't really follow what I've read, the original "shot" you describe seems more like a decision by IBM to protect their existing hierarchical oriented product, and the subsequent efforts to isolate developers from Codd's ideas doesn't really seem to have been a decision made by developers themselves.
https://en.wikipedia.org/wiki/Edgar_F._Codd
Coders spew out more LoC to get more moolah.
This seems to be opposed to much discussion of desireable development practices I've run across, so I'm thinking a strawman might be under construction here 🙂 This in no way precludes the instances of bad development, but I'm thinking that you won't find many notable leading developers ascribing to "more LoC means better systems."
More LoC is implicit in "doing data management in the client". And yes, I hear that all the time. Few will be explicit in protecting their turf (aka, code silo); it looks small and petty. Fact remains, the "software problem" remains, and there's a way to fix much of it (not all, of course). That ain't no strawman, just your average coder.:w00t: There are a host of client-side edits generators, using the catalog. Why aren't they better known? Because the coder camp won't hear of it.:-P And so on.
As to Codd and IBM: protecting IMS and protecting sop COBOL coding was a case of one hand washing the other, IMS supported data management in code (it's just xml, though a bit brighter) so coders felt allegiance to those protecting their skill set. In 1969, when Codd presented his RM within IBM, IMS was only 1 year in the field (depending on how you count, no more than 4). A "better" data paradigm made for some bed-fellows. When it came time to define a formal data language, Codd was cut out, and an IMS cowboy (Chamberlin) got the job.
Two completely different points of view on how to manage transactional data. One that dates to 1950, and one that's driven by math. There's only one steering wheel, and it's been fought over for decades. The legacy coders started the fight by refusing to get out of the car. Can't say that I blame them, who'd want to give up a middle-class wage with no other skill set? Fact remains: the engine is responsible for the data, not the client(s); agnostic view of client access is what makes it possible to have any client r/w the data. And so on.
July 15, 2013 at 12:07 pm
patrickmcginnis59 10839 (7/15/2013)
Vila Restal (7/12/2013)
That's a sweeping generalisation of 'coders' (or perhaps more respectfully called software engineers or developers). Do you really have so little respect for them all, even those you've never met, or just the ones you've ever worked with?The dba/developer divide is probably something we'll have to live with. I don't really subscribe to it except to acknowledge the existance of the divide for the purposes of navigating the various logistics of getting things done, and maybe occasionally expend some effort occasionally to ruminate on its cause.
But lets not pretend that the disdain for developers expressed by one poster is a fluke, a significant percentage of DBA's do seem to have this adversarial point of view.
So it would seem to be with developer disdain for DBAs. I don't get it either... I spend a fair bit of time working with the Developers in my shop (I actually asked to be seated right in the middle of all of them so they think of me as one of them and so I'm easily accessible) so that we can tear down that great divide and so that all of us understand that we're all working for the same company.
Like I said, we're all in this together and the sooner that Devs and DBAs figure that out, the better it will be for everyone in any given company.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 15, 2013 at 1:13 pm
The first shot was fired.
That's about all we can say. Anything else is guesswork, hearsay, and likely self-serving.
As Jeff said, we're all in this together. Devs and DBAs need to work together to be effective, and secure.
July 15, 2013 at 4:37 pm
RobertYoung (7/11/2013)
Depends on the nature of the DBA: is it a production position, or a development position? I've never been or known anyone who would (or even could) do both.
Then you must have been in very soft protected environments where no-one had to do that. I've known many people who have done both at the same time, have done that myself, plus mixed in a few other roles too, making life a god deal more complex than it would be for someone just combining production DBA and development DBA.
The former let the client coders run the show, while the latter have the database developers do so. So, three different kinds of DBA, none compatible with the others.
I've been simultaneously VP of R&D, production DBA, development DBA, system DBA, database designer, and QA manager (and a few other roles thrown in as well); that's the sort of thing that senior people do in start-ups, for example: the cost of using half a dozen people to handle what you might think of as half a dozen roles of which no-one should do two adds enough to the burn rate that it just isn't going to happen, so it gets done by one person. The idea that the various DBA roles are not compatible with each-other is nonsense.
Tom
July 15, 2013 at 5:26 pm
RobertYoung (7/15/2013)
Coders spew out more LoC to get more moolah. That's their motivation. That's how they get more moolah; not by being smart and lazy, but by typing more. (Database folks look for the least amount of effort to get the maximum amount of benefit.) Anything to keep their butts in their cubes; the more convoluted the better. That's why we *still* have the "software problem" 60 years on. Codd showed us a much, much better way for those applications which depend on stored data, for multi-use(rs). Coders are repelled by that, in my experience. "We will do data management in the client". Heard that too many times to count. That's adversarial.
I've been reading through this conversation and becoming more and more depressed at seeing yet another demonstration that some people in the DBA world have decided to ignore reality and slag off "coders" at every opportunity for no reason at all. Maybe you are not one of those, and are just giving that impression through not paying enough attention to how your comments may be interpreted.
I suspect I know a lot more about "coders" than you do, 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; these three concerns, which are regarded as crucial by almost every software engineer I have ever known, would apparently be anathema to every "coder" you have ever met. I have to pity you in that you have spent all your years working with RDBMS in environments which have not managed to attract a single decent coder, and have allowed this bizarre and unusual experience to convince you that coders are inherently evil. I find it amazing that someone with a reasonable amount of experience of working as a DBA has managed to pick only such really awful employers to work for (only awful employers employ coders like those you describe) and have to wonder whether your choice of jobs has been biased by a vast prejudice against anyone who would be so anti-dba as to employ competent and professionally honorable "coders.
As for "adversarial", that cap definitely fits your comments in this forum. I hope that if that wasn't your intention you will be able to see that it was in fact your tone when you read back through the comments to date.
Tom
July 15, 2013 at 5:47 pm
As I said: there's only one steering wheel. In the bad old days (before cheap multi-processor/core/SSD/big-ram machines), all applications were code driven against OS files. That mentality persists with "coders", like it or not. I don't. Organic Normal Form™ schemas on such machines remove the necessity of code bloat on clients (and an App Server is still a client to the database); and, not too surprisingly, quite so many coders. It's that simple. As RM/SQL advocates, it is our duty to make the case for our profession. Some may wish to go along, to get along. Some may wish to split the baby, but I, for one, do not. I'm advocating for the paradigm shift that Codd envisioned. The get along folks just want to pay for the kids' braces. Date takes much the same point of view. The coders still hold the steering wheel in many places, and thus marginalize the datastore ("we have to de-normalize for speed", and such nonsense). I still see and hear this daily.
The machines available today, for a fraction of the cost of one medium duty coder (say, $20,000), will easily support ONF databases; blow the doors off Olde Style applications, and be utterly client agnostic. Such a Deal!!! The structure of ONF datastores simply does not support the data-management-in-client-code approach that code-centric development prefers. Such application development relegates the database (and DBA) to a subservient role. Codd and the RM deserve better. As his advocates (for those of us who still are), we must press ahead. 45 years of ignorance is sufficient.
July 15, 2013 at 6:07 pm
RobertYoung (7/15/2013)
patrickmcginnis59 10839 (7/15/2013)
RobertYoung (7/15/2013)
patrickmcginnis59 10839 (7/15/2013)
Vila Restal (7/12/2013)
That's a sweeping generalisation of 'coders' (or perhaps more respectfully called software engineers or developers). Do you really have so little respect for them all, even those you've never met, or just the ones you've ever worked with?The dba/developer divide is probably something we'll have to live with. I don't really subscribe to it except to acknowledge the existance of the divide for the purposes of navigating the various logistics of getting things done, and maybe occasionally expend some effort occasionally to ruminate on its cause.
But lets not pretend that the disdain for developers expressed by one poster is a fluke, a significant percentage of DBA's do seem to have this adversarial point of view.
The first shot in the "adversarial point of view" was fired by coders. If you were around, or have read the history, you well know that Codd was vilified by the coding camp. The RM/sql database blew a large hole in IMS, which was Codd's explicit agenda. For those who don't know, IMS was/is IBM's hierarchical datastore, aimed mostly at COBOL copybooks, and requires a lot of coding just to keep breathing. IBM didn't take kindly to Codd; which is how Ellison beat them to a working product.
That doesn't really follow what I've read, the original "shot" you describe seems more like a decision by IBM to protect their existing hierarchical oriented product, and the subsequent efforts to isolate developers from Codd's ideas doesn't really seem to have been a decision made by developers themselves.
https://en.wikipedia.org/wiki/Edgar_F._Codd
Coders spew out more LoC to get more moolah.
This seems to be opposed to much discussion of desireable development practices I've run across, so I'm thinking a strawman might be under construction here 🙂 This in no way precludes the instances of bad development, but I'm thinking that you won't find many notable leading developers ascribing to "more LoC means better systems."
More LoC is implicit in "doing data management in the client".
Its implicit IF it duplicates functionality already available in the SQL server.
And yes, I hear that all the time. Few will be explicit in protecting their turf (aka, code silo); it looks small and petty.
The thing is, if you have a fellow going off the farm, and he's piling on unmantainable and ill advised code, then what is essentially happening is he is probably working unsupervised or even worse, the organization really has no knowlegeable staff on board. If this is the sort of app that is well suited to relational technology, and the fellow is essentially writing an RDBMS on the client (or any significant portion thereof), then isn't that more of a "not invented here" syndrome, which we as IT professionals across the board should recognize as a bit of an anitpattern no matter whether we are developers or dbas?
Hey, I'm not saying it doesn't happen, I've seen some real headscratchers, but I'm also aware that its possible to simultaneously be proficient in procedural and object oriented languages and set oriented queries. I'm also certain that LoC is not generally considered a direct meter of programmer incompetence as you believe it implies.
Fact remains, the "software problem" remains, and there's a way to fix much of it (not all, of course).
I'm not going to profess to be able to solve the "software problem", and given the history of our industry's endeavours, I'm not absolutely sure there is a "silver bullet."
That ain't no strawman, just your average coder.:w00t: There are a host of client-side edits generators, using the catalog. Why aren't they better known? Because the coder camp won't hear of it.:-P And so on.
This is contrary to my experience even just reading forums. In fact, I've read some griping that some of these interfaces are used too much, and even that some DBAs would like the developers to pretty much stick with stored procedures. As a matter of fact, I even think that the extent that "edit generators" are used to produce an app is orthogonal to the degree of database functionality duplicated in the client, so I don't even see how this argument follows.
As to Codd and IBM: protecting IMS and protecting sop COBOL coding was a case of one hand washing the other, IMS supported data management in code (it's just xml, though a bit brighter) so coders felt allegiance to those protecting their skill set. In 1969, when Codd presented his RM within IBM, IMS was only 1 year in the field (depending on how you count, no more than 4). A "better" data paradigm made for some bed-fellows. When it came time to define a formal data language, Codd was cut out, and an IMS cowboy (Chamberlin) got the job.
Well sure, one or four years in the field, doesn't that imply that at the beginning of that first year, at least some investment and development into the product was at an end point rather than the beginning? For instance, the big OS/360 during its very first year of production usage none the less was a product of immense effort and resources. You're not going to run something like that for a year and then drop it unless nobody finds it useful at all.
Two completely different points of view on how to manage transactional data. One that dates to 1950, and one that's driven by math.
I've heard that argument before, its like the programmers in the fifties stored the number 1 in a variable and prayed that it didn't transform into some other tandom number because they weren't able to use math.
There's only one steering wheel, and it's been fought over for decades. The legacy coders started the fight by refusing to get out of the car. Can't say that I blame them, who'd want to give up a middle-class wage with no other skill set? Fact remains: the engine is responsible for the data, not the client(s); agnostic view of client access is what makes it possible to have any client r/w the data. And so on.
I don't doubt that the developer / dba divide exists. I would absolutely encourage you in expressing your theories on why this divide exists, just as I hope you would encourage me to evaluate your theories in some detail.
July 15, 2013 at 7:17 pm
(rather than duplicate that whole stream...)
As a matter of fact, I even think that the extent that "edit generators" are used to produce an app is orthogonal to the degree of database functionality duplicated in the client, so I don't even see how this argument follows.
There is the emerging possibility, if bandwidth continues to increase, that we're on the verge of doing *nix/RDBMS/RS-232/VT-X00 over the 'net. IOW, full duplex connection to the database over "just a wire". Thus, updates are in real-time, and errors are generated by the database and passed to the "client", also in real-time. Every client is just a dumb terminal!!! (We could even see a resurgence of 4GL databases; Back to The Future, a kind of Progress.) Wouldn't that be loverly?
The "duplication" of functionality is for the convenience of users, where the connection is HTTP-like (or actually is), which is to say non-persistent (block mode vs. character mode, for instance); give them the same data-checking locally, so long as it doesn't get out of date. The 3270 has had an edit language from day 1 for just that reason. Some argue that this means that the datastore needn't do so. And here I strongly disagree. The database must be the "integrity check of record"; otherwise it's just a collection of VSAM files. "Duplicate" the integrity checks for use by the client from the database; update client from database as needed.
Not much code to write for a VT-220.
July 15, 2013 at 7:26 pm
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. 😀
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 have worked with plenty of people that think that Agile Development requires no planning or 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, people with a hefty dose of the "I don't need to test my code" syndrome, people who think the ORMs write perfect code, and people that think stored procedures should be replaced by embedded code, but not so many that understand the goodness that you speak of. 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".
So I'm thinking that there are shops where the divide is quite large and even hostile. 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. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 15, 2013 at 7:39 pm
Of course a postal code field should be nvarchar(4000)! You never know what the future holds.
Cheers
July 15, 2013 at 7:46 pm
jfogel (7/15/2013)
Of course a postal code field should be nvarchar(4000)! You never know what the future holds.
BWAAA-HAAAA!!!! That and an "IsActive" column were the examples I used put put a little heat under their kettles. I couldn't believe it when the Lead Developer recited Knuth's famous saying to explain why it was done and he did it with a perfectly serious face on. As a bit of a side bar, this is the guy that introduced himself to me as "I'm the Jeff Moden of the GUI world." My comment after his Knuth explanation was "you can't be... I'm not [font="Arial Black"]that [/font]bad". :-P:-P:-P
--Jeff Moden
Change is inevitable... Change for the better is not.
July 15, 2013 at 7:54 pm
One of the major apps our business uses names columns with spaces and special characters like "Created Date/Time". I'm surprised they don't want the case sensitivity default changed as well. Then they have common app generated queries that search the first three characters of that nvarchar(4000) column. Oh but the column is indexed!
Cheers
July 15, 2013 at 9:25 pm
jfogel (7/15/2013)
One of the major apps our business uses names columns with spaces and special characters like "Created Date/Time". I'm surprised they don't want the case sensitivity default changed as well. Then they have common app generated queries that search the first three characters of that nvarchar(4000) column. Oh but the column is indexed!
BWAAA-HAAAAA-HAAAA!!!! Too funny! Real life is stranger than anything you could make up! It was all I could do to keep from blowing the mashed potatoes I was eating out of my nose when I read that. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
July 16, 2013 at 4:47 am
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. 😀
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. 😛
Dealing with the consequences of peoples' errors (including my own) has been educational and exciting for me too. 😀
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.
Tom
July 16, 2013 at 7:43 am
Well said, Tom. In fact, that's a great editorial based on an obviously long period of experience. Yeah... I've worked in some pretty strange environments. You said you don't know how they can exist and that's spot on because they don't exist long.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 31 through 45 (of 63 total)
You must be logged in to reply to this topic. Login to reply