THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Merrill Aldrich

Technical content about Microsoft data technologies. All opinions expressed are purely my own and do not reflect positions of my employer or associates.

Dear SQL Tools Team(s): Stop Starting Over. Seriously.

I have two little boys at home, and my parents were both teachers. It gives me a strange relationship with our public schools – I am passionate about them, and the quality of education I want for my kids, but I have to keep my distance a little, lest they drive me completely around the bend. One reason it’s so frustrating: among all the complex challenges our schools face, administrators and school reformers alike are stuck in an infinite loop of starting over again before anything is finished. Before one curriculum is complete, someone wants a new one. A new educational idea arrives on the scene before the last one even gets a chance to be evaluated. We have to break eggs to make an omelet, but all we do is the egg-breaking part. And our school system is the very apex of the idea, “too many cooks in the kitchen.”

Sadly, the people working on all the flavors of SQL Server management tools seem to me to be stuck in the same type of self-destructive loop. For now six or eight years, depending how you count, the management tools for SQL Server have gone sideways, or around in a circle, instead of forward.

Five Versions 2.0 != One Version 10.0

This post was prompted by a short exchange I had on Twitter this morning. Someone asked a simple question: Why is there, again, another management & dev tool for SQL Server. My off-the-cuff response was that the team at Microsoft keeps on starting over again instead of moving forward. But the more I thought about it, the more I realized that that is literally true: through Management Studio, BIDS, Team System/Data Dude and now Juneau, and even to some degree Crescent, the various tools teams continue to slide sideways, and deliver sort of disjoint, bland, V 2.0 mediocrity. We need version 10 at this point, not version 1 or 2 again. Really.

This isn’t an attack on any of the developers working hard on those tools and features. Some of the specific features and capabilities are really interesting. The problem is with the process – just as in some fundamental public school issues. In the current vernacular:

(Smart People + Good Intentions) * Deeply Flawed Coordination = #EPICFAIL

There are a lot of good ideas. There are a lot of challenges. There are a lot of conflicting requirements and conflicting opinions about what a tool like this should be. That’s what design is for. If the problem were simple, design would not be necessary. This is just a design problem.*

80% of Good Design is Synthesizing Conflicting Requirements

So it’s a hard problem. Administrators want administration tools, monitoring, troubleshooting. Developers want development tools, code writing environments. BI people maybe want graphical programming tools like BIDS SSIS projects. We all want the tools to be elegant and simple to use. I get that. But that doesn’t mean you’ll solve the problem by ten years of starting over again, annually, creating different flavors of the same tools. It gets solved by leadership, visionary design, and synthesis. It is possible to make one environment that meets all these needs. But it takes conviction, courage, time and, most of all, design.

What do we have now, six years or so into the SSMS “era?”

  • Still total inconsistency in the way SSMS treats basic features like scripting objects.
  • One passable query writing environment in the SSMS query window itself, which somehow(?) has not made it into any other place in the whole suite of products. There is no even C- level query editing capability in any MS BI tool, for example. It’s not even in the Table Designer. But the code’s been sitting there in SSMS all this time.
  • B- Intellisense, with better provided by a third party.
  • No code formatting, again with a fine third party solution.
  • The object tree in SSMS has had the same cruel joke of a design, that most people seem to either barely tolerate or hate, this whole time.
  • Activity Monitor. Ugh.
  • A query plan viewer that is so stale, so old fashioned, that a third-party company (and thank you SQL Sentry) could walk in and create a free one that is many times better.
  • Decent diagnostic data from the engine (DMV’s) with NO decent UI associated.

The reasonable thing would have been to put someone with some design sense on this problem to improve the tool. Version 3, version 4, version 5. Forward progress.

Instead, people complained from outside MS, and people within perhaps had some new ideas, but instead of having the courage to synthesize those challenges into a better product, we keep going in a circle. So I am begging: would someone please stand up over there in Redmond and say, “enough.” I want SSMS 3.0.

* This is the thing Steve Jobs, love him or hate him, “gets.”

Published Saturday, August 20, 2011 4:52 PM by merrillaldrich

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Peter Schott said:

I'd actually appreciate it if the Dev team for SQL Tools even gave the appearance of sitting down with people who work with SQL Server every day. Whoever thought "let's build a SQL Server interface on top of Visual Studio" didn't get it. We work primarily with SQL, not code. Whoever keeps thinking of more ways to get our hands on a mouse instead of keeping them on the keyboard doesn't get it. Whoever decided that the expressions in various portions should be one line and small doesn't get it.

Of course, when you mention this to MS, they seem to think that it's either a big joke or an "opportunity" for other developers. Design sense would help, but so would actually listening to the people using the product daily. Perhaps not trying to shove everything into the same environment would make more sense - TSQL, Reports, ETL, etc - give each a tool that makes sense instead of an all-in-one approach, building on what's currently there.

August 20, 2011 7:18 PM

merrillaldrich said:

Yep - design of software, when done well, meets users' needs and desires. Getting to that can be complicated, but that has to be the end point.

August 20, 2011 8:25 PM

Antony said:

