Developers and DBAs - can they work together?

[BJCooperIT]

I am a consultant who has a problem. What is a developer to do when the support DBAs have different priorities and are resistant to requests?

I am working on a government data conversion contract for a new database and need to have an Oracle parameter changed (this is a show-stopper for me). I politely requested the change via e-mail last Friday. Tuesday I received a return e-mail that I thought was almost hostile in its tone. "Why are you asking it to be set so high? What formula are you using to get this number? Currently it is set to ###, is this not sufficient?"

My knee-jerk reaction was "No, it is not enough or I would not be experiencing the problem!" but instead I responded professionally and outlined answers to his questions in a factual manner with out emotion. I understand that he has other tasks and does not know my capabilities, but why would he assume I would have been selected for this contract without the necessary talents? I also know that not everyone has "people" skills, but this is the typical reaction I have received from DBAs on several contracts.

I needed to have another Oracle parameter set-up and it took 2 months for them to do 2 minutes work. In the meantime my deadline does not slide and they put me further and further behind since I was not able to test my code. This on top of the fact it took the department 9 weeks to get me a computer and I still do not have a development database. Just how long can you read manuals to stay busy?

In my previous contract (government also) the DBA who was responsible for putting Oracle Discoverer EUL in production and just decided it was too difficult and that he did not have time...so he did not do it. The users still cannot run reports 8 months later.

I guess what I am asking is what do I need to do to insure that the DBAs feel like we are teammates instead of competitors?

Bribes, donuts, sports tickets?

(select * from life where brain is not null)
Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000

 

[KornGeek]

I think the best approach would be to keep them informed. Invite them to the project meetings. When making a request, explain why, and ask politely (not just professionally). If they understand what you're doing and why, they might be more responsive.

Keeping in mind that they might not be, I'd follow the CYA code just to be safe. When requesting services that are required in order to proceed, do so in email so that it is in writing, and cc the project manager. Make sure to state clearly that the development will be delayed if this is not done in a timely manner, and make sure you give them as much advance notice as possible. If nothing has been done, and the due date for their piece arrives, a friendly reminder might help. If nothing else, the project manager will see that you are making an effort to resolve this. Also, if you need to slip your deadline because you don't have the resources, you can show that you have requested them, and are being reasonable.

Above all else, remember that there is no way you can control their behavior. The only person you can control is you, so I recommend finding a way to adapt to them.

 

[tdgulbra]

As a DBA, let me just chime in with a couple of thoughts.

1) The DBA is basically the guardian of the data. When he/she asks for justification for a certain security level, they are just trying to protect themselves.

2) As far as government contractors go, the "rank and file" of government workers look down at contractors. I think it has something to do with a perceived lack of committment on the contractors part as they come in for a project and leave. The government workers I knew thought this made the contractors less than loyal and greedy. I am not saying this is true, but it is the perception I have heard.

3) I am now a contractor in the business world and I can honestly say it is better to contract outside government circles for your perceived value.

Not saying it's right, just saying that's how it is......

Tony

 

[sleipnir214]

Remember, the DBA has one overweaning motivation: protect the data.

Sure, if you didn't get your changes, then your project would be delayed. But if the DBA implemented your change without due consideration of the side-effects of the change, the entire database server could go down. And in the modern business place, that can mean the entire company will be on hold until the server is back up.

So the question becomes: Are you, within a reasonable doubt, sure that this change will not harm the company's ability to use the data on the server? And are you sure enough to bet your paycheck and the paycheck of everyone else in the company on it?

I've worn the DBA hat before. Unless you have, you can't possibly image the deluge of idiotic requests you have to deal with -- everything from "Can I have the superuser password, please?" to "Would you please blindly change this obscure, badly-documented server operating parameter? I think it'll fix my program.".

And while all of the requestors had taken the time to verify that this server tweak was at least one option in getting them past their respective programming humps, none had checked whether the tweaks they had suggested would affect the server in a bad way. It also never seems to occur to anyone that implementing a tweak to fix one programmer's app might actually undo a previous tweak to make another programmer's app work.

Implementing a server change will take two minutes. But researching what that change will do to the server and its data and its users over the course of the months and years it will be operating -- that takes time.

So don't take it personally when a DBA looks at your request and says, "Explain yourself!", because that is exactly what a DBA is supposed to be doing. Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[KornGeek]

Implementing a server change will take two minutes. But researching what that change will do to the server and its data and its users over the course of the months and years it will be operating -- that takes time.

sleipnir214,
That is a great point that applies to several areas. In the software development I do, I often get requests that seem trivial to the requester, but require much behind-the-scenes work. For the programmers out there, remember that even a small change results in retesting the entire app just to be sure you didn't have any side effects.

These comments seem to point back to keeping the DBA informed, and requesting changes well in advance. If they understand the reasoning, and are given time to consider the ramifications, they are more likely to be helpful.

 

[BJCooperIT]

We have had only one face-to-face meeting since we are in different cities and 3 hours apart. It was not even my meeting (I just tagged along with my own agenda). It took me 10 weeks to even find out who the responsible DBA was. Unfortunately, this project is a political "hot-potato" since it is a software package bought by users outside the umbrella of the government's IT services group.

KornGeek you are right: "When making a request, explain why, and ask politely". I usually keep my requests short and to the point and perhaps I did not provide enough justification in my original e-mail.

tdgulbra: I appreciate your input. I understand the role of the DBA and it is a tough job. As a matter of fact it is one of the reasons why I have remained a developer. I have seen how difficult it can be and you are welcome to it. I make a better contribution as a developer.

I do my best to change the perceived image of a contractor but that only goes so far. On my last contract, one of the DBAs I encountered the most difficulty with was also a contractor. I felt that he was intimidated by me. After the developers would leave for the night after insuring the software was running correctly the DBAs would stay a bit longer to do some of their work. When we returned the next morning much of our code stored in the database was marked invalid. This was due to the fact they dropped & receated tables. I actually had him come in my office yelling that it wasn't anything HE had done and I didn't know what I was talking about. He did not have enough experience to know to recompile dependent objects. When I quietly explained what the cause was and what the solution was he went balistic. It HAD to be the developers fault! I was forced to present this at our next team meeting as an obstacle to acheiving our deadline (I did not mention names, simply said that a recompile script needed to be run after the late night DDL work). He would not speak to me for days afterwards.

On another occasion the DBA was the designer of our application database. When he gave us copies of the ERD I went to him privately and told him that I could not satisfy the requirements of the application with the current database design. He was defensive of his creation and said it worked for him. OK, I said, could you show me how to write the SQL to gather the necessary data from the database without doing full table scans? His reply was that he did not know how to write SQL! Oracle certification obviously has a few holes.

I would prefer to contract in the private sector but I go where my consulting firm sends me. I try my best, but sometimes that just is not good enough.
(select * from life where brain is not null)
Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000

 

[carp]

re: the DBA who does not know how to write SQL. The hole is not in Oracle certification (SQL is the first exam!). That was a blowoff answer to get rid of you or a symptom of a much larger problem: incompetence. I find a lot of DBA defensiveness seems to be geared at covering up a profound lack of knowledge. A DBA who does not know how or why to recompile dependent objects is grossly incompetent. The dependent objects are also part of the database!

I keep bouncing between being an Oracle DBA and a developer. I know all about the 0200 calls because "the database is broken". I know the DBAs get called to work to fix problems induced by developers while the developers sleep on. It's no wonder that DBAs don't want to change a working system!

On the other hand, you can also push them to explain their concerns. It can help bridge gaps (or, if applicable, further expose their incompetence and get them out of there!). In addition to saying "I'd like to have max_open_cursors increased.", you might also include the research you've done (e.g., error messages, metalink notes or documentation excerpts). If they resist, ask them why they are hesitant - exactly how does this pose a performance/security issue? Not only might you learn something you didn't know about Oracle, but the DBA might come to realize it really isn't an issue. At the very least, you are demonstrating that you care about the DBA's problems.

And if you do encounter pushback to your original email, by all means, ALWAYS cc at least one level higher! The project manager and/or DBA's manager needs to be kept informed of where the obstacles are.

 

[tdgulbra]

BJ - I hear ya'. I am also at the whim of my employer. I did not mean to suggest you could move. The current market does not support that idea. I was just trying to say that we can't get our idea of competence from those who are unfamiliar with our work.

Again, I don't know your exact situation, but this particular DBA just seems to be wanting to understand why a change needs to be made when his system (and, yes, he thinks he owns it) is working fine. The other shoe of this will drop when you convince him to make a change and something breaks. His first reaction will be to back out the last change, which may, or may not, be the right answer for the problem at hand. This leaves him embarrassed and more resistant to future changes.

