Database Underground | Sean McCown » Why Doesn't Microsoft Care about DBAs?

November 28, 2006 | Comments: (0)

Why Doesn't Microsoft Care about DBAs?

TAGS: SQL Server

I got a chance to talk extensively with some of the MS dev team at PASS. Specifically, the new VSTS for DBAs team, or part of it anyway (Gert Drapers and Cameron Skinner). In our discussions about MS's current vision for the product, it became very clear to me that MS really doesn't hold DBAs in much regard. However, apparently, developers are the bee's knees.

The main problem that I outline in VSTS is that you have to go into VS.Net to use it instead of being able to access it from SSMS, which is where DBAs spend all of their time. Not only has the DBA been left completely out of this equation, but the more popular dual-role guys are hardshipped as well because they now have to keep 2 tools open. The presumption that DBAs don't need an easy way to get at code is absurd. I get the idea behind it though... offline editing. Everything you do to the code is done offline and kept away from production. That still doesn't mean that you have to keep everything separate though. They said they wanted to help close the gap between devs and prods, but everything they're doing is keeping us apart. It's now very apparent that anytime you want to develop something, that you have to go through VS. Look at this this way... for a DBA to have to go to VS to code is a huge pain. For starters, none of their connections are there. They have to define all new connections, and if they change, he's got to keep them up to date as well. Even the help files are kept separate. Have you ever saved a help topic in favorites and then tried to retrieve it from VS help? It doesn't work.

I'm a DBA, and when I write code, I write it in SSMS, not VS. So for me to put something into the code vault I have to now cut and paste it into VS. So, VS becomes nothing but a way for me to source my code and that's it. There's also nothing in the way of a decent auto-complete feature in SSMS. There are some really thoughtful features... in VS. SSMS doesn't really have anything all that earth shattering in the way of features, and most of the ones it does boast tend to be so impossible to work with they're not even worth using. The mgmt reports are a good example. They're so slow to bring up, they're almost not worth even having. And have you ever tried to right-click on a table and bring up a 'select to' menu? It's like getting blood out of a turnip. Most of the time it's just so slow, it just drags on and on and on and on and on and on and on... well, you get the idea. Whereas in QA (Query analyzer), these things were very fast and I've only ever had very minor problems with it. QA was written by Gert Drapers, btw. However, SSMS falls short and I haven't talked to anybody who's happy with it. It's got some good ideas, but none of them have materialized to anything useful yet.

I was really hoping they'd fix some of these problems in SP2, but that so didn't happen. Why, you may ask? Well, the answer's simple. MS doesn't care about production DBAs. The message is clear... if you have any serious development to do, do it in VS, not SSMS. Apparently no self-respecting developer would be caught dead in SSMS, and no DBA could possibly be serious about development if they insist on coding in a front-end tool.

I would like to see a feature pack come out very soon that contains just the client tools. They could address all of the issues with SSMS and really give DBAs something to work with. Every single dev I talked to said that he knew about the problems in SSMS. And why wouldn't they... it's been a year. So why weren't they fixed in SP2? That's right... you guessed it... because MS doesn't care about DBAs. If the same problems existed in VS I can guarantee you they would have been fixed by SP1 if not sooner.

Now, one more thing. While it's true that DBAs have to go to VS to develop if they want to us VSTS, it could be argued that MS is using this model to conform with the separation of duties control in most audits. Making DBAs keep their functions separated forces those dual-role guys to be more aware of what they're doing and of the fact that they're actually switching roles. I doubt MS really had that in mind, and I'm sure now that I've said it they'll be like... yeah, that's why we did it... I'm glad you finally figured it out, now get off our backs.

That's fine guys. I don't mind. The idea does have some merit though. I'm sure I don't have to flesh out the whole discussion for you, but the separation of duties angle could be the way to sell this to DBAs who just complain and complain about little stuff like this. I'm just glad I'm not one of them.

Posted by Sean McCown on November 28, 2006 10:55 AM

RATE THIS ARTICLE: