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 3, 2014 6:34 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: 2 days ago @ 5:21 AM
Points: 125, Visits: 661
I personally think the problem's a bit overstated.

As a developer I think I've probably butted heads with every DBA I've ever worked with and, as long as it remained professional, that was fine. Sometimes I had to give ground, sometimes they did. Usually we both did. We all still came in to work the next day and were good freinds again by the end the week because, despite a bit of stress in the moment, we achieved the goal and that really was what we both wanted.

I have worked with a very few genuinely hostile DBAs but anyone who's that hostile is also, by definition, also unprofessional. At that point it's really a problem for the HR department rather than us as an industry. And in the interests of even-handedness I should acknowledge that I've dealt with quite a few hostile developers as well. There's <insert profanity of choice here> in every walk of life. It's not a problem with our industry, it's a problem with a few individuals.

And if you think the relationship between devs and DBAs is bad you should see experience the relationship between the IT project manager and the combined heads of every other department in the business is like. Frankly you DBAs are kittens.

If you can't educate the other person, perhaps you need to educate yourself
That or you're not shouting at them loudly enough.
Post #1527489
Posted Friday, January 3, 2014 6:57 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, May 9, 2014 10:07 AM
Points: 7, Visits: 41
The first is to put them on the same team. Too often DEV, OPS, DBA, are all split. The most successful teams I have worked with, these teams are one and are responsible for a given set of products. They are all responsible for the product and sink or swim with the product. This generally makes the products more successful and removes the division the most IT shops face.
Post #1527509
Posted Friday, January 3, 2014 7:08 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 8:10 AM
Points: 2,581, Visits: 3,880
How to solve these issues:

1. Check your ego at the door.

2. Understand that the other has a job to do and to open your mind to their viewpoints.

3. For most of us, problems are not the end of the world. No one is perfect and mistakes will happen. Being angry about it does no good. Unless you are truly saving lives or are a rocket scientist, the problems we have are generally pretty tame.

4. Be open to learning new things.

5. Treat others as you wish to be treated.


Tom
Post #1527517
Posted Friday, January 3, 2014 7:13 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 12:17 PM
Points: 1,837, Visits: 2,180
mister.magoo (1/3/2014)
Hey, come on it's not the DBAs or the Programmers that are the problem, it's the Project Managers that we should be worried about, those good for nothing....


A grain of truth to this perhaps. Both roles tend to respond to the incentives, positive and negative of the environment they are in. "Get it done fast" tends to be the motivator for programmers in many environments. Where DBA's tend to be directed more to "Make sure we can get it done, now and forever".

The most important people to educate are those in charge, and the hardest to educate as well, it seems.

Still, I very much like the idea of each role having to walk a mile in the other's shoes. Most people are reasonable, on a good day. If they understand the ramifications of their actions, they tend to be willing to cooperate with the process a bit more.

The other solution would be to hire only DBA's, and then make some of them programmers. Seriously, I've found it easier for a DBA to be a good programmer, than the other way around. However, I'm sure there are those who would, and will, disagree.


Please don't go. The drones need you. They look up to you.
Connect to me on LinkedIn
Post #1527522
Posted Friday, January 3, 2014 7:40 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, August 18, 2014 10:02 AM
Points: 2, Visits: 196
I'm a developer who fell into the DBA role because we had no DBA. So for years I was 80% developer, 20% DBA, before I switched into full-time DBA. I think it's resulted in me being a more pragmatic DBA because I still remember what it's like to ship a release against a tight deadline. And honestly, I rather miss coding.

In the end, while I am responsible for the health of the servers and the integrity of the data, I believe my ultimate responsibility is to deliver solutions that enable the business to achieve their goals. And that sometimes means speed of project delivery over completely optimized database operations. I'd rather enable than obstruct.

In my limited experience, because I'm willing to help, developers who are weaker with T-SQL will seek me out and ask me to assist with complex queries. Those developers end up learning a lot about T-SQL and need less help in the future.

Have I let some queries go that make me cringe? Sure. But I also know that I've written some cringe-worthy queries in the past for code that had to be delivered quickly, and miraculously they didn't result in significant impact on database efficiency. So I have a lot of sympathy for developers who are under the gun.
Post #1527536
Posted Friday, January 3, 2014 7:47 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Saturday, September 20, 2014 11:37 AM
Points: 79, Visits: 753
As DBA's, you can't be the party of "No!". If you have to say "No", which is often, then say "Not exactly, but how about we do it like this instead..." *and* provide sample code. Devs love sample code, it's in a language that they speak fluently.

