Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Breaking Down Barriers


Breaking Down Barriers

Author
Message
kiwood
kiwood
SSC Rookie
SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)SSC Rookie (48 reputation)

Group: General Forum Members
Points: 48 Visits: 86
george sibbald (1/3/2014)
....
a lot of posts talk about devs and dba working on the same team, whether that is possible will depend on the size of the organisation, the larger it is the more likely skills will be siloed and the DBAs more focused on production support than say code reviews. ......


While I have observed the same thing, I also have observed that this pushing of skills into silos is a huge contributor to the problem. In fact, it could be the root of the problem. It naturally pits the "sides" against each other since you look out for your own team. It externalizes the problems of the "other" guy. In this scenario if the DBA does (or allows) something that benefits the Developers at the cost of the DBAs, then said DBA is a traitor to the team. Putting them on the same team makes it sharing the pain. Neither wants to be an undue burden to the other.

Having a team of DBAs, a team of Developers, and a Support team leads to three way fighting. Common practice doesn't make it right, or even good.
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36204 Visits: 18751
Tony Bater (1/3/2014)
Education, communication, understanding: they are all critical in resolving this issue.

My DBA background was initially as a developer in FoxPro where the code and the database are deeply connected.


Me too. Maybe we should make more DBAs and developers work in FoxPro first w00t

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Stephanie J Brown
Stephanie J Brown
SSC Eights!
SSC Eights! (808 reputation)SSC Eights! (808 reputation)SSC Eights! (808 reputation)SSC Eights! (808 reputation)SSC Eights! (808 reputation)SSC Eights! (808 reputation)SSC Eights! (808 reputation)SSC Eights! (808 reputation)

Group: General Forum Members
Points: 808 Visits: 1103
I agree that silos are a big part of the underlying cause of friction, whether between DBAs and Developers and Project Managers or other "functions" within IT. And most of the good ideas about how to break down that friction have already been stated, although I'd suggest lunch as an alternative to beer (I don't like beer, so I'm at a disadvantage on that one Ermm ).

Over the course of my career I've worked Operations, Production Support, Development, DBA, Project Manager, Systems Analyst and Business Analyst. I've only occasionally run across an individual that was truly difficult to work with. The best advice I could give, based on what has worked for me, is to "be the change you want to see".

Want more respect? Act respectfully towards others. Need better communication? Check how you are communicating and look for ways to improve. Often we point out the faults in others to avoid seeing those same faults within ourselves (and yes, I include myself in this!)

I've noticed that when I'm complaining about the actions of someone else, nothing changes. Conversely, if instead I take action and change what I am doing, or I reach out to ask questions in a different way, the change percolates outward - sometimes with unexpected results.

I think this all boils down to: Take Action
Don't wait for the world to change. Go out and change it.


Here there be dragons...,

Steph Brown
Revenant
Revenant
SSCertifiable
SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)SSCertifiable (5.8K reputation)

Group: General Forum Members
Points: 5807 Visits: 4718
IMO the first condition for peace between us devs and DBAs is to give them sufficient lead time for any changes we want them to make.
brent.kremer
brent.kremer
Grasshopper
Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)

Group: General Forum Members
Points: 16 Visits: 181
I agree with the comments around organizational alignment. The further 2 people are from each other within the hierarchy, the less likely they are to understand each other's role. I think this has to do with the metrics our managers place on our work. If we share the same manager or senior manager then our goals should be similar. If we have to go up multiple chains of command before we share a common manager then our goals will be very different.

If the primary metric a DBA is measured on is availability then how does that align with a developer whose primary metric is delivering user requirements on time?

I have seen very little tension between developers and DBAs at my different jobs. I am typically happy to speak with somebody who comes close to understanding my issues. As a developer perhaps I don't hear the grumblings from DBAs in their circles. If I have issues with my business partners I try to let them know in as civilized way as possible. We typically do lessons learned meetings after large projects with our business analyst, project managers and technology partners to help improve our overall process.
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45203 Visits: 39925
andrew.morrell 67746 (1/3/2014)
DBAs and Developers are at times both purists but I find that developers tend to be a little more pragmatic in allowing some things to wait until a refactoring exercise.

For DBAs though it is a little different as they work a little more isolated from the end users and know that a mistake or shortcut early on can (and often will) lead to a serious time cost later on in reworking a schema.

