July 12, 2013 at 10:01 am
Vila Restal (7/12/2013)
RobertYoung (7/11/2013)
Vila Restal (7/11/2013)
If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.
I don't see why you would say that.
Because, as I said originally, there are multiple types of DBA, and what you describe is the code-centric data DBA under the thumb of coders. No real DBA, who's learned Codd and SQL and ..., has any desire to kowtow to coders, who generally make more bugs than features.:-P Building an Organic Normal Form™ schema isn't something that one guy/gal does over lunch, while the coders are playing frisbee. It's real work, with real payoff. That payoff being smaller data footprint, and loads less code on the client. Aye, matey, thar's the rub. Coders never want to hear about a tech that makes less code.
Again, for those coders who just want a simplified I/O syntax, and are too lazy to write their own I/O handlers, and want easy backups, then a sql database will do that. But it won't be very efficient, and will end up with spaghetti everywhere.
July 12, 2013 at 11:07 am
RobertYoung (7/12/2013)
Vila Restal (7/12/2013)
RobertYoung (7/11/2013)
Vila Restal (7/11/2013)
If the analogy is between a software shop and a band then I wouldn't say DBA's are on stage. The sales reps and support are the performers, the developers are the songwriters (and often performers too). DBA's would be behind-the-scenes people: sound or lighting engineers or even roadies.And that's the DBA who just runs the flatfiles that make the coders happy. Not the sort of DBA that most people who do RDMBS want to be.
I don't see why you would say that.
Because, as I said originally, there are multiple types of DBA, and what you describe is the code-centric data DBA under the thumb of coders. No real DBA, who's learned Codd and SQL and ..., has any desire to kowtow to coders, who generally make more bugs than features.:-P Building an Organic Normal Form™ schema isn't something that one guy/gal does over lunch, while the coders are playing frisbee. It's real work, with real payoff. That payoff being smaller data footprint, and loads less code on the client. Aye, matey, thar's the rub. Coders never want to hear about a tech that makes less code.
Again, for those coders who just want a simplified I/O syntax, and are too lazy to write their own I/O handlers, and want easy backups, then a sql database will do that. But it won't be very efficient, and will end up with spaghetti everywhere.
OK, so you've shown that you don't like coders and that DBA's mustn't be subservient to them but not why the 'DBA is more like a Sound Engineer rather than Guitarist' point is wrong. If you're going to say I'm wrong on that point, which is what you are doing (it's all I said), please explain why and not just explain that DBA's mustn't work for the coders, which isn't what I said and is another point entirely.
And why this tirade against coders? Where did you get the impression that I was suggesting a DBA's work was easy or unimportant? Do you understand what a sound engineer does? That was the title of the article: Hiring Guitarists. My point is simply that a company hiring a good DBA is more like a band hiring a good sound engineer rather than a guitarist.
It is annoying to have someone disagree with you and then give complete non-sequitur reasons for it:
RobertYoung (7/12/2013)
what you describe is the code-centric data DBA under the thumb of coders.
No it isn't. Not my intention or my opinion or what I did.
RobertYoung (7/12/2013)
No real DBA, who's learned Codd and SQL and ..., has any desire to kowtow to coders, who generally make more bugs than features.:-P
Codd's rules take 10 minutes to learn and a good DBA or developer learns them from first principle (would come to them by their own reasoning) not by wrote.
All DBAs have learnt SQL surely (of one flavour or another).
I've not learnt "..." though. Is it useful for being a DBA?
Surely no human being with any self-respect has any desire to kowtow to anyone else. The DBA/coder subset is no different.
(And wow! You really don't like "coders" do you?)
RobertYoung (7/12/2013)
Building an Organic Normal Form schema isn't something that one guy/gal does over lunch
Sounds more like development than administration to me but ok, let's call him a DBA for sake of argument
RobertYoung (7/12/2013)
t's real work, with real payoff.
I never said it wasn't
RobertYoung (7/12/2013)
That payoff being smaller data footprint, and loads less code on the client. Aye, matey, thar's the rub.
Well duh. Relational databases are better. I agree and I never said they weren't.
RobertYoung (7/12/2013)
Coders never want to hear about a tech that makes less code.
Again, for those coders who just want a simplified I/O syntax, and are too lazy to write their own I/O handlers, and want easy backups, then a sql database will do that. But it won't be very efficient, and will end up with spaghetti everywhere.
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?
To everyone else: am I being trolled here? ("I'll just quote some random guy, say I'm disagreeing with him and go into a tirade against coders")
July 12, 2013 at 11:31 am
Trolled? You're the one who reduced DBA to not even a guitarist!
Well, what can I say, but what I said originally: there are DBAs who rule the data (the singers) and there are DBAs who don't (sound guys, roadies, drum techs, etc.). The notion that *no* DBA can be the singer is where the fundamental disagreement lies. Screen oriented apps (games, embedded, iStuff apps, and the like) have little need for a persistent, coherent data store.
However, for those apps which can/do use an RDBMS, then there is a fork in the development road: treat the data as un-normalized files (cater to the coders) or as Organic Normal Form™ data (put the logic with the data in the engine through DRI, etc.). The former is no different from COBOL/VSAM of the late 60s, while the latter isn't. I've been in the room when coders (COBOL/java as it happens) insist on "doing the transactions in the application". So, I'm not making this up. Those coders weren't going to give up their power over the application, as they saw it. The simple fact is that relying on the RDBMS engine to enforce data integrity reduces the amount of data on the server and (non-generated) code on the client. Coders see that as stealing from their rice bowl. And it is. So be it.
To put it starkly: if *your* DBA said to you, "I can show you how to eliminate 90% of LoC out in the application and reduce data footprint by 75% by using SS (or whatever) relationally", would you graciously say, "thanks". Or would you look for some excuse to keep writing code?
July 12, 2013 at 12:01 pm
RobertYoung (7/12/2013)
Trolled? You're the one who reduced DBA to not even a guitarist!
Not even a guitarist?
Firstly, you seem to think that only the musicians are important in a band. Wrong!
Secondly, you seem to think that the DBA is the most important person in a company. Also wrong!
I am a person who wears both DBA and developer hats (and the two are distinct although often performed by the same person). We are here talking about the DBA role only, not a DBA/developer.
But anyway, I see now why you disagree: You think only guitarists (at the very least) and singers (or even only the performers on stage) are important to music and DBAs should be equated to only these most exalted people and it's an insult to equate them to a lowly sound engineer.
Try these links. You might find them enlightening:
http://en.wikipedia.org/wiki/Eddie_Kramer
http://en.wikipedia.org/wiki/Andy_Johns
http://en.wikipedia.org/wiki/James_Guthrie_(record_producer)
http://en.wikipedia.org/wiki/Leslie_Ann_Jones
Or indeed anybody in the lists of engineers of note on http://en.wikipedia.org/wiki/Audio_engineer
You obviously haven't any understanding of how integral and essential these people are to the music that has enriched your life.
Not even a guitarist indeed. As an amateur guitarist myself I find that insulting.
And I maintain my point: A DBA needs to be reliable but behind the scenes. The customer (the audience) shouldn't know they're there because the only time they do is when support is explaining to the customer why they've lost all their data ( because the numpty DBA deleted it all).
July 12, 2013 at 12:20 pm
Vila Restal (7/12/2013)
And I maintain my point: A DBA needs to be reliable but behind the scenes. The customer (the audience) shouldn't know they're there because the only time they do is when support is explaining to the customer why they've lost all their data ( because the numpty DBA deleted it all).
Yes, because it is ALWAYS the DBA who screws up? I don't know what to make of the above and I hope I'm simply not reading it right.
Cheers
July 12, 2013 at 1:58 pm
jfogel (7/12/2013)
Vila Restal (7/12/2013)
And I maintain my point: A DBA needs to be reliable but behind the scenes. The customer (the audience) shouldn't know they're there because the only time they do is when support is explaining to the customer why they've lost all their data ( because the numpty DBA deleted it all).
Yes, because it is ALWAYS the DBA who screws up? I don't know what to make of the above and I hope I'm simply not reading it right.
Indeed you're not reading it write if you think that's what it says (it doesn't say that).
It means what I said (sheesh):
DBAs are not customer facing people. the good ones are unsung heroes if you like: when they're good everything ticks a long without a hitch but when they're bad - that's when they become known (that was the point of that example - along with making it clear that plenty of DBAs are numptys and if you're thinking of employing a DBA you want to be sure you don't get one of them). But they are, by definition, behind the scenes and should be much more like sound engineers in attitude and role than the performers such as guitarists and singers. And any DBA with the obvious lack of people skills (irrational hatred of 'coders' and misquoting people and not listening to what people are actually saying) that perhaps some DBAs might have should definitely not be allowed anywhere near a customer.
I think that this is uncovering two very important tests of any DBA interview process: that they listen to people and comprehend what's being said to them (vital to being a good DBA imho) and that they are team players and respect other people's roles in the process and work to accommodate the requirements of the developers and customers. Companies with DBAs that don't do that have a major problem on their hands.
July 12, 2013 at 2:08 pm
Am I reading it write or right?
Cheers
July 12, 2013 at 2:30 pm
jfogel (7/12/2013)
Am I reading it write or right?
Neither! You are reading it wrong.
I didn't say what you said I said. You know that. You even quoted me and went on to say something completely different.
How else can I phrase that?
One example of a DBA that messed up does not mean that it's always the DBAs that do. I can give examples of coders that do and doctors and politicians and bankers and economists etc etc. This is elementary stuff! I shouldn't need to explain that to you. I'm sure you're not stupid. Please try not to be.
It was an example of the only way a DBA becomes known to the world because when they do mess up it's often quite catastrophic. Sound engineers are the same: if they do a good job nobody knows. But everyone in the audience knows when they make a mistake. A DBA and a sound engineer should not want to be the centre of attention (like a guitarist or singer does) because the only time that happens is when they get fired!
Now: was that an honest mistake of yours (taking what I said to mean that when it obviously doesn't like I made a mistake writing 'write' instead of 'right')? Or were you just deliberately being provocative?
July 12, 2013 at 2:35 pm
Just stop.
You wrote:
"Indeed you're not reading it write if you think that's what it says (it doesn't say that)."
And I asked if I read it write or right. You are acting so uppity and saying people need to comprehend but you misuse words and speak in circles. Give it a rest. Go play an instrument, have a beer or anything other than continue to post in this thread.
Cheers
July 12, 2013 at 3:30 pm
jfogel (7/12/2013)
Just stop.You wrote:
"Indeed you're not reading it write if you think that's what it says (it doesn't say that)."
And I asked if I read it write or right. You are acting so uppity and saying people need to comprehend but you misuse words and speak in circles. Give it a rest. Go play an instrument, have a beer or anything other than continue to post in this thread.
I spelled one word wrong! and acknowledged it!!
Vila Restal (7/12/2013)
like I made a mistake writing 'write' instead of 'right'
and you then say all that above? (you explain your 'joke'? really?!!!)
So I'm misusing words? (plural)?!
Give it a rest?!!
No, you sir owe me an apology for misquoting me. Accusing me of saying that all mistakes are made by DBAs (or had you forgotten about that).
Acting so uppity? Uppity is not the word and I am not acting. I am annoyed at what you said. It is a basic logical fallacy to take what I said and equate it to "it's always DBAs that make mistakes". Then you pick up on a spelling mistake as an oh so witty comeback. I'd expect that on YouTube comments. Not here.
You accused me of an opinion and you were wrong. I explained that you were wrong. And now you say I'm being uppity. You would be too.
Why did you bother to post if you don't care about the topic?
As it happens I do care about the topic and I think people reading this might be wanting some thoughts about hiring DBAs: what makes a good DBA and what doesn't. If I'm speaking in circles it's because a couple of people are (I half suspect deliberately) not comprehending what I'm saying (and I'm not using long words or making particularly complicated so it's getting quite frustrating).
My point was and is:
DBAs are more like sound engineers than guitarists. That is not an insult to DBAs or sound engineers. Both perform vital difficult roles that need lots of training and experience to be any good at. A band with a bad sound engineer will sound like a swarm of hornets to the audience no matter how good musicians they are. Database developers (coders) will produce a shockingly unreliable and poorly performing product for the customer if they don't have a good DBA no matter how good they are at their job.
I was then picked up on that point as talking about flat-file DBAs only. And that was wrong. That's not what I meant and it came from a basic misunderstanding of what a sound engineer does. (Regarding it as a lowly role - less than a guitarist, which it isn't.)
By way of explaining why DBAs are and should remain behind the scenes (like a sound engineer) I gave a link to an example of a DBA making a name for himself in the company where he works. (I.e. by screwing up and getting fired.)
You then chipped in suggesting that that means I think DBAs are the only ones that make mistakes, which of course, to anyone with a basic grasp of logic, it doesn't.
That was annoying. I expect you know that's not what I meant or what it proves. But, just in case you didn't, I explained that to you.
You then came back with your oh so witty comment about a misspelled word.
That is not speaking in circles. I am trying to stay on topic here and you are trying to annoy me.
If you disagree with what I'm saying then please do but make sure you understand what I'm saying (including what a sound engineer does and how difficult and vital that work is) and what I'm not saying (that a DBAs job is easy or unimportant or they are the only ones who make mistakes).
Otherwise, of course you can make comments about the article irrespective of what I've said. But if you're going to comment on what I've said please keep it on topic and respectful.
Misquoting me and trying to make witty put downs is not appropriate for this discussion or forum and I did neither of those to you or anyone else so I don't see why you are doing that.
July 12, 2013 at 4:03 pm
Easy guys. We're all in this together.
--Jeff Moden
Change is inevitable... Change for the better is not.
July 15, 2013 at 3:32 am
Steve - thanks for those thoughts. I wish life were that simple. I seem to have spent most of my time trying to stop the lunatics taking over the asylum! The more skilled the lunatic the worse the situation can become. I need all my team - experts to novice - to talk to me and explain their approaches. It is the "talk to me" bit that is vital. I always ask for alternative solutions even if the first one offered is a clear winner. Arrogance and the closed mind really annoy me and I always ask questions at interview to try to winkle this out. I would rather a colleague who needs to develop but is a good team player, than a guy/gal (the guys are worst believe me) bristling with Microsoft accreditations and finely honed interview responses.
July 15, 2013 at 9:30 am
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.
July 15, 2013 at 10:00 am
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.
The issue isn't individuals. The issue is work product. 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.
Organic Normal Form™ schemas (supported by triggers, procs, and other server side entities) provide an opportunity to ditch the three-chord knucklehead for Clapton (i.e., not so much code and much more database). IOW, yet again, smart database development stresses effort in the database design, and any code in extremis. This is not the coders way. It just isn't; as these comments have demonstrated.
July 15, 2013 at 11:06 am
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."
Viewing 15 posts - 16 through 30 (of 63 total)
You must be logged in to reply to this topic. Login to reply