January 3, 2014 at 9:22 am
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.
January 3, 2014 at 9:23 am
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: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
January 3, 2014 at 10:20 am
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.
Steph Brown
January 3, 2014 at 11:25 am
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.
January 3, 2014 at 11:30 am
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.
January 3, 2014 at 12:56 pm
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
January 3, 2014 at 1:13 pm
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
Don't fear failure, fear regret.
January 3, 2014 at 1:43 pm
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
January 3, 2014 at 8:11 pm
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
January 5, 2014 at 11:12 am
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 on googles mail service
January 7, 2014 at 6:56 am
I'm a developer and an
- accidental
- pretend
- you are aren't you?
- you have to be there is no one else!
DBA
so I am always arguing with myself 😛
but I've not beat myself up yet 😀
Far away is close at hand in the images of elsewhere.
Anon.
Viewing 11 posts - 31 through 40 (of 40 total)
You must be logged in to reply to this topic. Login to reply