June 12, 2014 at 5:58 am
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.
June 12, 2014 at 6:18 am
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.
June 12, 2014 at 6:27 am
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.
June 12, 2014 at 6:28 am
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
June 12, 2014 at 6:43 am
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
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 12, 2014 at 6:53 am
OCTom (6/12/2014)
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
Totally agree.
Databases often have a longer lifespan and are slower to change. In fact the same is found in applications in that you can have differing rates of change for different components. The closer to the UI the faster the rate of change is usually the case.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 12, 2014 at 6:54 am
The option of writing poor processing is always available in any language so I don't imagine Server are planning on introducing that as a possibility as that 'feature' has always been available. In fact most of the code I review is poorly written SQL, it seems to be the standard these days. What we have to remember is that someone with the ability to get the current date out of the system and someone who can crunch millions of rows across a multitude of tables have the same skill set from the management perspective. Add to this the management view that someone who can bring a database online is a DBA and we have a recipe for disaster. The default these days is to look for delays and excuses within dependencies across teams so conflict is excelerated.
We manage this relationship despite the management, best keeping them out of the equation.
June 12, 2014 at 7:00 am
OCTom (6/12/2014)
Any bickering between developers and DBAs is childish and is counter-productive to the goal of delivering quality.
Gary Varga (6/12/2014)
Databases often have a longer lifespan and are slower to change. In fact the same is found in applications in that you can have differing rates of change for different components. The closer to the UI the faster the rate of change is usually the case.
+1000. I couldn't agree more on both points. The key is for understanding between the two groups so bickering doesn't happen in the first place.
June 12, 2014 at 7:17 am
OCTom (6/12/2014)
...Any bickering between developers and DBAs is childish and is counter-productive to the goal of delivering quality.
Tom
BUT THEY STARTED IT!!!
:hehe:
June 12, 2014 at 7:20 am
Dave62 (6/12/2014)
OCTom (6/12/2014)
...Any bickering between developers and DBAs is childish and is counter-productive to the goal of delivering quality.
Tom
BUT THEY STARTED IT!!!
:hehe:
Winner of the Internet this morning. Well done!
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
June 12, 2014 at 7:22 am
Ed Wagner (6/12/2014)
OCTom (6/12/2014)
Any bickering between developers and DBAs is childish and is counter-productive to the goal of delivering quality.Gary Varga (6/12/2014)
Databases often have a longer lifespan and are slower to change. In fact the same is found in applications in that you can have differing rates of change for different components. The closer to the UI the faster the rate of change is usually the case.+1000. I couldn't agree more on both points. The key is for understanding between the two groups so bickering doesn't happen in the first place.
Yeah, yeah. It's always them. Get back to your Kung Fu Disco Fighting!!!
(I always wanted to get that reference in)
Edit: This post makes less sense than it would have done due to the SSC.com forum bug of the Quote button not behaving as expected if someone has posted after your page was generated i.e. you are quoting the wrong post (I would tell Steve but he is busy drinking Mojitos).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 12, 2014 at 7:25 am
When I built my SaaS application, I had no DBA. Therefore, I became an accidental DBA by learning everything I could about database design, stored procedures, etc.
Personally, I believe a good software developer will want to understand what goes on behind the scenes. It would be great if companies had a mentor-protege program to ensure both sides worked together.
Steve
June 12, 2014 at 7:28 am
sdorris 90134 (6/12/2014)
When I built my SaaS application, I had no DBA. Therefore, I became an accidental DBA by learning everything I could about database design, stored procedures, etc.Personally, I believe a good software developer will want to understand what goes on behind the scenes. It would be great if companies had a mentor-protege program to ensure both sides worked together.
Steve
Good thought. Also being peers in different technologies means that the mentor and protege are based on skills in the relevant technology not on their perceived or actual standing in the company hierarchy i.e. a mid-level can mentor a senior etc.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
June 12, 2014 at 7:30 am
It makes a big difference when developers can rely on help from the DBA. I've been in many situations where I've suggested to a dev that their statements, while they work, are eating up resources and things could be much faster if we changed this or that. Many times the first reaction is "it works, so piss off". I'll demonstrate how a change could knock this many seconds off of something and how much less work a query performs as a result of a proposed change (Of course, people only care about the reduction in execution time).
We you can do this you've not only shown that you can improve something, you have also demonstrated that you are willing to take on this kind of work (an offer not usually accepted the first time). The benefits of this are enormous to both sides. Clearly it is a major benefit to a developer when they can pass on the work of writing things like stored procedures. Now they just call it and how this "black box" works doesn't matter to them because it just works. For the DBA who writes this proc the benefit is that you've kept something nasty from being introduced because you have control of its construction and implementation. Soon the developers come to you first to handle this stuff. Devs are writing code (not SQL) and the DBs are running smoothly.
DBA may mean don't bother asking to some, but I suggest if the answer to a request has to be no one should try to offer another option that works for both sides whenever possible. Sometimes the answer will be no and the requester will stomp off unhappy. Perhaps this is due to a company policy, a limitation in software, or even just a plain ridiculous request. Unreasonable expectations or a feeling of entitlement does not make someone right. There have been times I've had to OK something I really hated, but a business requirement has more weight. I try to mitigate what I hate so the business need can be met and I can be a bit less unhappy about how it is met.
Now, if a company has a culture of not allowing DBAs to do any dev work, treat one group as better than the other, or even just discourage direct communication then that is a major flaw in how that business is run. Don't dare make eye contact with so and so isn't the right way. This happens all to often and it is a major cause of this divide. If you constantly tell someone they are better than so and so they will come to believe it.
Cheers
June 12, 2014 at 7:32 am
A few days ago, there was an editorial on SSC about the DBA being too large/encompassing a term (http://www.sqlservercentral.com/articles/terminology/109566/). It led to a very interesting discussion (http://www.sqlservercentral.com/Forums/Topic1577204-3554-1.aspx). One of the topics discussed was that of a database developer. I happen to be this kind of animal, that bridges the gap between development and DB administration. I live in both worlds, and I think roles like mine help resolve the issues this editorial discusses.
I do not know how many companies still have firmly entrenched developers and DBAs in us-vs-them style camps. Most places I have worked at have had good collaboration if not outright intermixing (Agile teams with 2 devs, a DBA/database developer, and a QA). Places that continue to tolerate/promote the divide are only hurting themselves.
Hakim Ali
www.sqlzen.com
Viewing 15 posts - 16 through 30 (of 79 total)
You must be logged in to reply to this topic. Login to reply