I've always preferred to script things rather than use a GUI, so the lack of progress in SSMS UI has never really bothered me - though i would love to see something even half as good as SQL Prompt as part of the tool.

What I do wonder though, given how many people DO love the GUI, if thats one of the reasons why really useful features such as database snapshots and service broker haven't really taken off as much as they should have - because there is absolutely zero GUI support for them, beyond a node on the object browser.

August 21, 2011 2:28 AM

merrillaldrich said:

My take - the GUI is a really important entry point for a lot of people, even if they end up using scripts or automation later (or not.) It can be a great way to find features and get familiar with them.

I think you're right - good features that are not well represented right there in the GUI are a whole lot less likely to get traction. That might be "wrong," in the abstract, but I think there's truth to it.

August 21, 2011 2:40 AM

Thomas Williams said:

Hi Merrill - some well made points. I agree that consistency would really benefit the GUI/object browser - some features seem to have GUI priority ("Snapshots", "Database Diagrams") but just don't feature in my day-to-day work. Would love to hide/relegate/remove them.

August 21, 2011 7:11 AM

Armando Prato said:

I'm with you on this topic.  Why is there no code formatting utility?  Why can't we control the object scripting layout?   It drives me nuts because they seem like basic features that should be there.   As a result, I've written my own scripts to perform these basic tasks.

August 21, 2011 11:09 AM

Anonymous said:

The reasonable thing would be for Microsoft to create a proper extensibility model, strip out all of the fluff, step back, and let third-party vendors and the community take charge.

August 21, 2011 1:25 PM

Paul Bell said:

I agree completely. The Management tools appear to be a half-hearted attempt (like documentation produced by developers) rather than something you would want to use every day.

August 21, 2011 10:26 PM

Henry said:

Yeah, the amount of third party stuff I end up using is a bit depressing to say the least...

When in 2005 they completely made debugging a pain, it used to be so easy.  Or activity monitor which if it's goal was to push you to use sp_whoisactive or sp_who2

Should the development tools for SQL Server and the admin tools be different at this point?

August 21, 2011 10:54 PM

KKline said:

Amen to that, Merrill.  I couldn't agree more.  And I think Adam has an excellent point too.  Microsoft R&D spends a lot of time re-inventing the wheel over and over again on elements of the stack that could be more than adequately handled by others, while things that ONLY Microsoft can work on inside of the various engines languish.

August 22, 2011 8:12 AM

merrillaldrich said:

Definitely. It should be a decent, base platform with clear, well designed functionality AND with a reasonable way to extend with plugins, etc. After all these years it seems like that could be complete by now.

August 22, 2011 12:56 PM

Jens said:

Good to see someone cry out, Merrill!

On a good day I can live with most of the items on your list, with great help from 3rd. party tools. But, "breaking changes" seems to be missing. Having to deal with mediocre dev/adm tools is one thing, Having to sell the same report to a client all over again, due to incompatibility is another game. Whats to stop MS from doing it again?

August 22, 2011 3:04 PM

Dave Pendleton said:

I wonder why the SQL community hasn't taken something like this on (think Paint.NET)?

August 22, 2011 3:18 PM

mjswart said:

You worried in a tweet that this post came off as a big rant. Not at all Merrill, so don't worry there.

And very well put. I agree completely (just like I agree with Adam's suggestion)

(And while I'm at it, three cheers for SQL Sentry's plan explorer.)

August 22, 2011 4:20 PM

Allan Hirt said:

SSMS tries to be all things to all people (mainly DBAs and devs), but fails at both. To me, SSMS is and should be more of a true MANAGEMENT (hence the M) tool for DBAs with some dev-ish aspects. The old SQL Server 2000 Enterprise Manager was a much more effective tool in many ways. My favorite example of a great tool for administration is Failover Cluster Manager from the Windows folks. SQL could only hope to ship something nearly as good I think. Don't get me wrong, I love SQL Server but SSMS is a chore to use and is way bloated.

Visual Studio is no way to code an admin tool. MS has a standard (see: FCM again; it's a snap-in - nearly everyone uses it). Use it.

August 22, 2011 9:47 PM

Victor Isakov said:

Not sure if I agree Adam... Specifically about letting "the community take charge".

Virtually all SQL Server "community" projects on Codeplex are even more under-baked. Definitely not production ready. Consider SQLNexus, DMVStats, and others. Difficult to use. No "polish".

Ones that have been more successful and "polished", such as SQL Server Internals Viewer and FineBuild represent where one person has devoted all their time and effort, until "something changed" so as to make it harder to maintain, etc and thus it ended up on Codeplex.

August 22, 2011 11:10 PM

Victor Isakov said:

Kevin, I don't think it's as simple as "while things that ONLY Microsoft can work on inside of the various engines languish." which implies that developers from the storage engine are being transferred to work on the tools. In most cases, people from other teams, such as System Center, have moved into the SQL development team to works on the tools, etc.

That's why the SQL Server development team is so much larger than in previous versions.

I would suggest that "work on inside of the various engines languish" due to poor communication between Microsoft and customers. (Of course there will be some reourcing constraints as well.)

August 22, 2011 11:15 PM

merrillaldrich said:

You know what's funny: I've often thought idly about whether it would make sense to write a whole replacement for ssms. Never acted on it because a. I have a day job and family :-) and it would be a HUGE undertaking and b. People are so cheap, generally, when it comes to a tool like this, it would probably have to be free or it would have a very limited audience.

August 23, 2011 12:45 AM

Allan Hirt said:

Merrill, I had an idea for another tool (non-SSMS related), but the time/cost to develop with folks vs. what I'd ultimately earn back given my normal workload made it a no-go. Maybe someday ...

August 23, 2011 2:11 PM

Jonlee Lockwood said:

I wonder what size of the standalone install will be?

Excellent points. Maybe they want ALL Devs to be DBAs?

August 23, 2011 4:27 PM

Eric Humphrey said:

Agree on all points Merrill, though I would grade their intellisense a C at best. Tools like SQL Prompt and ReSharper in the C# world have raised the bar.

Not saying it's better, in fact I don't believe it is, but there is already an alternative to SSMS: Toad. If the community is responsible for tooling, I think we'd wind up much like Oracle.

August 23, 2011 4:49 PM

Alexander Kuznetsov said:


Give the SQL Server dev team some slack -  I think it is not their fault.

I am completely with Victor on his "poor communication between Microsoft and customers" remark. Just think: the best and most influential customer feedback, money, is completely eliminated from the process. Even if we know for sure that we will never use SSIS, or intellisense, or Database Diagrams, we still have to buy the whole package and sponsor further development of things we are not going to use ever, or even strongly dislike. If you can show me just one case when such process yields high quality output, show me - I know none.

Another important cause of the pain you are describing is the way the product is licensed: instead of paying annual fees and upgrading only when we feel like it, we pay for the licensing once. This is a strong incentive for frequent updates, way more frequent than most of us would prefer. Joel Spolski wrote up a great article on this thing; he went into much detail; his article is a must read.

These frequent updates make development of third party tools around the core product less profitable if at all. Again, Joel Spolski has written a must read article entitled "Fire and Motion". Basically he argues that when we react to others' changes we lose initiative and make less money. If you haven't read this article yet, i encourage you to do it now.

For example, consider JetBrains and their great products, such as ReSharper and IntelliJ - many developers pay considerable money for their top quality products, even though there are free or cheaper alternatives. Their GUI rocks. Their IDE for Java, IntelliJ, is very popular even though it is not exactly cheap, and there are lots of free, and good, alternatives. IntelliJ is a totally awesome IDE - I wish they developed one for C# as well. ReSharper is also very popular even though some basic intellisense comes with Visual Studio.

I believe a few years ago JetBrains actually had plans to develop an IDE for C#. Yet to my best knowledge they never released it. Lesson learned: even a top notch JetBrains team with excellent track record and lots of fans among C# developers does not directly compete with Visual Studio. Based on that, I doubt that it would be profitable to develop a third party alternative to SSMS, which would probably have much less potential customers that a C# IDE.

It is unlikely to have a quality product without competition, which (competition) is probably not profitable because of frequent changes, which (frequent changes) are caused by the licensing approach. So, as long as the current way of licensing remains unchanged, I would not expect any improvements in quality of SSMS and other tools.

August 23, 2011 10:36 PM

andyleonard said:

Great post, Merrill!

  I think part of the disconnect lies in the delta between application development and databases. Reading through some of the comments above (and everone makes good points), the comparisons to developer add-ons for development environments aren't a fair comparison - unless you're an application developer.

  I often joke to software architects and developers who use ORMs: "I'm going to write a stored procedure that generates C# classes."

  The reason that's kind of funny (and the comparison unfair) is because SQL Server Management tools aren't written in T-SQL. This is not a statement about the capabilities of T-SQL - it's a statement about the type of thinking required of those who build SQL Server Management tools. Given that, I think the Microsoft teams do a good (not perfect) job.

  I like Adam's idea of Microsoft exposing more functionality via APIs. The database tools and add-ons built by third parties (BIDSHelper, PlanExplorer, SQLPrompt, SSMS Tools Pack, etc.) are awesome and no one expects Microsoft to think of everything.

My two cents...


August 24, 2011 11:27 AM

Anonymous said:

Andy: "No one expects Microsoft to think of everything." Except Microsoft. Its attitude (at least, that of the SSMS team) is that it can--and will--do exactly that. Even though everyone in the real world knows better.

August 24, 2011 1:15 PM

Jakub Dvorak said:

My personal oppinion is that Microsoft doesn't really know what to do with SSMS in next years. They are adding more and more database features in Visual Studio .NET but only few features to SSMS. On the other hand they state that SSMS is still main tool for core T-SQL developers. It's mystery for me because many horrible things stay same in SSMS for years!

One thing I was missing from the very beginning is support for logical groups/folders in SSMS. Or sort of "project oriented view" instead of core database view. If you have hunders of objects and expand tree in Object Explorer you must deal with them all. I tried to fill this gap with my SSMS add-in, check it at .

August 30, 2011 2:48 AM

silk said:^Eescort.html^Eescort.html^Eescort.html^Eescort.html

February 9, 2019 8:20 AM

Leave a Comment


This Blog


Privacy Statement