Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««12345»»»

Breaking Down Barriers Expand / Collapse
Author
Message
Posted Friday, January 03, 2014 8:13 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, February 27, 2014 4:44 PM
Points: 9, Visits: 12
I'm a strong proponent of drinking together and I say that both lightly and seriously. When we don't know anything about each other outside of work, it's too easy to put our frustrations with a DBA or developer into a box labeled as such and allow them to collect and ripen.

When we spend a little bit of time together outside the office, these coworkers pretty rapidly outgrow the boxes we've been using to identify them and soon we tend to give this DBA or developer *person* a little benefit of the doubt, a little leeway for being human. We find it's harder to criticize so harshly someone who shares a similar family situation, hobby, struggle, dream.

As long as this nonsense discontinues before we start enjoying our work together, I think we'll be OK.
Post #1527561
Posted Friday, January 03, 2014 8:27 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Tuesday, March 18, 2014 9:34 AM
Points: 60, Visits: 158
I'm fully in the integration camp. When Admin (DBA), Dev and Ops are siloed with poor communication you get the situation you describe in your editorial. However, if they are well integrated so that the DBA team functions with Dev and Ops on projects and has both input and understanding of the business goals and business processes being supported, things work out much better for everyone.

In general, we who do this kind of work, are on the more-communications-challenged end of the spectrum so teams and managers need to work to facilitate communication between individuals and groups. They also need to try to disarm resource-guarding within these groups:

-- DBAs don't want new (aka bad) code and data structures getting put up on domains they have to administer because it can cause serious heart burn for them. They already have their days full with their normal work load so new code pushes are just an added headache.
-- Developers are usually scrambling to meet tight deadlines with limited information and endlessly changing requirements. They're juggling a million details and the goal for them is to just get something that works (sort of) up for their user by the deadline. Good code is a stretch goal.
-- Ops very often has a full-time job just trying to fight fires that they have no control over quenching. Changes are not desired because change usually means that for sure something will go wrong and they'll be up at 3 am trying to figure out why and/or trying to find someone who can make it better.

Building partnerships and communication is the key. Teams that can focus on long-term gains rather than short-term pain is key. Doing that with the usual personalities of the tech/database world is the challenge!
Post #1527566
Posted Friday, January 03, 2014 8:28 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:49 PM
Points: 32,768, Visits: 14,929
andrew.morrell 67746 (1/3/2014)
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?


We're all skewed, but I think your last sentence is right.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1527567
Posted Friday, January 03, 2014 8:34 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, February 21, 2014 6:50 AM
Points: 34, Visits: 48
Speaking for myself, I've had the good fortune to come to my current job when the company was very small, so I had both the role of DBA and SQL Developer. There was some really ghastly code in SP's that I was able to quickly correct, having extraordinary gains in performance with very little effort.

That helped establish my credibility with my boss and the upper management. So, when we started to grow and hire more developers and a proper DBA, I was looked upon as an authority figure. That has helped me establish development policies and best practices that help the junior developers avoid the most common mistakes. We also conduct regular code review sessions that have helped me a lot (I always learn something, even from the most junior developer) and our development policies and best practices are regularly updated.

This situation has helped me grow professionally, while also helping all other developers grow.
Post #1527575
Posted Friday, January 03, 2014 8:37 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, January 07, 2014 7:03 AM
Points: 5, Visits: 8
I think the first thing is to make them on the same team with the same supervisor. For that matter, I think the division by function is bad for IT because it leads to the us against them attitudes.

If you really want to get them to work together then free enough DBA time to go with the developer to meetings on what needs to happen. Have them figure out together how to make things work.

Also, it helps if DBAs learn what developers sometimes do wrong and talk to them about it. For instance I have heard all kinds of blame thrown at Entity Framework. Where most of the problems are actually easy to fix by educating the developer in two areas:
1) bring it all back at once (ToList)
2) watch some queries since often the developer is used to case sensitivity in strings and sql is typically not sensitive
Post #1527579
Posted Friday, January 03, 2014 8:59 AM


UDP Broadcaster

UDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP BroadcasterUDP Broadcaster

Group: General Forum Members
Last Login: Today @ 8:10 AM
Points: 1,468, Visits: 4,269
How do we get DBAs, Developers, as well as sysadmins and Sharepoint administrators, to work closer together?

It helps to have cross-funtional team meetings.



"Winter Is Coming" - April 6, 2014
Post #1527593
Posted Friday, January 03, 2014 9:08 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:25 AM
Points: 5,847, Visits: 12,579
First of all congratulations to everyone, when I see this type of article I normally cringe, expecting a bun fight, but this one has not descended into name calling and stone throwing. so perhaps working relationships are improving out there.

Having said that...........

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. I understand why devs would love to have a DBA dedicated to their project but in a large organisation where a small team of DBAs support a large number of applications in production that is difficult, so this needs to be taken into account.

In terms of working together just be professional and sensible. I have only ever had problems with people who would have been awkward whatever the situation as its in their nature, and those are the only people who have ever had a problem with me.


---------------------------------------------------------------------

Post #1527602
Posted Friday, January 03, 2014 9:08 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 8:20 AM
Points: 4,862, Visits: 2,243
I worked on a project developing a system which could store in either SQL Server or Oracle. There were about 10 .NET developers, 1 SQL Server Dev DBA and 1 Oracle Dev DBA. Everyone was under pressure. Everyone was joked about. Everyone laughed. Crucially, everyone had mutual respect for one another.

My favourite aspect was that the development process for stored procedures (for various reasons) was the .NET developers wrote SQL Server stored procedures then the SQL Server and Oracle DBAs treated that as a requirement specification and evaluated each one (sometimes in conjunction with the .NET developer). The final stored procedures (1 for SQL Server, 1 for Oracle) were then published back to the .NET developer to work against.

This maximised the learning experience for the .NET developer (as changes by the DBAs were often explained) and allowed for rapid development without creating a molasses of maintenance trouble. Quality of SQL developed by the .NET developers improved over time.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1527604
Posted Friday, January 03, 2014 9:21 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:49 PM
Points: 32,768, Visits: 14,929
Yet Another DBA (1/3/2014)


One of the issue I come across is that some developers believe that writing a stored procedure or even a set based query will slow them down from cutting code and prevent them from bug fixing.


to me, this is a place DBAs can help. We can educate, and work with devs to show them how to write quicker, or offer to help them and get it done for them.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1527611
Posted Friday, January 03, 2014 9:21 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 1:49 PM
Points: 32,768, Visits: 14,929
gerardo.lima (1/3/2014)
One good way is to periodically put DBAs to work within a developers team and the reverse. For my experience, developers should not take SGDBs abstractions as granted and having a DBA on the team helps evaluating and anticipating real world behaviour of the code; likewise, DBAs would have a glimpse of the pressure and time constraints that are so common on developer teams and maybe this could lead to development of better (deployment, maintenance, ..) processes. Having developers working within a DBA team would teach the long term consequences of bad designed code and the pressure that these teams usually are so that things just work, no matter what.


I'd love to see this more often. We tried this once with ops and engineering in a large company, but it didn't stick long.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1527612
« Prev Topic | Next Topic »

Add to briefcase «««12345»»»

Permissions Expand / Collapse