You probably heard about the DevOps movement. The idea is that developers and operations often don't get along very well and that we have to change that in order to produce, deploy and maintain high quality software fast. I certainly agree with this movement. I have seen the great divide between developers and operations bring projects more or less to a full stop.

But there is another big divide running through many software development teams: Application developers versus database developers (or administrators).

In my experience this divide manifests itself in these ways:

• Application Developers don't give a damn about what happens in the database
• Database Developers set up rules for the database without bothering to explain why or assisting in living up to these rules
• Application Developers throw database related problems towards the Database Developers and just wait for a fix, without trying to learn to fix it themselves.
• Database Developers insist that everybody uses their toolchain (e.g. sql plus + bash) without caring how or if this integrates with the tool chain of the rest of the team.
• Application Developers demonstrate an attitude of: "It's a database problem, not mine"
• Database Developers demonstrate an attitued of: "It's an application problem, not mine"

You two, listen up: It is your project. If it sucks or even fails, nobody will ask if it was the database part of the team or the application part of the team. It's just the team. So I'll expect the following from you:

Application Developers: Learn yourself some SQL. And I don't mean select * from table. I mean merge statements, analytic functions, DDL and PL/SQL. Learn to read Explain plans and how to use data dictionary views. If there is a database related problem try to solve it. If you fail get help by a database expert, but make sure you are doing the work, so next time you can fix a similar problem yourself.

Database Developers: Learn the programming language used by the rest of the team. Learn what is happening in on the Continuous Integration system. Make sure it massages your database scripts as well. Read about refactoring databases, continuous integration of databases and listen to this podcast about agile database development.

Both: Get used to the fact that there are many aspects to a project and you probably understand only half of them. Get in the habit to talk to the guys and girls understanding the other half.