October 5, 2016 at 7:23 am
Eric M Russell (10/5/2016)
It's important that the DBA be an integral team member. Include their database development and deployment tasks as part of sprint planning and invite them to daily stand-up meetings. Invite the DBA to lunch gathering while you're at it. If folks are just shooting the DBA emails with a .sql attchment and instructions like "Please deploy this in production by COB today.", then you can understand how they end up feeling disconnected and adversarial.
Yes, I think the biggest problem between the different professions in IT is that we place ourselves in camps. We should team up more and learn to know each other more then all the syndromes would not exist. We should all, despite our different professions, team up and together make for better working conditions. You know, we do not even have to stop there. I hear a lot of complaining, done some myself, about the users. What if we can be friends with ALL our colleagues? Well, some companies are just too big but we can at least be friends, or be friendly, with everybody we encounter in our daily work.
So, in stead of criticizing someone for using sub standard coding, let's give some positive comments to help that person to code better!! Live and let live!!!
Manie Verster
Developer
Johannesburg
South Africa
I am happy because I choose to be happy.
I just love my job!!!
October 5, 2016 at 9:12 am
Interesting article. This can happen, the king syndrome, in any position with a little (or more) power.
October 5, 2016 at 9:13 am
joshua 15769 (10/5/2016)
From a programmer's perspective, I'd say, anything that you'd want to use to communicate with the database should be "tested". Anything which would be new to the database (e.g. Triggers, SP, Views) should be "Proven and tested". But the DBA is not the problem, in my case, its the management. They don't want change yet they want to enhance things. They DBA says yes, programmers says yes, then management says NO, then to hell with your effort.
I agree with joshua. In my old job I wore both hats. (I honestly miss that.) However, in my current job I'm just a small cog in a much larger collection of DBAs, developers and business analysts. (Until I came to this job I hadn't even met a BA; didn't know what they did. Funny, all that time in the old job I was doing a BA's job without even knowing it.) In this job I'm a developer, but I work closely with the DBAs. Yes, they're a bit resistant to making changes, but I think they're as interested in good changes as anybody. It seems to me as though the resistance to changing anything comes from elsewhere. Its sort of faceless, in the sense that I know some of the players but not others. Any change is approved via committee. And some changes can sit in committee for many months.
Kindest Regards, Rod Connect with me on LinkedIn.
October 5, 2016 at 9:15 am
I think there's also Anti-DBA Syndrome. At a previous gig, I was ambushed by the SAN manager and the director saying to stop all SQL backups to the ERP system, which was around 150 gig and growing at a steady pace. All backups would be handled by Windows Whatever System Backup. So I did. They wouldn't acknowledge my points, so I had no choice.
After I was gone, they decided they didn't need a full-time DBA. Or any DBA, for that matter. They decided that the ERP vendor could monitor their systems just fine. Except the vendor didn't. On a different database backed up by Whatever (not the ERP system), the vendor failed to notice that corruption had crept in on little stealthy mousie feet, and that the backups were also failing. Then the SAN dropped a disk that part of the DB was on. Database go KABLOOEY! Multiple months of unpaid data was lost.
So go ahead and ignore your DBA's advice for having SQL do its own backups and DBCCs and to monitor them fastidiously. You get to explain to the city manager and mayor why data was lost, I really don't care.
It's a heck of a balancing act. DBAs deserve respect, but they also need to respect their developers and not knee-jerk block any new ideas or implementations. They need to defend their systems against stupidity, but ultimately their boss has the final say-so.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
October 5, 2016 at 9:34 am
Wayne West (10/5/2016)
...It's a heck of a balancing act. DBAs deserve respect, but they also need to respect their developers and not knee-jerk block any new ideas or implementations. They need to defend their systems against stupidity...
Certainly a two-way street. Fortunately, here we all seem prepared to walk in either direction. It is funny that those of us who appear to be driven self-learners are also the more amicable bunch too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 5, 2016 at 10:27 am
I just wish developers would show me the SQL code they are developing whether it is embedded in the application or as stored procedures or views before the application goes to testing and IPAT rather than me seeing it after it deploys into production at multiple sites where users complain because the code that worked in development/test/IPAT wasn't run against production levels of data or users.
October 5, 2016 at 10:47 am
Gary Varga (10/5/2016)
Wayne West (10/5/2016)
...It's a heck of a balancing act. DBAs deserve respect, but they also need to respect their developers and not knee-jerk block any new ideas or implementations. They need to defend their systems against stupidity...Certainly a two-way street. Fortunately, here we all seem prepared to walk in either direction. It is funny that those of us who appear to be driven self-learners are also the more amicable bunch too.
I agree with both statements above.
When you ask the DBA about a database decision and walk away thinking;
"He just said that because he as DBA syndrome. I know my way is right."
Who is really having a hard time taking off the ring of power in this parlay?
It does not sound like the DBA. You asked something and he gave a professional (hopefully) answer.
If you do not like it for any reason other than it was an incorrect unbiased answer then the fault is your own.
All the editorials in the world won't fix broken ears and eyes that can't see the truth.
:cool::Whistling:
October 5, 2016 at 10:53 am
Lynn Pettis (10/5/2016)
I just which developers would show me the SQL code they are developing whether it is embedded in the application or as stored procedures or views before the application goes to testing and IPAT rather than me seeing it after it deploys into production at multiple sites where users complain because the code that worked in development/test/IPAT wasn't run against production levels of data or users.
You just described every Deployment when I was DBA/Build Deployment Manager at my previous employer.
There was a huge issue with wWMDs (Works With My Dev Systems) there.
There was no testing prior to deployment to 700+ client systems except what the developer did on their local machines.
You can guess how many times this worked.
October 5, 2016 at 11:06 am
That's DevOops for ya. Development, Test, and QA databases (if they even exist) too small or under powered compared to production. And never synchronized with production. I lived that dream for a decade...
October 5, 2016 at 11:13 am
Like most workplace communication issues, this is a management issue. Most of the time, the people are hardworking and competent, but the incentives are wrong.
A DBA (and most other non-developer IT) is praised for keeping the system running and penalized for issues with performance, cost, stability, etc. Developers, on the other hand, are rewarded for delivering new features to the customer and penalized when those features are late. With these incentives, the following scenarios occur:
- DBA (only) is penalized because development deployed something with performance problems inherent in the design
- Development (only) is penalized because DBA is unreasonably delaying/denying deployment (justifiably fearing the above scenario)
While most people can ignore these kinds of structural disincentives, it's exhausting to do so repeatedly. People either settle for the status quo or find another place to work.
October 5, 2016 at 11:26 am
Lynn Pettis (10/5/2016)
I just wish developers would show me the SQL code they are developing whether it is embedded in the application or as stored procedures or views before the application goes to testing and IPAT rather than me seeing it after it deploys into production at multiple sites where users complain because the code that worked in development/test/IPAT wasn't run against production levels of data or users.
My personal pet peeve is when said developers try to troubleshoot, fail, then send an email that amounts to "shit be broke". I expect that from people outside of IT but seriously developers should know better.....
Bonus points if they also send links to articles/posts that have nothing to do with the actual problem.
October 5, 2016 at 11:40 am
RAThor (10/5/2016)
They are working 45 hours a week
So they're part-time? 😉
45 hours a day for me!
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
October 5, 2016 at 6:12 pm
Bonus points if they also send links to articles/posts that have nothing to do with the actual problem.
This, THIS! HAHAHA! In my last work place the management sends me "motivational" pictures and thing like "How to work positively" thingy. Then ends up deploying a system without even testing it! No presentation for the department concerned, no proper documentation, not even a beta test! HAHAHAHA!
October 5, 2016 at 8:23 pm
It's a funny thing... sometimes so called "DBA Syndrome" is the fault of the DBA. Sometimes it's actually because of "Developer Syndrome" like the one at a previous job that took his case straight up the chain of command when I refused to let his carefully written CLR go to production. He wrote a CLR to do a generic MODULUS and wasn't open to the idea of using the "%" operator because he had taken his code so far down the rabbit hole that it would cause a lot of rework on his part. I'm just not open to the idea of writing CLRs to replace built in functions.
I work on a team that has been practicing DevOps long before the term actually existed. I'm the DBA for my current company and I sit with the Developers. I also do 100% peer reviews for the WebDev team, use the peer reviews as time to mentor, and my virtual door is never closed to anyone that has a question. I do have to sometimes say "NO" to something but I'm normally able to suggest an alternative and the reason why the alternative is better. Most of the time, much of that happens before anyone writes any code because <drum roll please>, we're a team and we bounce ideas off of each other. I rely on the Developers and much as they rely on me.
The gate swings both ways, folks. The DBAs and the Developers both have jobs to do. The ONLY time things work well is when everyone realizes that there will sometimes be a conflict of interest and responsibility and that the end game is not personal but what's supposed to be good for the company that's paying us all ridiculous amounts of money to get it right for our customers without unnecessarily increasing risk for the company.
This is also why the extreme benefits of DevOps will not be realized by many companies. Everyone is living in their own little pond and has never looked at the ocean even if it's only a couple of feet away. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
October 6, 2016 at 12:19 am
Jeff Moden (10/5/2016)
...I do have to sometimes say "NO" to something but I'm normally able to suggest an alternative and the reason why the alternative is better...
I don't understand why people don't realise this is just an expanded process of what we all SHOULD be doing internally anyway.
I suspect most, if not all, of you will evaluate a few options before even considering discussing with anyone else. I doubt I would be alone in feeling annoyed when someone comes to ask your opinion without even attempting to evaluate and assess the problem and potential solutions. In my opinion, I would rather discuss possible alternatives with someone who thought about it but didn't come up with a solution than someone who could come up with a solution (appropriate or otherwise) but could not be bothered to try.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply