A significant change to SQL Server 2016 is that SQL Server Management Studio 2016 becomes a stand-alone solution that’s available by means of a simple downloadable installer. Not only does this mean that end users will no longer need to hunt down installation media for the SQL Server engine to install management tools, but this change also heralds substantial, long-term benefits as it means that SSMS will be uncoupled from the underlying database engine. Ideally, we should see more regular releases of improvements, enhancements, and bug fixes than what would otherwise be the case should SSMS continue to be released roughly every two years along with each successive new version of SQL Server itself.
As an example of how big this change will be, consider that one of the biggest advances for SSMS 2016 is that it’s now based on Visual Studio 2015, unlike SSMS 2012 and SSMS 2014 that were based on Visual Studio 2010. Out of the gate, this change alone provides the following benefits:
It might not sound like much, but .NET Framework 3.5 was released near the end of 2007, making it over eight years old today.
Consequently, although it might sound snobby to wish that installing an eight year-old dependency could be avoided when installing SSMS 2014, the reality is that Microsoft still provides .NET Framework 3.5 as a download for non-Server editions of Windows. By providing 3.5, Microsoft actively tries to ‘steer’ these same users toward the most recent version of .NET, helping to add a few extra hoops that need to be jumped through to install SSMS.
The process is actually quite convoluted on Windows Server 2012 and 2012 R2 instances, where you can’t simply download and install .NET Framework 3.5. Instead, you need to deploy it as a feature after specifying an alternate location for the media, as this version of the .NET Framework is so old it’s not cached as part of the OS installation process.
One of the great things that Visual Studio 2013 and Visual Studio 2015 brought to the table was a successive set of performance optimizations over previous versions, making Visual Studio 2015 feel pretty snappy compared to Visual Studio 2010. With SSMS 2016, that means SQL Server users finally get some love and performance increases as well.
With SSMS 2014 and earlier, native scaling within Windows notoriously causes freakish outcomes when working with some modal and property windows. A double-buffering trick is available, which works fairly well, only it makes SSMS look noticeably fuzzy at many scalability levels. In my experience, this trick frequently results in weird issues with mouse-clicks commonly getting lost when switching back to SSMS from other applications and the likes. With SSMS 2016, however, all of these issues go away, and SSMS 2016 can be natively scaled and looks great at practically any resolution.
Taken by themselves, the three benefits listed above are probably going to be welcome news for lots of serious SSMS users. My hope, however, is that this these improvements will just be the tip of the iceberg.
By uncoupling SSMS from roughly two-year release cycles will not only hopefully result in semi-regular releases to address bugs and provide enhancements and optimizations, but also start adding in new features and capabilities as the developers working on SSMS will no longer be in a situation where they’re beholden to monolithic release schedules that de-incentivize the addition of new features and capabilities because they take so long to see the light of day and have to be built atop so much existing debt to start with.
Of course, although it might seem optimistic to hope that end users could see more features, improvements, and bug fixes in the future because Microsoft has decoupled SSMS development from the SQL Server engine itself, the reality is that the SQL Server Management team is already posturing that this is going to be the case.
As an example, Microsoft recently opened a Trello board to seek input for new features and improvements from end users. Sadly, the SQL Server team has accrued some less-than-stellar history responding to customer needs in the past, so it will take a bit of time to see how well the SSMS team is able to execute on what appears to be some very real zeal and openness with customers. In looking at the changes that SSMS 2016 already brings and in thinking about what changes we might see, however, I’m more hopeful about the future of SSMS than I have ever been.