How could DBAs be more 'programmer friendly'?

Question

The answers and comments on the dba.se version and programmers.se version of the question "What are the arguments against or for putting application logic in the database layer?" are very revealing about the divide between DBAs and programmers in some workplaces.

What could DBAs do differently to work better with programmers on issues like this?

Should we:

• Study the tools and languages our programmers are using to understand their difficulties they face, particularly when working with well designed databases?
• Encourage programmers to be better educated about databases and the advantages of having business logic at the database level?
• Change the way we define interfaces to our data - such as by using more programmer friendly transactional APIs (eg for issues such as backwards compatibility)?

Answer 1

From a Programmer standpoint, I would say the thing we want most is consistent, well defined and implemented standards for how the data layer will be designed and built. I am willing to play the way you want in your sandbox, you just need to tell me what you want, and not change the rules all the time. It should be implemented the same for everyone, even superprogrammergod. If you make exceptions for him then you want me to support and change it but re-implement it the right way that doesn't work for me.

And please do not tell me not to do it that way and walk away. Work with me to show me what you want, and why your way is better. If I understand I will comply every time. When I don't get it then its harder to comply. I do not want to be a DBA. I love programming I do not want your job and if you are a good DBA then I will be your biggest fan.

Answer 2

I've been a MySQL DBA for the past 6.5 years. I've also spent some 16 years as a developer and have interacted with many DBAs. Many of them pragmatic. Some of them obnoxious. A few have no idea what it means to be a DBA.

I have come to this conclusion:

Technically speaking, DBAs who have one or more of the following qualities are the best to work with:

1. Spent years as developers themselves
2. Have a grasp of database theory
3. Have a good understanding of how the RDBMS works internally
4. Have superior knowledge of the operating system

Very disciplined, knowledgeable DBAs have a lot to share and offer. They may see database performance from a perspective not really considered by Developers. Developers know what they want from the database. DBAs know how to be "polite" to the database.

