Apr 22 2014

I Am Better Than You

That is a patently false statement and total BS. It sure does crawl up your spine though doesn’t it? Why then do we need to do this?

I read an article, “How DevOps is Killing the Developer,” and, frankly, was a little put off by this:

Good developers are smart people. I know I’m going to get a ton of hate mail, but there is a hierarchy of usefulness of technology roles in an organization. Developer is at the top, followed by sysadmin and DBA. QA teams, “operations” people, release coordinators and the like are at the bottom of the totem pole. Why is it arranged like this?

Because each role can do the job of all roles below it if necessary.

Nice to know I’m almost as good as a developer. Now, I could go off on a “bash the developers” rant, but I think that would be seriously silly and counter-productive, not to mention completely against my beliefs. I really do like, admire, respect, developers. I also respect system administrators and SAN admins and QA people, hell, project managers. You can go find a web site or a blog specializing in any of these IT disciplines and locate the “DBAs are better than developers” article or the “QA people save the universe” article or “Thank the gods project managers keep all you poo flinging monkeys in line” article. They’re out there. And every single one of them is wrong.

My actual job title these days is Product Evangelist, but I’ve spend the last 15 years as a DBA, database developer and data architect. I feel like I have a handle on that job. I’ve specialized around the Microsoft stack, not because of any sort of religious beliefs, but because it pays the bills. Before that I worked as an application developer. Before that I was in tech support. And you know what, at no point in my career was any of the jobs I did literally more important than the others. You know why? They’re all in support of the same thing: the company succeeds.

Now, fine, developers are smart people. No question, no argument. Developers are capable of learning other jobs (I’m living proof). But you know what, so are people in all those other positions. How do I know this? Because I’ve worked with the QA person turned developer. She was a GREAT QA person. She was so great because she learned the full stack. She developed an understanding of databases and systems and code in support of doing a better and better job at QA. Then, she finally decided she wanted to fix the code a little earlier and switched over to development full time. I’ve also met the QA person turned sysadmin. I’ve met the developer turned SAN admin. The system admin turned DBA, the DBA turned developer, a million and one support desk people turned developer/dba/admin. Every one of these people followed similar trajectories. They started learning the full stack and found areas where they could specialize while using their knowledge of the full stack to make each position they were in better.

But all these jobs and all these people are all, or all should be, focused on one thing, helping the business to do what the business does, for most businesses, support the customer.  Regardless, the focus needs to be on the goals of the organization, not on the purity of a job, a process, a software stack, or a system. Purity and perfection are dangerous concepts within IT. We need to keep our focus where it belongs, not on MY code or on MY database or on MY servers, but on OUR BUSINESS.

And DevOps (I wish the term didn’t have such bad connotations), is about breaking down communication barriers, not just putting all the work on one person/team. Again, focus back on the business and what the business does.

So no, I am absolutely not better than you (the title is just click-bait). I’m not. But, you’re not better than me either. If my saying that makes you angry, maybe you need to reexamine your assumptions.

Mar 21 2011

Communication

It sure seems like there’s a lot of miscommunication between developers and database specialists. In fact, the communication can become so poor that outright hostility between the groups is common. At the end of the day we are all working towards a common goal, to add value to whatever organization we are working for. It’s a shame that we all lose sight of this commonality and create such a false dichotomy between the groups. I think there are some ways that we, as database specialists, can use to attempt to cross that gap.

Prior to being suborned to the dark side, I was a developer. I had a little over 10 years experience working in VB, Java & C#. I remember, distinctly, cursing our database team for being so problematic about how they did things. They slowed me down. They got in the way. When I had problems they were slow to respond, unless the problems were on production. I know I even instigated a few fights with them in an attempt to get them to move the way I wanted (hard to believe, I know). Then came the day when I shifted over to all database work.

Suddenly, I’m responsible for making sure the production system stays online and that the data is readily available to the business. Now I’m slowing down development, because I want a chance to review their design and validate their code to ensure it’ll work well and not affect production. Now I’m acting as a gatekeeper to prevent unauthorized access to the systems or at least keep people from making any of the 10,001 simple errors that could impact production. Now when a developer wants something fixed in dev, I’m the guy telling them they have to wait because something in production is wonky. And yeah, I’ve instigated fights from this side as I tried to get devs to understand that simply delivering code is not enough and that data persistence is there for a reason (again, shocking I’m sure).

Remember, both of these groups are more right than wrong, and both are working towards that common goal, value for the business. But they really don’t get along. What’s more, what they work on and how they work with it is frequently at odds. Ever heard of the object-relational impedance mismatch? How about the concept that you don’t have a database, but a persistence layer? What about managing data integrity within the application (one of my abiding favorites)? Never heard of those terms or concepts? Then you’re probably a database specialist and you’re probably not talking to your developers. If they haven’t already, they’ll soon be introducing an Object Relational Mapping tool to your enterprise. Best of luck.

A lot of these communication issues probably can’t be solved, but I know of one place where most database specialists are not communicating well with their dev teams, and database guys, it’s your fault. Source Control. Do you think of the structures and procedures within your database as code? You should, because, to a large degree, it is. The Data Definition Language (DDL) calls that make up your tables, views and procedures are code. That code needs to be checked into a source control management system. There, the individual objects can be versioned and managed. There you can create labeled releases of your code. There you can branch your code to create alternate development or support streams that contain variations of your database. There you can merge changes from multiple users and branches into a single main source for deployment to production. There you can keep your database directly in sync with application developers code.

Did you catch that last one? You can become more tightly coupled with your development team. Best of all, you can do this using their tools and their language. This is the communication problem I want you, the database professional to solve. Very few of us database types are using source control these days. This, despite the fact that there are fantastic tools and methods under development from different vendors that directly address the issue of getting and keeping database code within a source control system.

Years ago, when I first made the jump to databases, I was appalled that I couldn’t keep my code in source control. Then, as I worked more and more with databases, despite the problems, I abandoned the idea of managing the code in source because, frankly, it was way too hard. But several years ago new tools appeared on the market to make it possible (if still somewhat painful) to get the database into source control. I’ve been working that way for years now. It has completely eliminated one of the many problems I used to have with developers. They now know that my code is stored with theirs. That my versions are their versions. That their labels are my labels. That we branch the code together. It’s taken completely for granted, and we share a common language about change and deployment.

This has not solved every problem or conflict with database teams I’ve worked with. It has eliminated a source of friction. It has increased communication. It’s something that I could do, and you can do, to get a little closer to your development team. Not to mention the fact that you will now have your databases in a known state, all the time, that you’ll be deploying from a single location, that you can manage access to your code, and all the other things that having your databases in source control will bring.

For more details on the concept of putting your database in source control, and working better within teams in general, I’d recommend reading the SQL Server Team-based Development book. It’s a free download.

Addendum (3/27/2011): If you got this link through an email, could you post a comment below as to which distribution list it’s from? Thanks.