January 3, 2014 at 7:47 am
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.
January 3, 2014 at 7:51 am
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.
January 3, 2014 at 7:58 am
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).
January 3, 2014 at 8:00 am
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.
-------------------------------------------------------------
we travel not to escape life but for life not to escape us
Don't fear failure, fear regret.
January 3, 2014 at 8:03 am
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.
January 3, 2014 at 8:13 am
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.
January 3, 2014 at 8:27 am
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!
January 3, 2014 at 8:28 am
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.
January 3, 2014 at 8:34 am
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.
January 3, 2014 at 8:37 am
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
January 3, 2014 at 8:59 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 3, 2014 at 9:08 am
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.
---------------------------------------------------------------------
January 3, 2014 at 9:08 am
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!!!
January 3, 2014 at 9:21 am
Yet Another DBA (1/3/2014)
:rolleyes: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.
January 3, 2014 at 9:21 am
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. 🙁
Viewing 15 posts - 16 through 30 (of 40 total)
You must be logged in to reply to this topic. Login to reply