Does your DBA make schema changes for you? If so, why?

One of the fundamental principles of an agile team is that of cross-functionality. Everyone should have at least a passing familiarity with everyone else’s role, and there should be no one bottleneck within the team. There should also be minimal external dependencies that could prevent the team from delivering its stated sprint goal. If you have an external dependency then you’re betting your own team’s success on something that you don’t control. Tell me how that makes sense, someone?

If you have a crack DBA within your team then that’s one thing. I still don’t think it’s wise, but at least they’re operating within your team. Even so, they’re a bottleneck: if more than one person needs to make a schema change then all but the first person can hurry up and wait for the DBA to be available.

Is your DBA a developer? Does s/he have commit rights and responsibilities just like any other member of your team? Will s/he fix the build if it breaks? Does s/he decide on your class names? Or on your project/solution structure? Then why have them act as a gatekeeper for same? Your database is just a persistent record of your domain model, and should change accordingly. The schema should be updated by your own scripts, kept in your own source repository, and applied automatically by your application. It is part of your application.

Have infrastructure people do infrastructure and software developers write software. Database servers are infrastructure. Databases themselves are software components, not infrastructure.

This might sound like I’m against DBAs in principle. Not entirely, but I am against the kind who feel the need to insert themselves into application design decisions after the fact. To be fair, I’m also against developers who treat databases as an abstraction that they don’t have to understand. My position is that both attitudes are irresponsible.

As a developer using a database you’re responsible for knowing your tools and using them well, and that includes SQL. Likewise, as a DBA responsible for any component of a software development project you’re responsible for knowing your tools, and that includes being able to code to the extent that you can write migrations if that’s what your team needs.