Most of the friction between the Devs and the DB team at my old place disappeared once both sides got together and agreed upon a set of coding patterns. When both teams have agreed on formal templates for tables, SPs, promotion-to-production scripts, initial lookup table population, and even emergency ad-hoc production updates it's actually funny watching the tribe enforce the policies and seeing the email threads scolding the occasional violators.



Post #1527544
Posted Friday, January 3, 2014 7:51 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, August 8, 2014 1:01 PM
Points: 61, Visits: 207
What’s worked really well for our small development team is having a development DBA as a part of the development team. Complex queries, stored procedures, etc are developed by DBA. The management of the project content inside the timelines are also handled by DBA so the application developers don’t get the feeling of an 'us versus them' relationship.
Post #1527546
Posted Friday, January 3, 2014 7:58 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, January 3, 2014 8:39 AM
Points: 74, Visits: 37
Developers need to write code, including SQL. Unless you have vast DBA resources, having a backlogged single resource write all SQL is impossible - if you intend to get any development done.

I am the manager, systems analyst, and the DBA. This is critical for our team's success. My goal is the same as theirs - to improve our systems and deliver to the end user what they ask for. While my day to day tasks are much different than the developer's, we have a common cause.

A DBA can't simply focus on making sure the data is safe and that performance is 100%. Yes, those and other concerns need to be kept in the forefront, but in the end - the DBA and developers are providing service to the same folks, for the same reasons.

End users get tired of hearing of turmoil between multiple factions in IT, there is no place for it. It is the managers job to make sure there is a common focus, with different tasks to do. It isn't us (DBA) against them (Developers), it is us (IT) servicing them (Everyone Else).
Post #1527551
Posted Friday, January 3, 2014 8:00 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Today @ 9:01 AM
Points: 288, Visits: 1,085
dan.tan (1/3/2014)
I'm a developer who fell into the DBA role because we had no DBA. So for years I was 80% developer, 20% DBA, before I switched into full-time DBA. I think it's resulted in me being a more pragmatic DBA because I still remember what it's like to ship a release against a tight deadline. And honestly, I rather miss coding.

In the end, while I am responsible for the health of the servers and the integrity of the data, I believe my ultimate responsibility is to deliver solutions that enable the business to achieve their goals. And that sometimes means speed of project delivery over completely optimized database operations. I'd rather enable than obstruct.

In my limited experience, because I'm willing to help, developers who are weaker with T-SQL will seek me out and ask me to assist with complex queries. Those developers end up learning a lot about T-SQL and need less help in the future.

Have I let some queries go that make me cringe? Sure. But I also know that I've written some cringe-worthy queries in the past for code that had to be delivered quickly, and miraculously they didn't result in significant impact on database efficiency. So I have a lot of sympathy for developers who are under the gun.


Well said, I agree as a developer. Some times I look at it as a DBA as the Monday morning quarterback. The DBA can look back over the work and maybe see what you did wrong or could have done better. But in the 'middle of the game' you do what you have to do to get the job done. We usually don't have the luxury of having enough time to go back through the code to 'fix' some of the bad code. And as others have stated when you develop the code against a smaller 'test' version of the data, or you have to make up your own data, the code you wrote at that time worked great, but when you get more data coming through it may be less efficient. No one can always write the most efficient code.

I also agree that it works better when the DBA is on the same team as the developers. And each of us, I include myself in this, need to check their ego's at the door.
Post #1527554
Posted Friday, January 3, 2014 8:03 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Yesterday @ 7:03 AM
Points: 27, Visits: 229
This is a very interesting question. Having been both a developer and now a DBA, I can see the arguement from both sides of the fence as well as the different pressures and requirements each job has. It is important to remember that we all have the same end goal. Fast, reliable, useful applications.

A short answer: beer. Go for a drink with the other team. Become people to each other. Learn why developers often rush out bad code thinking that we will fix in the next release. Learn why DBAs have to balance security, effciency, troubleshooting SQL code becauase every thing ends in a database, whilst keeping an eye on the detail and the bigger picture at the same time.

The long answer is much more complicated. However, I feel that the important thing for a DBA to remember is that we, as most of us who are in IT, are a support role. We support the databases, the data integrity, the developers (support them to write better SQL code) and the businesses we all work for. There are many ways in the SQL world to do a thing and sometimes someone elses way may be better than yours. We all have the same end goal, developers and DBA's alike. No one wants a slow unreliable application. Good luck everybody.
Post #1527557
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse