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»»»

Developers vs. DBAs Expand / Collapse
Author
Message
Posted Thursday, June 12, 2014 5:19 AM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 2:00 PM
Points: 4,477, Visits: 3,929
I do both development and DBA activities, so I get to design it end-to-end. I don't have the conflict of developer versus DBA, as I pick the best tool for the job, and that tool is never an ORM because of the uber-inefficient code they produce.

I find the most conflict occurs when determining user requirements. The business side doesn't know what they want because the client doesn't know what they want. So, naturally, they want me to write something. Then they change it 45 times until they like it. Now it's in production and everyone's happy, up to the point where they want it to do something in a different way that was never even thought of. This continues in perpetuity for several years and then there's a large meeting of the minds where the business side actually takes the time to sit down and really think things through. Then a redesign happens with lots of hours (and therefore cost) being sunk into something. Voila! It now does exactly what everyone wants.

I think the trick is to get people to think it through before design starts. Everyone's in such a rush that they don't want to take the time to think it through the first time, but it sure does save a pile of time and money when it happens.



Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
Post #1579973
Posted Thursday, June 12, 2014 5:21 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Tuesday, November 11, 2014 11:28 AM
Points: 41, Visits: 383
Gary Varga (6/12/2014)
geoffrey.sturdy (6/12/2014)
No Gary - that's how things are - when you roll out changes you by their nature de-stabilise a system , ususally there is a good reason for doing so - hence the term "constructive de-stabilisation" , however a DBA's sucess is measured in uptime so there is a conflict as both sides measure sucess in a different manner - and I say this as having been a developer (back in the 1980s) and DBA in both Codasyl and relational databases - no offence to developers intended


So any roll out of changes by developers "by their nature de-stabilise a system".

But any roll out of changes DBAs "promote stability and reliability".

How on earth can that be anything but a generalisation that causes divides between two parties?


Increase in Change = Decrease in Stability is I think Geoffrey's point -- not that it is a ding against developers. In this case the DBA's when compared to the Dev's are like IT to the Business. The Business needs to change constantly and so development happens (with or without IT involvement; see Shadow IT). But IT is incentivized to keep the lights on and the trains running. Any change must be slow or it will be de-stabilizing and thus likely to hurt your up-time stats.
Post #1579974
Posted Thursday, June 12, 2014 5:33 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Wednesday, June 25, 2014 7:33 AM
Points: 27, Visits: 101
Tension arise when Developer and DBA roles/responsibilities are not properly separated.

If the company divides its employees into Developers and DBAs, it should also clearly separate their roles and responsibilities so there is no overlap.

- Developers design and implement applications.
- DBAs design and implement databases.

What this means in practise is that every database should have a well-defined stored procedure interface, and applications should use the stored procedures and should not directly access the tables within the database, either using Entity Framework or any other means.

When a new requirement comes along, the Developers and DBAs should get together and agree what database interface is required. The Developers can then go away and write the application code while the DBAs can go away and write the database stored procedures and if necessary extend or modify the database schema.

With this approach, Developers retain full control over the application design and DBAs retain full control over the database design, and both camps are happy.

It sounds simple because it is. Problems only arise when people forget the basic principles of software engineering, i.e. every component must have a well-defined interface, and users of a component must not bypass the interface or make any assumptions about how the component works internally.

Post #1579981
Posted Thursday, June 12, 2014 5:46 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, June 24, 2014 4:38 AM
Points: 7, Visits: 21
A little bit off topic there from Ed Wagner as requirements gathering is a can of worms best left of unopened in this thread. To those who see distinct clear definitions of each role there is always overlap that causes the conflict. The key resolving the conflict is to encourage communication and understanding. We manage these relationships despite the management rather because of them.
Post #1579988
Posted Thursday, June 12, 2014 5:56 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:46 AM
Points: 5,750, Visits: 3,672
scott mcnitt (6/12/2014)
Gary Varga (6/12/2014)
geoffrey.sturdy (6/12/2014)
No Gary - that's how things are - when you roll out changes you by their nature de-stabilise a system , ususally there is a good reason for doing so - hence the term "constructive de-stabilisation" , however a DBA's sucess is measured in uptime so there is a conflict as both sides measure sucess in a different manner - and I say this as having been a developer (back in the 1980s) and DBA in both Codasyl and relational databases - no offence to developers intended


So any roll out of changes by developers "by their nature de-stabilise a system".

But any roll out of changes DBAs "promote stability and reliability".

How on earth can that be anything but a generalisation that causes divides between two parties?


Increase in Change = Decrease in Stability is I think Geoffrey's point -- not that it is a ding against developers. In this case the DBA's when compared to the Dev's are like IT to the Business. The Business needs to change constantly and so development happens (with or without IT involvement; see Shadow IT). But IT is incentivized to keep the lights on and the trains running. Any change must be slow or it will be de-stabilizing and thus likely to hurt your up-time stats.


My point is that, bearing in mind the editorial, the whole way of thinking is as flawed as the value of the number of legs as described in Animal Farm (the George Orwell book for those who are aware of other less literary references that can be attributed to). And no I am not calling DBAs pigs

Categorizing all tasks that development do as destabilising changes (i.e. deployment of new code which WILL destabilise the system) ignores the other tasks that development does. It also ignores the sea of change in software development towards a more dynamic, yet engineered, approach. If people aren't seeing this then either they are not opening their eyes or they need to nudge their colleagues to open their eyes to a little self improvement (of course, management need to invest to gain these benefits).

Categorizing all tasks that DBAs do as stabilising changes ignores that sometimes DBAs deploy code in the form of stored procedures, deploy code in the form of CUs and SPs and assumes that all other tasks are always carried out and never reduce the stability of systems.

Talk like this is certainly fence building.

So in answer to the editorial, the attitude that everything that developers do is detrimental to stability of systems whereas everything that DBAs do stabilises them is one that appears to be accepted by some and perpetuates a perception that DBAs consider themselves god like when compared to the mere mortals in development who muck things up and creates a less collaborative "us and them" environment.

Excerpt from a sketch from BBC's "Miranda":

Stevie: "No offence but you're not much of a looker"
Miranda: "You know it doesn't make it any less offensive starting with 'No offence but...'"

Edit: Corrected grammar in sketch quote.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1579990
Posted Thursday, June 12, 2014 5:58 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Yesterday @ 7:31 AM
Points: 17, Visits: 139
I agree with several of the points already made here by Gaz and Grant. The culture starts at the top, if upper management fosters a collaborative environment, then each side can recognize the contributions of the other and everyone feels recognized. Some developers know a lot more about the DBA side of things than DBAs credit them for and vice versa. But too many on both sides like to maintain the walls of their respective kingdom, like there are big secrets to protect. Ultimately working together is what will drive the organization forward most efficiently.
Post #1579991
Posted Thursday, June 12, 2014 6:18 AM


SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Tuesday, July 8, 2014 1:39 PM
Points: 245, Visits: 735
Grant Fritchey (6/12/2014)
... both sides are to blame for not recognizing that it's not code or data that's important, it's the business.


tim.berry 88829 (6/12/2014)
The key resolving the conflict is to encourage communication and understanding.


As a development consultant who crosses into DBA, and in addition deals with "co-workers" who think a DB is just a closet to throw stuff without thoughts of needing to find it again, I find much to agree with in many of the statements. The ones that resonate the most are included above.

Unfortunately management and personalities are not always optimized for understanding.

BTW: Several years ago Oracle introduced a feature where you could substitute good SQL for bad ORM SQL on the fly. Is there anything like that in SQL Server, or in the pipeline for SQL Server?


<><
Livin' down on the cube farm. Left, left, then a right.
Post #1580000
Posted Thursday, June 12, 2014 6:27 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Friday, November 21, 2014 6:04 AM
Points: 699, Visits: 1,754
A quick (and slightly biased) question: I am a developer whose only community that I am active on is this, so how many of you DBAs are active on developer forums?


I'm a developer/DBA/analyst/JackOfAllTrades that works with multiple OSes with several different DBMS. I also read/skim/participate in a large number of forums/blogs/mailing lists.

The problem is most people are too specialized/busy/silo-ed to take the time to comprehend others roles in the greater scheme of things. When you are spread too thin, are juggling multiple projects or hundreds of servers, it's sometimes hard to be empathic towards others, especially when they may be causing more work for you. Toss in the fact that management often has no f___ing clue of any of the tasks details and you have a recipe for conflict.
Post #1580003
Posted Thursday, June 12, 2014 6:28 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Today @ 1:50 PM
Points: 2,630, Visits: 4,036
I think the problem is the thinking that an application and a database are two separate things. They are not. The user interface code and the database combine to form an application. They are both important. It is not about any one of us individually. It is about delivering quality products to our customers.

Any bickering between developers and DBAs is childish and is counter-productive to the goal of delivering quality.

Tom
Post #1580004
Posted Thursday, June 12, 2014 6:43 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Today @ 4:03 PM
Points: 14,017, Visits: 28,396
OCTom (6/12/2014)
Any bickering between developers and DBAs is childish and is counter-productive to the goal of delivering quality.

Tom


THIS!


----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1580013
« Prev Topic | Next Topic »

Add to briefcase ««12345»»»

Permissions Expand / Collapse