As far as personalities go, there will always be conflicts, pettiness, and maybe even envy. One thing is for certain: In no particular order, DBAs and Developers are like husbands and wives (I've been happily married for 16 years with on-going projects [4 children]).

Regardless who is viewed as the husband and who is viewed as the wife, these principles apply:

1. one must consult the other
2. one must value the perspective of the other
3. one must make decisions for the good of both parties
4. one must support, and not sabatoge, the decision made
5. one must not denigrade the other if decisions result in bad consequences
6. one must rejoice in the contribution of both parties to the success of decisions
7. one must consult a higher authority (HA) if a decision cannot be mutually agreed upon

These seven(7) principles apply just as much in the workplace, especially in the IT realm.

By communicating every step of way, all should :

1. layout their expectations
2. engender respect for the other party's ability to do their part based on past performance
3. have trust and confidence that the other party can complete their assignment
4. live up to our own expectations
5. acquiese under the guidance of the HA (see principle #7)

There is no room for micromanagement in this. DBAs SHOULD NOT TELL Developers how to think like DBAs. Developers SHOULD NOT TELL DBAs how to be Developers. Final decisions on database performance and usage must rest with DBAs. Final decisions on application needs must rest with Developers. This symbiosis must be maintained always.

FINAL THOUGHTS

Principle #7 requires active participation and oversight by the HIGHER AUTHORITY (the HA), i.e., project manager, team leader, lead developer. Your HA better know how both parties work individually and how both parties should work together. If the HA does not establish ground rules for both parties, or if the HA fails to guide the parties individually and together, projects will always come to a halt at some point and endanger the very existence (employment) of the Developer, the DBA, or even the HA.

Answer 3

Having teams sit in different sections/floors somehow seems to encourage "us vs them" mentality.

Sitting a DBA right in the middle of the development team is a great way to tear down the programmer/DBA wall. Both the DBA and the programmers will benefit from this, if they remain open minded and put their egos aside.

Face to face communication, especially when sharing ideas, is far more effective than email and has less chance of causing hard feelings due to misunderstandings.

Answer 4

This sort of thing varies hugely from place to place. At my current site, the line between developers and DBAs is very blurred indeed - we (DBAs) write PL/SQL too, and they (developers) dissect query plans. We all see ourselves as peers, merely with different skillsets and responsibilities. This is very amusing: recently the company has jumped on-board the DevOps bandwagon. The database community don't understand this at all; we've always worked like that. Needless to say we are enormously productive working like this: the database tier is by far the most reliable part of the company's technology stack, it's easy to operate (since we have the skills in the DBA team to understand the application at a deep level, and the developers have the DBA exposure to understand 24/7/365 operations and how to structure their apps for it).

But I know what you mean when you talk about the "wrong" sort of developer. He's self-taught, which in and of itself is a noble thing, but along the way he's picked up a distrust of any sort of formal instructions. He doesn't know what he doesn't know, and he resents anyone trying to enlighten him, he sees it as an insult to his self-learning skills. He's learnt the imperative style of programming, because you can learn it without any of that theory stuff that CS types are always babbling about (well, badly; everyone needs to know big-O and similar bits of theory). He's learnt a bit of OO too, just because he has to to use Java. But a good database professional - developer or DBA - has to be comfortable thinking in a declarative style, thinking about set theory, normal forms, even being able to understand the relational algebra and calculus. It's very, very difficult to communicate with these people, because they are actively hostile to anything that might jolt them out of their comfort zone, which is by and large confined to how to format something on a web page. If they think about databases at all, they think that a table is like a class and a row is like an object. These guys will literally just do SELECT * FROM TABLE and filter and sort the results in their own code. They really, really don't understand why a database is better than a flat file (and they not-so-secretly think anyone who uses a relational database is an idiot).

Let me give you a real example: recently I was talking to one of these types about the issues involved in rolling back a release of our software after it had gone into production, if an issue had slipped past QA. I explained that while we might roll back his application (one of many accessing the database), it would need to be able to operate with the database still deployed. He asked why, and I said, well, in those new tables and columns, there will be real customer data. He then said, so just copy it into a temporary table, what's the problem. I stared at him in disbelief: when a customer calls and says, my money has disappeared from my account, what do we tell him, that it's OK, it's in a temporary table? He simply didn't get that when you are dealing with other people's money, you have to act like a responsible adult. For all I know he still doesn't; he's no longer with us.

The MySQL camp were like this for a long time; they would say you didn't need transactions, foreign keys, etc, if you thought you did it was only because you had no idea what you were doing, etc, etc (then when they grew up, they quietly added them in). These are the kinds of people ORMs like ActiveRecord or Hibernate were developed for, so they could write database applications without ever needing to touch SQL. Use of these technologies I consider to be a red flag - this is not a company that values DBA skills. What they really want is a babysitter...

Answer 5

As a programmer understanding the database better made me a better programmer. When I became a database administrator this became even more important, therefore I believe education is the key.

DBAs should patiently guide developers treating them as competent professionals. Few programmers when shown the difference between a set operation and a row by row operation on the client side will balk at the idea. We share some of the same goals - application speed, data security, maintainability, etc. This applies not just to the application logic question, but also to all aspects of database interaction. Programmers want to use their tools better and the more the DBA can show them how to use the database tool better the more they both will benefit.

Answer 6

No matter what infrastructure we support, we have to support the users of it. A lot of users are developers, so we support the developers to enable them to make the best possible use of that infrastructure. To be able to do this we need to understand each other, with the different ideas and points of views in mind. Having insight to the views from both sides helps to make things better for the business and that is our combined goal. Make IT support the business as effective as we can.

In many organizations we see some dba types running in god mode. Most of the times these are not the ones that score very well if competency is measured ..... Often they just hide their - lack of - knowledge behind a wall of words.

To my opinion it has nothing to do with being 'programmer friendly' more with being professional. For a dba it means we need to be able to explain why we do the things we do and be prepared to at lease reconsider decision if it helps, without loosing the normal goals like availability, scalability, recoverability and performance. For the programmer it means he has to communicate to the dba, sometimes to teach the dba, sometimes to learn from the dba. My motto on this is: let the first day that I don't learn a thing be the day that the coffin closes above my head. Normal collaboration, having combined teams with developers and dba's certainly help make things easier.

Answer 7

I think part of the problem is perspective. Dbas and data analysts and database developers have to deal with the data over time. Application developers are concerned with how to make things work when they send it to production. They don't worry so much about what the data will look like in six months as long as there are no errors when it is deployed.

But data people have to live with the results of short-sighted decisions that cause the data to lose integrity or cause duplicate records to get inserted and then try to explain why the data is bad. DBAs are the ones who have to deal with the performance problem from the process that worked fine when there were only a thousand records, but now takes hours with 100,000,000 records.

Databases are harder to refactor, so DBAs are concerned with getting it right the first time. Developers see no problem in refactoring down the road.

Developers see no problem with making the database act as if it was object-oriented, database people know that is not the most effective or efficient way to store or get the data.

Application developers often only deal with a small subset of records but not with large data imports/exports or reporting. Things that work fine to enter one record, don't work when you are talking about importing a million. Business logic in the application (which is often not accessible to the reporting application) doesn't help the report writer get the same results for a million records as what is shown on the screen one record at a time.

Another part of the problem is disrespect on both sides. I have met more than a few application developers who think data work is not hard or interesting and who believe that you would only do this work if you can't hack it in their world. People tend not to react well to being treated as if they are stupid and useless. Some DBAs on the other hand tend to treat application developers with disrespect as well and tend to put their tasks of reviewing what the developers are doing to the database as a low priority (which when you have large complex production databases, it may be). They can refuse to hear or be responsive. Who wants his whole project put on hold until the DBA reviews it two weeks later? And then he tells you it is unacceptable and you have to rewrite the whole thing?

Answer 8

Over the many years since I started with SQL Server (1998), I've had many developers tell me how to do my job. It's interesting that they all know more than me as well being superb .net developers. In fact, they're architects too and should be doing greater things than code monkeying.

Perhaps that's the wrong attitude from me: but it's a quite common developer attitude in many shops. They do it to each other too, remember: watch the fights start when you suggest peer reviews.

I'll leave the fixes up to other answers (I agree 100% with the 2 so far) but add that the management and shop culture must support and nurture collaboration too.

Answer 9

As a developer, all I need from you is to know how you want me to communicate what I need. If I am asking for something ridiculous, I need for you to tell me - and if you tell me so, I will believe it because you have a track record for integrity. If you don't understand what I am asking for, take the time to explain to me what you think I mean - and I'll take the time to listen.

... Common theme, right ... Communication ... communication ... communication.

There is really no better way to put it. Developers get ticked because, "that DBA told me it couldn't be done - I sure proved him wrong last time." DBAs get ticked because, "that developer doesn't understand what I have to do every time he changes his specs."

Developers and DBAs, as @Rolando stated, have to understand each other. When it all comes down to it, we both speak "Ones & Zeros" - you'd think that would be a good match. We have 2 realms of responsibility: DBAs have data, Developers get the rest of the computer. But without data, programmers really wouldn't have much to do.

We don't have a DBA and it is painful at times. That piece of me that wanted to be a DBA a decade ago will cringe when I see some of the things we do. If we hired a DBA tomorrow, I think I would kiss the very ground he/she walked on.

Answer 10

In some companies, perhaps many, product development has a tendency to ignore anyone not writing in a compiled language. Come release time, there is resistance because network admins, DBAs, system admins, user-support, etc. each has their due-diligence to complete. There are often headaches because key aspects of the environment weren't considered. This naturally causes tensions between teams.

Who's to blame here? Ms. Communication.

Developers need to understand the environment code will be deployed in. People need to be given fair warning to adapt. Where the environment can't adapt for whatever reason (security, equipment, policy), the software needs to adapt. If this happens during the design & implementation process, everyone's happy. If it doesn't start until deployment time, it's a world of hurt.

Yes, the teams need to talk (and listen) to each other, but the project/product manager needs to create an environment this can happen in.

I've been lucky, in most places I've worked, mutual respect and communication has been part of the culture.

Answer 11

One thing a good DBA has to understand is the politics of data. I taught database programming and design to seasoned programmers and a few drafted DBAs for a few years. One question that would come up regularly was this: how come all the databases back at my shop are so political?

Here was my standard answer: If the database is useful, then you're sharing data. If you're sharing data, then you're sharing power. When power is shared, politics happens.

It doesn't matter whether you love politics or hate politics. If you're going to do good database work, get used to it.

Incidentally, some of you have only worked in a development environment. There are DBAs who work on the production side of the fence, and have little interaction with developers. You might think there's less politics over in production. There's more. The big production databases tend to be enterprise wide and mission critical.

Answer 12

A little humility might help for some of you. ;)

There are obviously valid arguments for either approach, I suggest you start by recognizing that. Software development is all about making the right tradeoffs. If it is a two way street, perhaps DBAs should keep an open mind as well.