September 25, 2013 at 1:29 am
Eric Higgins (9/24/2013)
eddie.caplan (9/24/2013)
Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.Agreed. This article is the only 1 star I've ever given on this site.
This sort of response is why some DBAs have issues with some Devs. By all means look at yourselves as the customer, but if you expect it all to be one way - your way - then expect not to be served. In business terms, it's known as 'Fire the Customer'.
September 26, 2013 at 1:37 pm
Hold the phone here.... you are placing a stereotype on DBAs which I don't really agree with.... I have played the role as DBA for a very long time along with many many years of development.
I will tell you an experience I had with a developer a number of years back. We would often not see eye to eye on his "designs" compared to what is good solid standard development techniques.
It got to a point where I just had enough dealing with this attitude. This one particular process was very cumbersome and very inefficient. I told him we will proceed with his design but the first time the design runs into a performance issue he was going to rewrite it and review it with me before we rolled it into production.
Well he was rewriting code before the end of the week because it failed and failed big! This approach worked and all future design considerations were passed & blessed by me before moving to production.
So I was not being an curmudgeon but more someone allowing a smart a$$ developer get his way only once and taught him a lesson.
Beyond that, most DBAs have standards that everyone needs to understand. Those standards are there for a reason. A seasoned, hardened DBA may rule the roost but has paid dues to get there. There is no room for poorly designed procedures, database structures, what ever, especially in a high volume environment.
Do I agree to the rest of the stereotype?? Give me time to think about it....
Kurt
Kurt W. Zimmerman
SR DBA
Lefrak Organization
New York, NY
http://www.linkedin.com/in/kurtwzimmerman
September 27, 2013 at 12:58 am
Kurt W. Zimmerman (9/26/2013)
Hold the phone here.... you are placing a stereotype on DBAs which I don't really agree with.... I have played the role as DBA for a very long time along with many many years of development.I will tell you an experience I had with a developer a number of years back. We would often not see eye to eye on his "designs" compared to what is good solid standard development techniques.
It got to a point where I just had enough dealing with this attitude. This one particular process was very cumbersome and very inefficient. I told him we will proceed with his design but the first time the design runs into a performance issue he was going to rewrite it and review it with me before we rolled it into production.
Well he was rewriting code before the end of the week because it failed and failed big! This approach worked and all future design considerations were passed & blessed by me before moving to production.
So I was not being an curmudgeon but more someone allowing a smart a$$ developer get his way only once and taught him a lesson.
Beyond that, most DBAs have standards that everyone needs to understand. Those standards are there for a reason. A seasoned, hardened DBA may rule the roost but has paid dues to get there. There is no room for poorly designed procedures, database structures, what ever, especially in a high volume environment.
Do I agree to the rest of the stereotype?? Give me time to think about it....
Kurt
I would like to take this example a step further based on my own experience.
Although I haven't had an experience quite like this, I have been blamed for letting inefficient code be rolled-out into production because the development team hadn't tested it properly. The reason it happened? Said team came out with the immortal phrase "We are developers and we know what we are doing". With a boss that also comes from a development background it made the job for me quite difficult.
Unfortunately, I had to take a very hard stance with these people and made myself unpopular with them but everything after that worked as it should.
September 27, 2013 at 7:10 am
This thread has been on my mind the last few days. It focuses on communication hurdles and getting one's own way. I'd like to reframe the situation. I see developer and DBA functions as being like organs in the body, each one has it's own priorities. If the heart, liver, and lungs all tried to do everything, the system would turn into mush. Developers don't tell Purchasing how to do their job. DBA's don't tell HR how to do their job. So, why don't we allow each other the right to freedom of implementation.
We only share messaging between an application and a storage system. Granted, if database retrieval performance suffers, the whole system suffers. If there are unnecessary data requests from the application, the system suffers. But, we are also dependent on Payroll and Sales teams too for the business to thrive. This freedom and interdependency trust go hand in hand. This is called holon theory. We balance our private internal lives with our public external lives in the same way.
September 28, 2013 at 6:00 am
eddie.caplan (9/24/2013)
Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.
True that. I am astonished at this article and attitude of assorted dbas in here. Developer is the one who provides your business customers (through sale people) with solutions. You and project managers and even system architects should provide them with solutions - not attitude and problems. Which many of the above mentioned do not seem to understand. Granted some - like project managers and system architects provide them with solutions without much discussion, but developers are their clients never the less, not the other way around.
I will not cross my arms when business analyst comes to me and ask him to follow "5 rules" when he brings me customer requirements - that's money for a company and me.
I have been dba for long 5 years, then developer, now an enterprise architect and this attitude and some shaky query optimizer behavior is why I am planning to take company in the direction of NoSql world.
P.S. To somebody bemoaning that his/her company sides with the needs of agile development. DUH. That what makes customers happy and willing to shell the money, not the promise that dba keep their data backed up.
September 28, 2013 at 12:00 pm
dkrasnikov (9/28/2013)
eddie.caplan (9/24/2013)
Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.True that. I am astonished at this article and attitude of assorted dbas in here. Developer is the one who provides your business customers (through sale people) with solutions. You and project managers and even system architects should provide them with solutions - not attitude and problems. Which many of the above mentioned do not seem to understand. Granted some - like project managers and system architects provide them with solutions without much discussion, but developers are their clients never the less, not the other way around.
I will not cross my arms when business analyst comes to me and ask him to follow "5 rules" when he brings me customer requirements - that's money for a company and me.
I have been dba for long 5 years, then developer, now an enterprise architect and this attitude and some shaky query optimizer behavior is why I am planning to take company in the direction of NoSql world.
P.S. To somebody bemoaning that his/her company sides with the needs of agile development. DUH. That what makes customers happy and willing to shell the money, not the promise that dba keep their data backed up.
Yes. The developer provides the code that forms a solution. But come to me with a query that is badly written (read: overloads my SGA(Oracle) or has a badly performing execution plan), then expect to walk away with an instruction to rewrite the code.
Good for you. Been a DBA for 5 years, huh? And you rely on the query optimiser? How about writing it properly yourself and bypassing the optimiser altogether?
And to your last paragraph: For an "enterprise architect" and "DBA for long 5 years" you show an immense lack of respect for data. There is one thing a DBA can NEVER get wrong and that is his/her backup and recovery strategy. It is my most important job and the it is the part that makes a difference between a company going bankrupt or successfully recovering in the event of catastrophic data loss.
I get the impression you are more concerned with bashing out code and selling stuff than producing something that the real customer really deserves.
Yep.....I guess you and I would not get on in the office.....
September 28, 2013 at 10:01 pm
Very nice. Thanks for posting this
September 29, 2013 at 7:58 am
kevaburg (9/28/2013)
dkrasnikov (9/28/2013)
eddie.caplan (9/24/2013)
Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.True that. I am astonished at this article and attitude of assorted dbas in here. Developer is the one who provides your business customers (through sale people) with solutions. You and project managers and even system architects should provide them with solutions - not attitude and problems. Which many of the above mentioned do not seem to understand. Granted some - like project managers and system architects provide them with solutions without much discussion, but developers are their clients never the less, not the other way around.
I will not cross my arms when business analyst comes to me and ask him to follow "5 rules" when he brings me customer requirements - that's money for a company and me.
I have been dba for long 5 years, then developer, now an enterprise architect and this attitude and some shaky query optimizer behavior is why I am planning to take company in the direction of NoSql world.
P.S. To somebody bemoaning that his/her company sides with the needs of agile development. DUH. That what makes customers happy and willing to shell the money, not the promise that dba keep their data backed up.
Yes. The developer provides the code that forms a solution. But come to me with a query that is badly written (read: overloads my SGA(Oracle) or has a badly performing execution plan), then expect to walk away with an instruction to rewrite the code.
Good for you. Been a DBA for 5 years, huh? And you rely on the query optimiser? How about writing it properly yourself and bypassing the optimiser altogether?
And to your last paragraph: For an "enterprise architect" and "DBA for long 5 years" you show an immense lack of respect for data. There is one thing a DBA can NEVER get wrong and that is his/her backup and recovery strategy. It is my most important job and the it is the part that makes a difference between a company going bankrupt or successfully recovering in the event of catastrophic data loss.
I get the impression you are more concerned with bashing out code and selling stuff than producing something that the real customer really deserves.
Yep.....I guess you and I would not get on in the office.....
Well if you know the way to bypass Sql Server query optimizer, I would certainly like to know about it. But I am pretty sure you can't. It's parsing->binding->query optimization->query execution that's how sql engine works. Yeah I can stop relying on it and start hinting heavy with indexes I want to use or that I want merge joins instead of hash ones. Hell I can even wright dynamic generator which will specify partition to go to, but I value my and other people time more then that, and it's a recepie for disaster later.
I think you were thinking about "Database Engine Tuning Advisor" though. Here is good book on Sql Server query optimizer - https://www.simple-talk.com/books/sql-books/inside-the-sql-server-query-optimizer/
I have more then healthy respect for data and it's integrity, but it's not a license for dba to think they are king of the hill, that's my point. You wouldn't want to have all your IP addresses disabled by IT security guy, since he thinks it's safer that way and you have to follow 5 rules to beg him to open each one and each sql port for your instances.
September 29, 2013 at 8:58 am
dkrasnikov (9/29/2013)
kevaburg (9/28/2013)
dkrasnikov (9/28/2013)
eddie.caplan (9/24/2013)
Joshua Feierman seems to think the developers are supplicants, pleading for help. In fact, the DBA should think of the developers as his customers, and provide better customer service than is described here.True that. I am astonished at this article and attitude of assorted dbas in here. Developer is the one who provides your business customers (through sale people) with solutions. You and project managers and even system architects should provide them with solutions - not attitude and problems. Which many of the above mentioned do not seem to understand. Granted some - like project managers and system architects provide them with solutions without much discussion, but developers are their clients never the less, not the other way around.
I will not cross my arms when business analyst comes to me and ask him to follow "5 rules" when he brings me customer requirements - that's money for a company and me.
I have been dba for long 5 years, then developer, now an enterprise architect and this attitude and some shaky query optimizer behavior is why I am planning to take company in the direction of NoSql world.
P.S. To somebody bemoaning that his/her company sides with the needs of agile development. DUH. That what makes customers happy and willing to shell the money, not the promise that dba keep their data backed up.
Yes. The developer provides the code that forms a solution. But come to me with a query that is badly written (read: overloads my SGA(Oracle) or has a badly performing execution plan), then expect to walk away with an instruction to rewrite the code.
Good for you. Been a DBA for 5 years, huh? And you rely on the query optimiser? How about writing it properly yourself and bypassing the optimiser altogether?
And to your last paragraph: For an "enterprise architect" and "DBA for long 5 years" you show an immense lack of respect for data. There is one thing a DBA can NEVER get wrong and that is his/her backup and recovery strategy. It is my most important job and the it is the part that makes a difference between a company going bankrupt or successfully recovering in the event of catastrophic data loss.
I get the impression you are more concerned with bashing out code and selling stuff than producing something that the real customer really deserves.
Yep.....I guess you and I would not get on in the office.....
Well if you know the way to bypass Sql Server query optimizer, I would certainly like to know about it. But I am pretty sure you can't. It's parsing->binding->query optimization->query execution that's how sql engine works. Yeah I can stop relying on it and start hinting heavy with indexes I want to use or that I want merge joins instead of hash ones. Hell I can even wright dynamic generator which will specify partition to go to, but I value my and other people time more then that, and it's a recepie for disaster later.
I think you were thinking about "Database Engine Tuning Advisor" though. Here is good book on Sql Server query optimizer - https://www.simple-talk.com/books/sql-books/inside-the-sql-server-query-optimizer/
I have more then healthy respect for data and it's integrity, but it's not a license for dba to think they are king of the hill, that's my point. You wouldn't want to have all your IP addresses disabled by IT security guy, since he thinks it's safer that way and you have to follow 5 rules to beg him to open each one and each sql port for your instances.
No, I did not mean the Database Engine Tuning Advisor. But if you can generate a better plan than the one presented by the optimiser, then tell it to use it. Is that so wrong? For the developer, the DBA and the person that buys the product it surely can't be wrong, can it?
http://technet.microsoft.com/en-us/library/cc917694.aspx
My problem is that you sound too much like the developer that wants to be king of the hill and that is exactly where the problems start. If you read my other posts here you will know and understand better what my stance on this is One is not better than the other but if you come to me with a solution the compromises an existing product or server, then it won't get implemented. That isn't being king of the castle: That is doing exactly what is expected of me.
November 3, 2013 at 9:03 am
Andy Warren (9/24/2013)
Josh, a nice take on the complexities of dealing with DBA's - I'd like to see you write the corollary for dealing with developers!
I agree.
These are some pretty good rules. I particularly like rules numbered 2 and 5
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
November 14, 2013 at 3:23 pm
I couldn't agree more, it's all about respect going both ways.
Oh, and remember to use ROLLBACK! 😉
qh
February 7, 2014 at 8:40 am
S/he is often stubborn, rude, and highly opinionated.
You left off "b*tch".
Awesome and well written article!!!
April 10, 2015 at 1:47 am
The main problem is that our best interests are not your best interests.
The developers have discovered Entity Framework and they say that it lets them code faster. I'm sure that it does. Meeting deadlines is good.
It also makes performance-tuning a pain in the arse. The DBAs have to take traces all of the time to find the offending (and frankly horrible) SQL generated by EF.
If their EF is the reason for poor performance, only they can improve it. The developers are always working on something new.
Beforehand we had SPs and the DBAs could optimise these. They can't optimise EF.
The developers don't like CHECK, DEFAULT or UNIQUE constraints. And since they are ones given the task of developing the DB, they get left out.
Violations cause errors and errors have to be handled. 'It's all right', they say, 'We'll validate all inputs'.
The DBAs still have to clean the data every year, because of values that should have been validated weren't really (The year 0209 anybody?).
The developers have no understanding of datatypes. the DBAs understand that the smaller the volume of data, the more data can be fit onto a page and the handling of fewer pages makes for faster performance. As a consequence, any field with a date in it gets the DATETIME datatype by default (because dates need microsecond detail), all strings are automatically Unicode (NVARCHAR et al.), all field with a number is automatically INT or BIGINT.
The developers understand that if there are performance problems, then the obvious solution is for the company to buy newer and faster servers.
Performance is always somebody else's problem.
April 10, 2015 at 2:33 am
From a Dev perspective, I think that the article is a bit backward.
First of all, why does it suggest that only dev should come up with data to back up their claim and not the DBAs?
The other issue is that recently, the power has shifted from DBAs to Developers.
There are many reasons for that:
1) A lot of companies that adopt BI are small to medium. The perceived security level that they need can be accomplished by a basic backup/restore strategy. So between a good good DBA and a good Dev they are choosing the later for obvious reasons. Or they decide to use a cloud solution.
2)Businesses are starting to realize that data is the new oil. Keeping it safe into the ground with a bulldog guarding the gate doesn't improve their bottom line. So when the dev extract and refine this "oil" and tell then that there is bulldog that prevent them to get the profit that they deserve, the businesses tend to listen.
As the demand for DBA is shrinking (thanks to cloud solution) and the demand for specialized Dev (BI/Software developers/data scientists/etc) keep on increasing, DBAs that see themself as gatekeeper are going to have a rude awakening.
April 10, 2015 at 3:29 am
Frankly I find this whole discussion about "them" and "us" puzzling.
Rule Number Zero: We are all human beings. Treat someone like you like being treated.
That means masochists aside for the moment if you treat someone roughshod then expect to get the same treatment. If I assert my technical and business acumen or "business needs" over keeping it human and I am a recipe for desaster. Yes, short term there will be more achievements short term, on the other hand I will be the one nobody likes to work with as I am an a**hole.
Besides, how do you learn to stay relevant if you know it all already? Be open, be human and you will learn more, easier and have more fun along the way.
Viewing 15 posts - 46 through 60 (of 76 total)
You must be logged in to reply to this topic. Login to reply