The Daily WTF: Curious Perversions in Information Technology

2013-11-19 Reply Admin

ObiWayneKenobi:
I've noticed that generally DBAs are over protective. They're extremely paranoid people that are afraid to relinquish any bit of control to anyone other than themselves. And organizations tend to be extremely paranoid as well, fearing anything that might let someone WHOM THEY HIRED do something that isn't specifically detailed in some manifest somewhere. This also tends to lead to nonsense like tracking each and every specific change that someone does, to the extent of even tracking when someone views a record, because they're so paranoid that somebody might change something instead of oh I don't know, trusting people they employ.
it's not always large companies, either. I've seen an increasing amount of smaller organizations trying to pull the same rigid control like everyone else. The only thing I can think of its that they are run by old fuddy-duddys that are out of touch with the world since the last time they actually worked in an organization before making their own, so they keep the old outdated practices that were in place that they remember and are afraid to evolve.

Let me ask you this ObiWan and other developers, kudos to you if you can answer this without searching for it but how long is 5 9's uptime? How long is 4 9's uptime? If you don't know, then reflect on that, it means you don't deal with the ops side too much and instead deal with dev, which is totally fine but the distinction needs to be made. Your job is to get as much code out which passes the unit and QA tests before the sprint ends. My job is to make sure we meet or exceed every internal and external SLA (documented or not), to be the guardian of the data, and to keep things running fast. I'm hoping "DevOps" within 5 years helps with this issue.

I'm a DBA for a very good tech company, we all make mistakes and grow, myself included. I love our developers and it's a real pleasure working with them, I genuinely mean that.

However you should see the absolute crazy sh*t I see when we let devs run wild and free... oh my dear God... the horrors I've seen. You don't understand, it cost the company A LOT of money, wasted time, opened us to lawsuits, and so fourth.

Someone needs to think about operations whom isn't tied to getting the release out as fast as possible to making the sprint. I'm sorry if that comes out as being paranoid but there is no 'undo' button for the DB, and changes are very hard to make if the table gets very large and it's a 24/7 shop. You can't just swap out the webconfig files or bring down the webserver from the farm (in DBs you don't really get to scale out writes in a farm, only reads).

Here are some nuggets I've seen in my career: -Unencrypted EXTREMELY sensitive data not just for a user, but for entire extra sensitive government agencies on a public facing database that we proved was susceptible to SQL injection. I can't get in the details, but if someone were to have gotten that data, there would be an international shit storm which would make the global news circuit. The developers didn't think 'jee maybe we should encrypt this'. The DBA's had to create a shit storm. I was almost ready to resign if they didn't make the change due to the fact that I didn't want to be the Ops DBA who was in charge of that system. No thanks. Not on my watch. I'm sorry if it means your development time takes 2x as long, but that's either your bad, your managers bad, or the architects mistake who didn't think 'DRRRR how about actually protecting the customers data?'

-Developers using the SSMS (SQL Management Studio) 'script' button to change column info... too bad SSMS populates the data in a temp table, drops the table, and recreates it. Now imagine doing this on a table that gets up to 5k transactions per second.... or on a 1 TB table... yea.... do you like 5 9's uptime? Well, you don't have it now!

-Developers demanding write access to QA and Prod. Are you guys who ask for this high as hell??? We refresh it from prod for each sprint and mask the sensitive data. What the heck makes you think you need write access to prod and QA??? QA owns QA, not the developers. The ONLY way I would like QA or anyone to write to the QA environment is through deployment tools. Why am I such a prick? Because they will go in, change values to make a test pass, and then when it hits prod it breaks something because guess what, changing the values needed was never part of the deployment script. If another developer (besides one that plays the role of prod debugger or release manager) asks me for full access to prod I swear to God I will cut them. Do the developers measure downtime though? NOPE! Not their concern.

-Does your code have NOLOCK everywhere? Well, a DBA needs to step in who understands isolation levels and solves the problem there. I've seen developers that all of their code has NOLOCK on it, even on writes! I ask them 'hey do you care about dirty reads in this app/code' and sometimes they look at me with a blank face like 'huh, what is that?'. Oh yea, I guess that would be bad. To be fair, a lot of times they absolutely know what they're doing but it's the few times they don't that ruin it for everyone else.

There's more I can go through but this should be a good starting sample.

***Remember, we all make mistakes and learn

2013-11-19 Reply Admin

TRWTF is that climbing+fishing+photography should be 7, not 5. 5 should be climbing+fishing. Dancing+photography should be 10 (or whatever dancing is plus 2).

The DBA isn't so smart after all, he doesn't understand binary.

2013-11-19 Reply Admin

Nagesh:
Dilligaf:
Jeff Grigg:
Wikipedia URLs are considered SPAM on this site?!?!?
How's that for a WTF?!?!?!?

Like a Ninja in the night, Jeff Grigg noticed that whenever he tried to post Wikipedia URLs to his favourite website "Worse Than Fail", they were marked as SPAM by the redoubtable akismet engine (aka SKYNET).

"This is why we can't have nice things in the comments" spat Gertrude, Jeff's dominatrix and bridge partner.

Jeff felt his temper flare. "Fuck you akismet!!!" he cried. While Jeff knew The Book of Five Rings told him there would be hardshipss as he fought dragons, monsters, and Nagesh , this latest pain was just too much.

Why you calling my name?

You have something against http://en.wikipedia.org/wiki/Dominatrix or http://en.wikipedia.org/wiki/Contract_bridge?

2013-11-19 Reply Admin

galgorah:
... Keep in mind a star schema would be a terrible choice for a transaction system. Buts its a great one for Analytical systems.

The system in the story appears to be a transactional/operational system, not a reporting system.

And how's a plus-delimited set of codes going to work in a reporting system? And what's its performance going to be, given that each plus-delimited value is effectively a foreign key?

dkf · 2013-11-19 Reply Admin

Geoff:
lets them really tease performance out of a database engine

“Hey! Oracle! Your daddy is an asshole and your mummy blows goats for money!”

“I'll show you! Just for that I'll give you thirty more transactions per second!”

2013-11-19 Reply Admin

dkf:
Geoff:
lets them really tease performance out of a database engine
“Hey! Oracle! Your daddy is an asshole and your mummy blows goats for money!”
“I'll show you! Just for that I'll give you thirty more transactions per second!”

I don't know about THAT, but I do know that database has some SERIOUSLY tall hair!

http://ushairstyles.com/wp-content/uploads/2011/08/Big-hairstyles.jpg

This is not spam.

2013-11-19 Reply Admin

TGV:
yojin:
Worked on a system a few years ago where they eschewed a many to many relation ship with this technique. Except it was a string that looked like "YYYNNYNYYNNNYNYYYNYNYYNYYYYNNNNNNNNNNNN"
I think it's not as crazy as it looks. It's easier to read, write and retrieve than a bunch of id-to-id relations, and it's also pretty efficient. It's not easy to query, and certainly not efficiently, but that seems much less of a problem.

What you just said is "Since I, as a human, has a hard time reading structures intended for machines the data structures should be made harder for the machines to read. And all code surrounding the data structure be made orders of magnitude more complex and error prone" ... Doesnt sound like a terribly good tradeoff to me.

galgorah · 2013-11-19 Reply Admin

Gertrude:
galgorah:
... Keep in mind a star schema would be a terrible choice for a transaction system. Buts its a great one for Analytical systems.
The system in the story appears to be a transactional/operational system, not a reporting system.
And how's a plus-delimited set of codes going to work in a reporting system? And what's its performance going to be, given that each plus-delimited value is effectively a foreign key?

I was speaking in more general terms in regards to the person who mentioned anti-normalization. Not for the specific design mentioned in the article.

I agree that its a terrible design thats mentioned in the article. But my real point was that design should match the purpose of the system. Not just be a knee Jerk everything should be normalized.

galgorah · 2013-11-19 Reply Admin

Mr. AHole DBA Man:

Let me ask you this ObiWan and other developers, kudos to you if you can answer this without searching for it but how long is 5 9's uptime? How long is 4 9's uptime? If you don't know, then reflect on that, it means you don't deal with the ops side too much and instead deal with dev, which is totally fine but the distinction needs to be made. Your job is to get as much code out which passes the unit and QA tests before the sprint ends. My job is to make sure we meet or exceed every internal and external SLA (documented or not), to be the guardian of the data, and to keep things running fast. I'm hoping "DevOps" within 5 years helps with this issue.

I'm a DBA for a very good tech company, we all make mistakes and grow, myself included. I love our developers and it's a real pleasure working with them, I genuinely mean that.

However you should see the absolute crazy sh*t I see when we let devs run wild and free... oh my dear God... the horrors I've seen. You don't understand, it cost the company A LOT of money, wasted time, opened us to lawsuits, and so fourth.

Someone needs to think about operations whom isn't tied to getting the release out as fast as possible to making the sprint. I'm sorry if that comes out as being paranoid but there is no 'undo' button for the DB, and changes are very hard to make if the table gets very large and it's a 24/7 shop. You can't just swap out the webconfig files or bring down the webserver from the farm (in DBs you don't really get to scale out writes in a farm, only reads).

Here are some nuggets I've seen in my career: -Unencrypted EXTREMELY sensitive data not just for a user, but for entire extra sensitive government agencies on a public facing database that we proved was susceptible to SQL injection. I can't get in the details, but if someone were to have gotten that data, there would be an international shit storm which would make the global news circuit. The developers didn't think 'jee maybe we should encrypt this'. The DBA's had to create a shit storm. I was almost ready to resign if they didn't make the change due to the fact that I didn't want to be the Ops DBA who was in charge of that system. No thanks. Not on my watch. I'm sorry if it means your development time takes 2x as long, but that's either your bad, your managers bad, or the architects mistake who didn't think 'DRRRR how about actually protecting the customers data?'

-Developers using the SSMS (SQL Management Studio) 'script' button to change column info... too bad SSMS populates the data in a temp table, drops the table, and recreates it. Now imagine doing this on a table that gets up to 5k transactions per second.... or on a 1 TB table... yea.... do you like 5 9's uptime? Well, you don't have it now!

-Developers demanding write access to QA and Prod. Are you guys who ask for this high as hell??? We refresh it from prod for each sprint and mask the sensitive data. What the heck makes you think you need write access to prod and QA??? QA owns QA, not the developers. The ONLY way I would like QA or anyone to write to the QA environment is through deployment tools. Why am I such a prick? Because they will go in, change values to make a test pass, and then when it hits prod it breaks something because guess what, changing the values needed was never part of the deployment script. If another developer (besides one that plays the role of prod debugger or release manager) asks me for full access to prod I swear to God I will cut them. Do the developers measure downtime though? NOPE! Not their concern.

-Does your code have NOLOCK everywhere? Well, a DBA needs to step in who understands isolation levels and solves the problem there. I've seen developers that all of their code has NOLOCK on it, even on writes! I ask them 'hey do you care about dirty reads in this app/code' and sometimes they look at me with a blank face like 'huh, what is that?'. Oh yea, I guess that would be bad. To be fair, a lot of times they absolutely know what they're doing but it's the few times they don't that ruin it for everyone else.

There's more I can go through but this should be a good starting sample.

***Remember, we all make mistakes and learn

As most know here, I'm also a DBA and a former developer.

Developers have to learn a myriad of different technologies constantly. So it can be hard for them to dig into things such as isolation levels, or internals. It's really part of our job as a DBA to work with them to help them understand the platform. Its also our job to understand their needs and pain points. Yes some stuff we have to say no to. But I always try to help them figure a better way out.

I do monthly lunch and learns as well. The company pays for lunch and I teach an hour long session on topics like indexing, partitioning, SQL Server internals, execution plans, etc. I'll even take stuff they are struggling with and we can do a session more focused on that issue. And it helps. Plus I encourage the developers to do the same. I'll attend their sessions. I want to see what insights they have and what they can teach me.

As for the the worst stuff I've seen, how about a 400 column table all varchar(max) with a billion rows and no indexes. Or how about the trigger on a table with 3 levels of nested cursors, updating million row tables at each level....

Bottom line, your right, we have to work with the developers not against them. But at the same time balance that with safety for the company.

chubertdev · 2013-11-19 Reply Admin

Mr. AHole DBA Man:
ObiWayneKenobi:
I've noticed that generally DBAs are over protective. They're extremely paranoid people that are afraid to relinquish any bit of control to anyone other than themselves. And organizations tend to be extremely paranoid as well, fearing anything that might let someone WHOM THEY HIRED do something that isn't specifically detailed in some manifest somewhere. This also tends to lead to nonsense like tracking each and every specific change that someone does, to the extent of even tracking when someone views a record, because they're so paranoid that somebody might change something instead of oh I don't know, trusting people they employ.
it's not always large companies, either. I've seen an increasing amount of smaller organizations trying to pull the same rigid control like everyone else. The only thing I can think of its that they are run by old fuddy-duddys that are out of touch with the world since the last time they actually worked in an organization before making their own, so they keep the old outdated practices that were in place that they remember and are afraid to evolve.

Let me ask you this ObiWan and other developers, kudos to you if you can answer this without searching for it but how long is 5 9's uptime? How long is 4 9's uptime? If you don't know, then reflect on that, it means you don't deal with the ops side too much and instead deal with dev, which is totally fine but the distinction needs to be made. Your job is to get as much code out which passes the unit and QA tests before the sprint ends. My job is to make sure we meet or exceed every internal and external SLA (documented or not), to be the guardian of the data, and to keep things running fast. I'm hoping "DevOps" within 5 years helps with this issue.

I'm a DBA for a very good tech company, we all make mistakes and grow, myself included. I love our developers and it's a real pleasure working with them, I genuinely mean that.

However you should see the absolute crazy sh*t I see when we let devs run wild and free... oh my dear God... the horrors I've seen. You don't understand, it cost the company A LOT of money, wasted time, opened us to lawsuits, and so fourth.

Someone needs to think about operations whom isn't tied to getting the release out as fast as possible to making the sprint. I'm sorry if that comes out as being paranoid but there is no 'undo' button for the DB, and changes are very hard to make if the table gets very large and it's a 24/7 shop. You can't just swap out the webconfig files or bring down the webserver from the farm (in DBs you don't really get to scale out writes in a farm, only reads).

Here are some nuggets I've seen in my career: -Unencrypted EXTREMELY sensitive data not just for a user, but for entire extra sensitive government agencies on a public facing database that we proved was susceptible to SQL injection. I can't get in the details, but if someone were to have gotten that data, there would be an international shit storm which would make the global news circuit. The developers didn't think 'jee maybe we should encrypt this'. The DBA's had to create a shit storm. I was almost ready to resign if they didn't make the change due to the fact that I didn't want to be the Ops DBA who was in charge of that system. No thanks. Not on my watch. I'm sorry if it means your development time takes 2x as long, but that's either your bad, your managers bad, or the architects mistake who didn't think 'DRRRR how about actually protecting the customers data?'

-Developers using the SSMS (SQL Management Studio) 'script' button to change column info... too bad SSMS populates the data in a temp table, drops the table, and recreates it. Now imagine doing this on a table that gets up to 5k transactions per second.... or on a 1 TB table... yea.... do you like 5 9's uptime? Well, you don't have it now!

-Developers demanding write access to QA and Prod. Are you guys who ask for this high as hell??? We refresh it from prod for each sprint and mask the sensitive data. What the heck makes you think you need write access to prod and QA??? QA owns QA, not the developers. The ONLY way I would like QA or anyone to write to the QA environment is through deployment tools. Why am I such a prick? Because they will go in, change values to make a test pass, and then when it hits prod it breaks something because guess what, changing the values needed was never part of the deployment script. If another developer (besides one that plays the role of prod debugger or release manager) asks me for full access to prod I swear to God I will cut them. Do the developers measure downtime though? NOPE! Not their concern.

-Does your code have NOLOCK everywhere? Well, a DBA needs to step in who understands isolation levels and solves the problem there. I've seen developers that all of their code has NOLOCK on it, even on writes! I ask them 'hey do you care about dirty reads in this app/code' and sometimes they look at me with a blank face like 'huh, what is that?'. Oh yea, I guess that would be bad. To be fair, a lot of times they absolutely know what they're doing but it's the few times they don't that ruin it for everyone else.

There's more I can go through but this should be a good starting sample.

***Remember, we all make mistakes and learn

TRWTF is you having high standards for your work, yet you are employed by a company that will hire anyone. And so fifth.

2013-11-19 Reply Admin

Paul Neumann:
Krunt:
Because DBAs shouldn't be developing, designing, or architecting programming solutions. They should be administering databases, tuning queries and indexes, monitoring storage and assisting devs where necessary. I'd much sooner hire a DBA who knows the ins and outs of SQL backup than one who (thinks he) knows the finer points of a join statement.
Let me know how that works out once you figure out how to avoid the self-contradiction.
Let management dictate the WHAT, let the dev develop the logical HOW, let the dba administer HOW the data which needs persisted is. This should indicate a close relation between dev and dba. (And contention with management.)

Your borderline non-sensical response notwithstanding, it works out pretty darn well at my organisation thanks. Our DBAs are capable of programming but that isn't their job role - it's to keep our database servers running smoothly. As far as contradiction goes, there aren't any - they assist developers where necessary if a query isn't performant and either needs a new index, different storage strategy, or a rethink of its structure to take advantage of what's already there. There is a close relationship between them and the programmers, yes, but each side knows their place and there is no contention between them or management as a result.

We tend to prefer it that way, you may prefer to have contention between your DBAs/devs and management; but hey whatever works for you, dude.

2013-11-19 Reply Admin

m:
It's not THE Network, it's just Network.
Glad I'm not the only one who noticed the coincidence of Luigi and a Martinet.

Why don't you read me!

2013-11-19 Reply Admin

Brompot:
TRWTF is that climbing+fishing+photography should be 7, not 5. 5 should be climbing+fishing. Dancing+photography should be 10 (or whatever dancing is plus 2).
The DBA isn't so smart after all, he doesn't understand binary.

It's not binary. There's a one-to-one correspondence between the users table and the hobbies table. If you want to add another user whose hobbies are climbing, fishing, and photography, you'd have to store:

int_id = 6 str_hobbyies = climbing+fishing+photography

If one of them wanted to take up basejumping, you'd just add "+basejumping" at the end of that user's row in the hobbyies table, and then their str_hobbyies values wouldn't be identical any longer.

2013-11-19 Reply Admin

chubertdev:
Mr. AHole DBA Man:
ObiWayneKenobi:
I've noticed that generally DBAs are over protective. They're extremely paranoid people that are afraid to relinquish any bit of control to anyone other than themselves. And organizations tend to be extremely paranoid as well, fearing anything that might let someone WHOM THEY HIRED do something that isn't specifically detailed in some manifest somewhere. This also tends to lead to nonsense like tracking each and every specific change that someone does, to the extent of even tracking when someone views a record, because they're so paranoid that somebody might change something instead of oh I don't know, trusting people they employ.
it's not always large companies, either. I've seen an increasing amount of smaller organizations trying to pull the same rigid control like everyone else. The only thing I can think of its that they are run by old fuddy-duddys that are out of touch with the world since the last time they actually worked in an organization before making their own, so they keep the old outdated practices that were in place that they remember and are afraid to evolve.

Let me ask you this ObiWan and other developers, kudos to you if you can answer this without searching for it but how long is 5 9's uptime? How long is 4 9's uptime? If you don't know, then reflect on that, it means you don't deal with the ops side too much and instead deal with dev, which is totally fine but the distinction needs to be made. Your job is to get as much code out which passes the unit and QA tests before the sprint ends. My job is to make sure we meet or exceed every internal and external SLA (documented or not), to be the guardian of the data, and to keep things running fast. I'm hoping "DevOps" within 5 years helps with this issue.

I'm a DBA for a very good tech company, we all make mistakes and grow, myself included. I love our developers and it's a real pleasure working with them, I genuinely mean that.

However you should see the absolute crazy sh*t I see when we let devs run wild and free... oh my dear God... the horrors I've seen. You don't understand, it cost the company A LOT of money, wasted time, opened us to lawsuits, and so fourth.

Someone needs to think about operations whom isn't tied to getting the release out as fast as possible to making the sprint. I'm sorry if that comes out as being paranoid but there is no 'undo' button for the DB, and changes are very hard to make if the table gets very large and it's a 24/7 shop. You can't just swap out the webconfig files or bring down the webserver from the farm (in DBs you don't really get to scale out writes in a farm, only reads).

Here are some nuggets I've seen in my career: -Unencrypted EXTREMELY sensitive data not just for a user, but for entire extra sensitive government agencies on a public facing database that we proved was susceptible to SQL injection. I can't get in the details, but if someone were to have gotten that data, there would be an international shit storm which would make the global news circuit. The developers didn't think 'jee maybe we should encrypt this'. The DBA's had to create a shit storm. I was almost ready to resign if they didn't make the change due to the fact that I didn't want to be the Ops DBA who was in charge of that system. No thanks. Not on my watch. I'm sorry if it means your development time takes 2x as long, but that's either your bad, your managers bad, or the architects mistake who didn't think 'DRRRR how about actually protecting the customers data?'

-Developers using the SSMS (SQL Management Studio) 'script' button to change column info... too bad SSMS populates the data in a temp table, drops the table, and recreates it. Now imagine doing this on a table that gets up to 5k transactions per second.... or on a 1 TB table... yea.... do you like 5 9's uptime? Well, you don't have it now!

-Developers demanding write access to QA and Prod. Are you guys who ask for this high as hell??? We refresh it from prod for each sprint and mask the sensitive data. What the heck makes you think you need write access to prod and QA??? QA owns QA, not the developers. The ONLY way I would like QA or anyone to write to the QA environment is through deployment tools. Why am I such a prick? Because they will go in, change values to make a test pass, and then when it hits prod it breaks something because guess what, changing the values needed was never part of the deployment script. If another developer (besides one that plays the role of prod debugger or release manager) asks me for full access to prod I swear to God I will cut them. Do the developers measure downtime though? NOPE! Not their concern.

-Does your code have NOLOCK everywhere? Well, a DBA needs to step in who understands isolation levels and solves the problem there. I've seen developers that all of their code has NOLOCK on it, even on writes! I ask them 'hey do you care about dirty reads in this app/code' and sometimes they look at me with a blank face like 'huh, what is that?'. Oh yea, I guess that would be bad. To be fair, a lot of times they absolutely know what they're doing but it's the few times they don't that ruin it for everyone else.

There's more I can go through but this should be a good starting sample.

***Remember, we all make mistakes and learn

TRWTF is you having high standards for your work, yet you are employed by a company that will hire anyone. And so fifth.

Because the work of a few developers, in a company with hundreds of talented people means the company is horrible, clearly! Nope, I'll enjoy our amazing growth working with engineers that teach me amazing new things everyday.

I'm sure every single developer you've worked with hasn't made any mistakes though! Must be nice to live in fantasy land.

chubertdev · 2013-11-19 Reply Admin

Mr. AHole DBA:
<Feeds the nice troll a cookie and pats him on his head>
Because the work of a few developers, in a company with hundreds of talented people means the company is horrible, clearly! Nope, I'll enjoy our amazing growth working with engineers that teach me amazing new things everyday.

I'm sure every single developer you've worked with hasn't made any mistakes though! Must be nice to live in fantasy land.

I've never worked with a DBA that would make the same mistakes as the co-workers at your company, so have fun thinking that it's worth it.

Nagesh · 2013-11-19 Reply Admin

I have worked with many DBA and all of them were painful to work with. Final I discover Hibernate and big-data and life is not require use of DBA anymore.

Happy developer = delightful end user. DBA now out of picture.

also another word for dba is "din bhar aaram"

2013-11-19 Reply Admin

chubertdev:
Mr. AHole DBA:
<Feeds the nice troll a cookie and pats him on his head>
Because the work of a few developers, in a company with hundreds of talented people means the company is horrible, clearly! Nope, I'll enjoy our amazing growth working with engineers that teach me amazing new things everyday.

I'm sure every single developer you've worked with hasn't made any mistakes though! Must be nice to live in fantasy land.

I've never worked with a DBA that would make the same mistakes as the co-workers at your company, so have fun thinking that it's worth it.

Yet you completely failed reading comprehension or critical thinking in this matter. I never said the DBA's made that mistake, a couple of web devs in a company with hundreds of engineers did. We use C++, Java (big data mostly), Django, .Net, and a slew of other tools. If you want to project that to an entire company, go right ahead, please!

You see, I've seen my stock options grow more than 5x, the company has grown tremendously with infrasturcture and customers and we're one of the top rated companies in several lists by leading groups (such as Deloitte). I will be MORE THAN HAPPY not to work with jerks :)

Our guys who code the back end, and even many of our web devs to a degree, are absolutely amazing and humble. We support each other and the company flurishes without the 'ahole developer ego' so many people get.

I am very happy not having you here and guys with your attitude that poison an entire department are thrown out quickly.

Good luck with your career!!

2013-11-19 Reply Admin

Nagesh:
I have worked with many DBA and all of them were painful to work with. Final I discover Hibernate and big-data and life is not require use of DBA anymore.
Happy developer = delightful end user. DBA now out of picture.

also another word for dba is "din bhar aaram"

I can't tell if you're trolling or really that inexperienced. I'm pretty sure the DBAs you worked with also consider you very painful, if you're not trolling.

Hibernate is a XML ORM with some ANSI 92 compliant SQL to query it. Big Data is a totally different beast not really used for transaction systems and up to the minute reporting, even with MS BigTable or Google Elastic Search.

These are NOT SQL Server. If you were using SQL Server to try to solve these issues you are doing it wrong. We use SQL Server to roll up the summary data that comes out of our big data systems, to provide transaction system support that requires full ACID compliance, and various other features.

Thank you Nagesh but it would be AWESOME if you never needed to work with a DBA, we all would breathe a collective sigh of relief.

chubertdev · 2013-11-19 Reply Admin

Mr. AHole DBA:
chubertdev:
Mr. AHole DBA:
<Feeds the nice troll a cookie and pats him on his head>
Because the work of a few developers, in a company with hundreds of talented people means the company is horrible, clearly! Nope, I'll enjoy our amazing growth working with engineers that teach me amazing new things everyday.

I'm sure every single developer you've worked with hasn't made any mistakes though! Must be nice to live in fantasy land.

I've never worked with a DBA that would make the same mistakes as the co-workers at your company, so have fun thinking that it's worth it.

Yet you completely failed reading comprehension or critical thinking in this matter. I never said the DBA's made that mistake, a couple of web devs in a company with hundreds of engineers did. We use C++, Java (big data mostly), Django, .Net, and a slew of other tools. If you want to project that to an entire company, go right ahead, please!

You see, I've seen my stock options grow more than 5x, the company has grown tremendously with infrasturcture and customers and we're one of the top rated companies in several lists by leading groups (such as Deloitte). I will be MORE THAN HAPPY not to work with jerks :)

Our guys who code the back end, and even many of our web devs to a degree, are absolutely amazing and humble. We support each other and the company flurishes without the 'ahole developer ego' so many people get.

I am very happy not having you here and guys with your attitude that poison an entire department are thrown out quickly.

Good luck with your career!!

So your company locks down systems to limit what the web devs can do when developing database code? Brilliant!

You're the personification of what ObiWayneKenobi was talking about, and you're probably a disease to your company.

2013-11-19 Reply Admin

chubertdev:
Mr. AHole DBA:
chubertdev:
Mr. AHole DBA:
<Feeds the nice troll a cookie and pats him on his head>
Because the work of a few developers, in a company with hundreds of talented people means the company is horrible, clearly! Nope, I'll enjoy our amazing growth working with engineers that teach me amazing new things everyday.

I'm sure every single developer you've worked with hasn't made any mistakes though! Must be nice to live in fantasy land.

I've never worked with a DBA that would make the same mistakes as the co-workers at your company, so have fun thinking that it's worth it.

Yet you completely failed reading comprehension or critical thinking in this matter. I never said the DBA's made that mistake, a couple of web devs in a company with hundreds of engineers did. We use C++, Java (big data mostly), Django, .Net, and a slew of other tools. If you want to project that to an entire company, go right ahead, please!

You see, I've seen my stock options grow more than 5x, the company has grown tremendously with infrasturcture and customers and we're one of the top rated companies in several lists by leading groups (such as Deloitte). I will be MORE THAN HAPPY not to work with jerks :)

Our guys who code the back end, and even many of our web devs to a degree, are absolutely amazing and humble. We support each other and the company flurishes without the 'ahole developer ego' so many people get.

I am very happy not having you here and guys with your attitude that poison an entire department are thrown out quickly.

Good luck with your career!!

So your company locks down systems to limit what the web devs can do when developing database code? Brilliant!

You're the personification of what ObiWayneKenobi was talking about, and you're probably a disease to your company.

Oh God, more reading comprehension failure. How hard is it for you to read?? You're a freaking developer for Gods sake, you're supposed to be able to read properly and follow logical steps, I want to stab my eyes out.

Let me make it clear for you: I stated Devs wanting full access to QA, not Dev. I give my developers many methods to build up/tear down dev environments to their hearts desire.

However, A developer could change something in the official QA environment to make a test pass without putting it through the proper release process, which means it will fail when it hits prod and QA will be liable for not catching it... for something a jerk developer who can't read or follow procedures did.

QA owns QA, not Dev. DBAs and release managers/prod debug get access to prod, NOT developers. I'm really sorry I care about data, proper and bug free releases (that uptime thing you don't seem to understand), value the companies brand image, and follow proper release procedures.

Actually my company highly values me, gave me 3 raises in 2 years, a 2nd set of stock options, and another one coming a month with another promotion! I LOVE IT. Don't be mad mr. developer that you can't break QA and Prod then have other people clean up your mess.

Subjugating cowboy devs like you who can't even exhibit proper reading comprehension (while being highly critical and judgmental) to proper SDLC is my joy and pleasure and I drink your tears like Agamemnon. MMMMMM. Developer tears!! YUM.

(However you developers and dev-ops folks that understand SDLC and care about the company, I love you all dearly, thank you for being you)

Nagesh · 2013-11-20 Reply Admin

Mr. AHole DBA:
Nagesh:
I have worked with many DBA and all of them were painful to work with. Final I discover Hibernate and big-data and life is not require use of DBA anymore.
Happy developer = delightful end user. DBA now out of picture.

also another word for dba is "din bhar aaram"

I can't tell if you're trolling or really that inexperienced. I'm pretty sure the DBAs you worked with also consider you very painful, if you're not trolling.

Hibernate is a XML ORM with some ANSI 92 compliant SQL to query it. Big Data is a totally different beast not really used for transaction systems and up to the minute reporting, even with MS BigTable or Google Elastic Search.

These are NOT SQL Server. If you were using SQL Server to try to solve these issues you are doing it wrong. We use SQL Server to roll up the summary data that comes out of our big data systems, to provide transaction system support that requires full ACID compliance, and various other features.

Thank you Nagesh but it would be AWESOME if you never needed to work with a DBA, we all would breathe a collective sigh of relief.

i am also avid reader of books from Mr Tom Kite. If you don't know who he is, please read oracle one on one.

the pain was caused to me because dba people refuse to give me access in development. i want to create db logon trigger in oracle. dba people say NO NO NO, three times.

i ask why? the true reason is FUD, as explained many times by Mr Kite of asktom.oracle.com

these dba make many test in production system, but not allow developer like me to create logon trigger. i realized it is useless to butt head with dba since my head is soft while dba wear helmet.

i already knowing that big data and rdbms are two different natures of beasts. i am happy that i am not working with rdbms system any more. my earlier foray into stored procedure went bad, so i learn hibernate and now stopped writing stored procedure codes totally. that saved me some time from dba ignorance, fear and doubt.

now i am no longer in hibernate, but just in bigdata.

chubertdev · 2013-11-20 Reply Admin

Nagesh:
Mr. AHole DBA:
Nagesh:
I have worked with many DBA and all of them were painful to work with. Final I discover Hibernate and big-data and life is not require use of DBA anymore.
Happy developer = delightful end user. DBA now out of picture.

also another word for dba is "din bhar aaram"

I can't tell if you're trolling or really that inexperienced. I'm pretty sure the DBAs you worked with also consider you very painful, if you're not trolling.

