How could DBAs be more 'programmer friendly'?

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)?

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:

• Spent years as developers themselves

• Have a grasp of database theory

• Have a good understanding of how the RDBMS works internally

• 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:

• one must consult the other

• one must value the perspective of the other

• one must make decisions for the good of both parties

• one must support, and not sabatoge, the decision made

• one must not denigrade the other if decisions result in bad consequences

• one must rejoice in the contribution of both parties to the success of decisions

• 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 :

• layout their expectations

• engender respect for the other party's ability to do their part based on past performance

• have trust and confidence that the other party can complete their assignment

• live up to our own expectations

• 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.

StackExchange Database Administrators Q#2471, answer score: 63