Pages

I first stumbled into the world of computing as of all things a DBA. From the beginning I’ve heard of this ongoing holy war between Developers and DBAs. Over the years I’ve seen the battles from both sides of the fence.

After years of watching the battles, I think the war is finally over. These days I write more C# or Objective-C then PL/SQL I still consider myself a DBA at heart. So with a heavy heart, I fear that the developers have won.

Prove it you say? I wish it was harder, but all you really have to do is ask your favorite DBA something about Agile, Test Driven Development, or Design Patterns. Embarrassingly these practices have not been embraced by the DBA community.

Still need more proof? As with anything this is just my opinion, but I have noticed over the past five years or so when I speak with organizations their DBA groups are usually with Platform services groups. I can’t think of one case in which they where linked with Product or Service development. Has our failure to evolve and our default answer of “No” effectively taken us out of the fight?

Is it over for the data community? I surely hope not. We’ve got better tools, methodologies, and platforms then ever before. Just like all of the Rocky movies the data community needs to stage a comeback and learn a few new tricks.

Taking a few tricks from the developer and Agile communities here are a few sure fire ways to jumpstart your personal comeback.

Understand ORM’s better than your developers

No matter which side of the holy war you fall on, Object Relational Mapping frameworks are here to stay. They make developers more effective and avoid the mental context switch languages.

No matter how good the tool, the DBA will always better understand how to leverage the data model. Instead of banning your developers from using these tools, learn them. You have an advantage since you know the technology from the bottom up. These tools are not black boxes, and most of the mature frameworks offer extension points, allowing for you to write specific SQL or Stored Procedure code.

This provides the developers with their productivity gains, and provides you an opportunity to contribute scale, performance, and reliability to the project.

If your organization has adopted Agile as a software development methodology you need to attend the daily stand-up. In my experience DBAs are often not included or do not attend these meetings. Find time or a reason to attend, these meetings tend to be the heartbeat of the project, and an excellent chance to contribute to areas both inside and outside the database.

Learn to evolve your designs

Sometimes I think DBAs pioneered the concept of “Big Design Up Front”. Maybe it is just that the Erwin model is too hard to change. Whatever the reason, your design must be flexible enough to evolve over time. A simple Google search returns over 2 million results for refactoring tools. With tools by Oracle, IBM, Microsoft, and others design evolution has gotten easier and is supported on whatever platform you might be on. Take a lesson from Ruby developers, refactoring and code evolution are necessities to meet ever changing business requirements.

Learn Design Patterns

Ever wish you could tell your younger self how to avoid all of your bad decisions? Design patterns is the technology communities way of doing that. Knowing even the basics for design patterns helps you avoid mistakes made by others, allowing you to make other new mistakes.

Design patterns are not linked to any specific technology, allowing you to apply similar patterns to your data models as your Java developers do to their classes and entities.

Do you know someone that has 20+ programming languages on their resume? That might be going alittle overboard but, knowing a few programming languages can do more then just get IT recruiters and HR Managers attention.

Learning how languages interact with our data model, is vital to understanding systems as a whole. I’m sure you’ve heard the stories of developers loading the entire database into arrays and looping to create joins in the server layer. Knowing and understanding the languages and frameworks your development team uses allows avoid the blame game of it’s the database or it’s the App Layer.