Hibernate is a XML ORM with some ANSI 92 compliant SQL to query it. Big Data is a totally different beast not really used for transaction systems and up to the minute reporting, even with MS BigTable or Google Elastic Search.

These are NOT SQL Server. If you were using SQL Server to try to solve these issues you are doing it wrong. We use SQL Server to roll up the summary data that comes out of our big data systems, to provide transaction system support that requires full ACID compliance, and various other features.

Thank you Nagesh but it would be AWESOME if you never needed to work with a DBA, we all would breathe a collective sigh of relief.

i am also avid reader of books from Mr Tom Kite. If you don't know who he is, please read oracle one on one.

the pain was caused to me because dba people refuse to give me access in development. i want to create db logon trigger in oracle. dba people say NO NO NO, three times.

i ask why? the true reason is FUD, as explained many times by Mr Kite of asktom.oracle.com

these dba make many test in production system, but not allow developer like me to create logon trigger. i realized it is useless to butt head with dba since my head is soft while dba wear helmet.

i already knowing that big data and rdbms are two different natures of beasts. i am happy that i am not working with rdbms system any more. my earlier foray into stored procedure went bad, so i learn hibernate and now stopped writing stored procedure codes totally. that saved me some time from dba ignorance, fear and doubt.

now i am no longer in hibernate, but just in bigdata.