Education is key so that both parties understand where each comes from. Decisions need to be made together and where necessary arbitrated by an architect or third person who is neither a dev or a DBA.

I am a dev though so maybe my impression is a little skewed?

More communication and less criticism is the key as we are all working to the same goal - aren't we?


That's why I sit right smack dab in the middle of the Dev Team and encourage them to ask me a question if they have any doubts about something they're working (and I'm close enough to everyone to overhear potential problems, as well). I also do 100% peer reviews that frequently turn into mentoring sessions, conduct "Lunch'n'Learn" training, and have published standards and "Tips'n'Tricks" published on the internal Wiki.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
below86
below86
SSChasing Mays
SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)SSChasing Mays (636 reputation)

Group: General Forum Members
Points: 636 Visits: 2121
Jeff Moden (1/3/2014)
..."Tips'n'Tricks" ....

Is there a place on this site where these type tips and tricks can/are posted? Under 'Scripts'? Or is there a place under the 'Forums'? Honestly I haven't looked yet, I don't know why I haven't thought of it. Crazy I know we (developers) here try to pass around and tips or tricks we learn to the entire group. But it is hard for everyone to keep track of these, we don't have our own WIKI site, there was talk at one time but as with a lot of things that would benefit us, it gets pushed back to meet the users demands.

-------------------------------------------------------------
we travel not to escape life but for life not to escape us
wolfkillj
wolfkillj
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1104 Visits: 2582
I am a database developer, and I have a great working relationship with the DBAs at my company. I think the DBAs and I respect each other because I have learned quite a bit about the challenges of administering and maintaining enterprise-scale databases and am always learning more. I can anticipate many of their concerns about my code and know when it's important to get their input on a project *before* development begins. They know that I'll understand and accept their explanations of the technical and policy concerns that govern their decisions and actions.

My role as a *database* developer gives me more time and reason to dig into the internal workings of SQL Server than most application developers, but I think even application developers can improve their working relationships with DBAs by learning more about the DBAs' responsibilities. One needn't know how to do the DBAs' job, only understand why they do the things they do. A good first step here is to *ask* them in a manner that demonstrates your interest in learning (*not* a combative tone that demands they justify themselves)!

Jason Wolfkill
Blog: SQLSouth
Twitter: @SQLSouth
Jeff Moden
Jeff Moden
SSC-Forever
SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)SSC-Forever (45K reputation)

Group: General Forum Members
Points: 45203 Visits: 39925
below86 (1/3/2014)
Jeff Moden (1/3/2014)
..."Tips'n'Tricks" ....

Is there a place on this site where these type tips and tricks can/are posted? Under 'Scripts'? Or is there a place under the 'Forums'? Honestly I haven't looked yet, I don't know why I haven't thought of it. Crazy I know we (developers) here try to pass around and tips or tricks we learn to the entire group. But it is hard for everyone to keep track of these, we don't have our own WIKI site, there was talk at one time but as with a lot of things that would benefit us, it gets pushed back to meet the users demands.



There's the "Stairways" Series of articles that go in depth on certain subjects but I suspect you want things a bit shorter and more direct than those (left side of the screen here on SQL Server Central). You would think that the "Scripts" section would be the place to look but I advise caution there. Those scripts aren't reviewed by a technical team and, just like anywhere else on the internet, some are excellent, some will kill your server, and the rest fall in varying degrees betwixt the two.

My recommendation would be to check on the articles of some of the "heavy hitters" on this forum and some of the many heavy hitters that post replies on the forums and add them to your "briefcase" which is located just above this window.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
TheSQLGuru
TheSQLGuru
SSCertifiable
SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)SSCertifiable (6K reputation)

Group: General Forum Members
Points: 5990 Visits: 8314
The VERY few times I have seen the entire IT stack (or even a significant fraction of it) really play well together and drive the company forward was when there was STRONG and INVOLVED leadership (all the way up to the C-level) that saw the value that such integration and meshing would bring to the company. If senior managers allowed (or heaven forbid ENCOURAGE) a "fiefdom" attitude to set in or exist then things would go down hill from there.

EVERYONE in a company must AT ALL TIMES remember they are just a cog in the machine whose ENTIRE and SOLE goal should be the improvement of the COMPANY's bottom line. And I don't mean the quarterly bottom line either, as almost all US-based companies worship.

Best,

Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru at GMail
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search