"Been there, done that, got the scars to prove it"
Tony

 

[BJCooperIT]

carp,
All good advice.

"In addition to saying "I'd like to have max_open_cursors increased.", you might also include the research you've done (e.g., error messages, metalink notes or documentation excerpts)"

That is exactly what I did with the first parameter (UTL_FILE directory). I included my research and some excerpts from the manuals. Unfortunately, I did know know that my intended audience perceived that as an insult to their talents. ("Why is this stuff included, I know how to do my job!&quot

The second request, interestingly enough, was to increase the max_open_cursors. I did my research but did not include it because I was afraid to offend again. I just tried to make sure my request was reasonable and would not have a negative impact on the database (only one application).

I always copy my manager on the e-mails, but since he is only a "user" and not IT staff, I doubt it has any impact.
Perhaps DBAs have become so accustomed to the ridiculous requests it sometime makes it difficult to recognize the reasonable ones. I think perhaps, in this case, it might also be part of the woman knocking on the "good ole boys" door. Sincerely hope I am wrong about that.....
(select * from life where brain is not null)
Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000

 

[sleipnir214]

Another problem is that you may not know what else is going on with that server.

I once had two programmers, working on different projects, who within a 2-hour period placed requests with me to modify the behavior of the database server.

The problem was that the change each programmer wanted to make was the exact opposite of the change the other wanted.

I wrote them both an email the text of which read, "Thumb-wrestle or something to agree on what you need.", and which included both original request emails as attachments.

After two days without hearing from them, I asked the two programmers what they wanted me to do. Both said that they had solved the problem without resorting to changing server behavior after all. Which, or course, is what I wanted in the first place.
Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[BJCooperIT]

How true..I am so far out of the loop I don't know where it is! (select * from life where brain is not null)
Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000

 

[sleipnir214]

Sometimes that doesn't matter.

The two programmers I mentioned in my previous post actually shared an office -- their desks were at most 4 feet from each other. Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[carp]

To the original question: "Can developers and DBAs get along?"

Yes, but it's not likely. I think the problem stems from the fact that the two groups work towards opposite goals.

A developer's sole purpose for existence is to make changes. Once DBAs have a database up and tuned, they will resist change to the death - and with good reason (Finish the phrase: If it ain't busted ......).

I have a group of DBAs that I have worked with for years; in fact, I trained a couple of them. I recently went from being the company's production DBA to being the lead developer. And I STILL run into this stuff. And it's a good thing up to a point - it keeps everybody on their toes and averts a lot of problems. But when it starts blocking all progress for no apparent reason, then it is a severe problem that needs to be removed. And that may mean calling a meeting with you, the DBA, and management and having it out. Of course, this may also lead to more resistance and even sabotage down the road, so you ARE on a razor's edge here.

Proceed with caution and make sure you keep your ducks in a row and your back covered!

 

[KornGeek]

A developer's sole purpose for existence is to make changes.

I actually laughed out loud when I read this (fortunately, since it is after hours, no one is around to look at me funny). I often joke that my job description reads "I wonder what will happen if I do this." I mutter that sentence at least five times each day.


As far as getting along with the DBAs, it may already be too late on this contract, but maybe on the next one you could try getting to know them (and hopefully get along with them) well before you need to make any requests.

Back when I worked in an IT/SA position, the people who were on our "good" list got help right away and with more resources. Those on our "(insert swear word here)" list got minimal help when it was most convenient for us. We gave them just enough to have management not come down on us.

I realize that is not very professional, but it was the corporate culture. If their first contact with you is you asking for something, then they might start off with a negative image of you. If they like you, and then you ask for a favor, they are often more willing to find a way to help you.

As far as gender playing a role, unfortunately in many workplaces, that can still cause difficulties. Often the view is that women in technical fields are less talented and less skilled, and this stereotype can lead to some clashes. I don't agree with this, but I've seen it often.

 

[Advocate]

works for me ...

try and win the trust of the senior dbm and his/her dbas

patronise if necessary ...

copy your contract supervisor on all email requests, clearly indicating why request is being made and what are implications for project if not approved

dbm/dba will then know that his/her decision will affect one of his/her permament colleagues ... hopefully a peer or manager

if all fails, raise it as a project issue and clearly indicate implications for non-agreement - i ALWAYS spell out implications in very clear terms which can not be misunderstood and ensure that dbm/dba are then responsible for coming up with another suggestion ...

i use standard project management terminology and it sure raises a few heads

good luck ...

by the way, BJcooperIT, quite enjoy some of your postings, keep it up ...
Best of Irish Luck, David.
djwilkes@hotmail.com

 

[Remou]

Hi
I do not know what the situation is in America, but in Irish govenment services you will often find that the top guy/ette in a department has the title and speaks some of the language but knows nothing. The person doing the work is much lower down, very overworked and may not even have heard of your request. Check the cellars / broom closets and you may find them! Seriously, the person you have been told is the liason may not be the best person to deal with. If you can establish an unofficial (it must be unofficial) relationship with the person doing the work, it helps.
However, this is an Irish solution to an Irish problem.
Bye
Fionnuala

 

[Lozbinator]

BJCooperIT, I don't know what its like elsewhere, but I work in Australia.

My organisation employs contractors who take care of a variety of things, including some database stuff.

One of the things I have learnt over the last 18 months is that being friendly with these contractors (who are always on site) has made my job easier. Whenever I need to ask them for help, they are happy to stop what they are doing and assist where they can (even on the things they may not normally want to do, or on things that may be difficult).

And all I have done to have a good working relationship with them is to be friendly, ask how they're going, etc.

I'm sure you're already friendly as it is, but thought I'd offer my opinion for all.

 

[Onyxpurr]

I don't mind that my change to my database may take some time, but at least tell me when to expect it and why. And if it goes over then inform on the day you promised it to me and give me a new ETA. Harumph!

 

[SQLSister]

What you have isn't a developer versus dba problem, but a teamwork problem. Lots of developers and dbas work well together.

What can you do about it. First try to get the dba on your side. When you have a need, go discuss it with her and ask for her input as to how to solve the problem. Respecting her professional expertise will get you a response a lot faster than telling her what to do. Also explain your deadline and why this is needed. Try not to go to the dba an hour before the deadline and want a change made and get upset if she can't do it then.

You may not want to hear this, but it is possible the difficult person in this equation is you. I know I have seen requests from certain people go straight to the bottom of the pile of requests just because the person doing the requesting was such an arrogant idiot that no one wanted to work on his stuff if they could help it. I also know that because I'm helpful to other people and treat them with respect, my requests frequently go to the top of the pile. You really do catch more flies with honey than you do with vinegar as my momma would say.

Should that not work (and dbas, being people, come in all types, some less cooperative than others), you need to start working through a formal request process. One that documents the request and the data asked for and the date the work was completed. And you need to have management pay attention to the items in this process and push their employees when they are not meeting deadlines. I can tell you that having a formal problem tracking system that managers can review to see what you are and aren't doing has fixed alot of these delay type problems where I work.

People do the work they are rewarded for doing and the work they will get in trouble for not doing. That's human nature. Also if all the tasks (this means everyone's tasks, not just the dba's) are being recorded you can have a better idea of what other things the team members you are expecting support from are doing which in turn will make you see why they may not be able to get to your request.

Asking for a data change on a development system may be important to you, but it really probably isn't too high in the priorities when the dba is busy recovering the production database because the hard drive crashed. If you can see other's task lists, sometimes you will know when to ask for something and when it's a bad time.

Another plus of documenting is that you can collect evidence to go to your boss and show there is a genuine problem. It also protects you in the event you are getting the blame for things not being done.

 

[BJCooperIT]

As a postscript to this thread I thought you might like to know that it took 5 months before I earned the grudging respect of the DBA in question. I finally got my development database 12 days before the end of my contract and did not have enough time to successfully test before the fiscal year ran out and the contract was no longer funded. Before they setup the database I had given the DBA a detailed write-up of what my project entailed and made sure he knew that I was going to be adding 80,000 rows to a particular table. My first test run died because he had not expanded the indexes (sigh). When I requested they be expanded he did that for me within 2 hours. Better late than never I guess.

^{Beware of false knowledge; it is more dangerous than ignorance. ~George Bernard Shaw}
Consultant/Custom Forms & PL/SQL - Oracle 8.1.7 - Windows 2000