Oh man, this is amusing.

2013-11-20 Reply Admin

large organizations are always like that. its probably they think that your poor and unable to clean up you own mess...

true elite best of the best, must always able to clean up their own mess.

2013-11-21 Reply Admin

John Max:
large organizations are always like that. its probably they think that your poor and unable to clean up you own mess...
true elite best of the best, must always able to clean up their own mess.

Dear God some of you devs harping on the DBAs for 'not giving you access to QA/Prod/etc.' are not helping your fellow co-workers.

MAYBE, just maybe it could have something to do with the fact that almost every single security compliance document such as SOX (you know, if you want to be publicly traded), PCI (if you want to accept credit cards), CIS, and a slew of others requires DEVELOPERS NOT TO HAVE ACCESS TO QA OR PROD, WITH FULL ENFORCEMENT OF SEPARATION OF DUTIES?

Do you think this is because large companies just love to create inefficiency or it's because giving devs access to prod could completely hose the system and cause massive amounts of revue and brand image loss?

Let me ask YOU devs something:

WHY the hell do you guys want access to prod and non dev environments SOOOO bad? I don't get why developers don't drop this ludicrous request. Here, I'll give you access to prod, but if you mess something up by not following proper procedures, I will take 6 months of your paycheck (and I'll know).

2013-11-25 Reply Admin

Generally because most code issues in a mature code-base are not code/logic errors but data issues (which may or may not have come about due to code/logic issues). Couple that with the following.

Our local environment (assuming we are lucky to get one) and development environments do not match production. They usually contain a subset of the data. This is usually a conscious choice since we can run scripts quickly and not have to worry about performance when trying to get it working.
The staging environment is usually rarely refreshed with the latest prod data. This is also a conscious choice since it will not match prod and QA/Other Developers and the like get annoyed when you blow it away while they are verifying their combined changes.

Quite often you get the above with the requirement to fix the issue quickly. Unless you can refresh staging or some other environment quickly (and in the case of very large databases that's not going to happen) its usually much faster to give the developer limited read access in Prod or UAT. They can then step through the issue work out what it is, then replicate in an environment they control and fix it.

I am all for not giving developers write access in Prod, and limiting their ability to read, but saying "no access for you" is rarely an effective way to deal with the problem. All issues should be fixed in the local/development environments but occasionally you do need limited production access. Please do not say that we can add logging around this as the last thing you want us to do is log sensitive data you have gone to so much effort to protect.

2013-12-04 Reply Admin

tragomaskhalos:
One of the best-kept secrets in IT is that any moderately competent developer, armed with a few Oracle books (or SQLServer, or whatever) and a modicum of common sense, will run rings around 98% of self-styled "DBAs" out there.

Oh, you so funny! I spend much of my time fixing up architecture and inefficient sql created by developers who don't understand set-based processing. So, tell me another one...

Control

Leave a comment on “Control”