An Interview with Microsoft's Ken Van Hyning

Last week, I sat down for a quick chat with Ken Van Hyning (@sqltoolsguy), the Engineering Manager for SQL Server Client Tools at Microsoft. If you haven't heard of him yet, you will - this is the guy who has pledged to undo years of inattention to the tools we use to manage SQL Server every day, most notably Management Studio (changes that I also blogged about today).

What is your title, and how did you get here?

Principal Engineering Manager, 16+ years at MS and in SQL Server since 2007. Worked in System Center prior to SQL. In SQL: 2007-2011 was Dev Manager for Manageability. From 2011 to 2015 was an engineering manager for SQL Azure. Moved back to take on SQL tooling again in the Fall of 2015.

Prior to Microsoft, I was in three startups: VersaCAD, ProTools, and a founding engineer of Kaspia Systems. All were great learning experiences, and Kaspia Systems was acquired by Visio and in-turn Microsoft in January 2000. My career focus and passion has always been in the tooling area and over most of the years in a network or systems management niche. SQL Server provided a unique opportunity to take on some new challenges personally and be a part of a great team and product.

The time working on the SQL Azure was an important culture change for the organization and for me personally. The most impactful change is the removal of the numerous insularly layers between our engineering team and customers. In my homecoming to the SQL Client Tools team, I am excited to bring this same culture to how we deliver our flagship tools like SSMS. Personally, I see SSMS as the “UI” of SQL Server and candidly we haven’t invested in it as much as we should have over the last few years. That’s going to change now. We are moving the engineering to the front lines with our partners, MVPs, and customers.

What are your immediate and long-term goals for SSMS?

The immediate goal for SSMS is to focus on performance, reliability, and the backlog of customer requests we have gotten over the years. Our methodology is to make this generation of SSMS “universal.” That is, you won’t see it tied or branded to a specific version of SQL Server. We are also switching to continual improvement via monthly releases, and leveraging telemetry to enable us to get insights into where we need focus our efforts.

Longer term, SSMS is our flagship SQL Server management tool. We will continue to invest in it to provide rich management capabilities for all the various flavors of SQL Server. I expect you will see us make further investments to rationalize the overall toolsets. Things like better component sharing between SSDT and SSMS (connection dialog, editor, etc.). A better solution for Profiler and .trc vs. XEvent. And of course, with the announcement of SQL Server on Linux, it is fair to expect SSMS will fully support managing a SQL Server instance on Linux.

What has been your biggest success so far?

Our biggest success so far is the core separation of the tools from the engine code-base, build, setup, and release systems. This took the team the better part of a year. The SQL Client Tools have well over 1200 project files and roughly 20,000 source files We had to detangle source, build, setup and runtime dependencies with the engine codebase that have been built up over the last 10-12 years. It has been a huge undertaking and not the most glamorous work, but I am very proud of the team getting SSMS and the other client tools set up so we can now ship on an independent monthly release cycle. We are all very excited to start reaping some of the return on our investment and get our users some long-awaited improvements.

What do you see as the biggest challenge?

The biggest challenge is also our biggest asset; our codebase. SSMS and the SQL Client Tools as a whole have a vast amount of IP that has been built up over the years. There are hundreds of dialogs within SSMS, so when we want to make improvements there can be a lot of inertia to overcome. High-DPI is a good example. We very much want to do this task, but due to the vast amount of code, it is a very large project for us. Similarly, changes like adopting the new Notification Center in the VS 2015 shell will be excellent for centralized notifications of long running tasks. We hope to have that package enabled soon. However converting all the dialogs and wizards to use it is again a pretty huge undertaking. Not just coding, but test wise as well! So while we are excited to modernize the experiences within SSMS, one big challenge is to do this while maintaining usability and consistency.

There is also one other big challenge for us. We know that the tools haven’t gotten a lot of attention the last few years. Many requests have simply sat in the digital basement collecting dust. The result, and rightly so, is a fair bit of skepticism and cynicism that we are really going to do anything significant in regards to the tools. I think on this front, it will be best to let our monthly releases and our hands-on engagement speak for themselves.

What has been the funniest thing that has happened so far in this project?

This question is a bit tougher for me... I’m not sure if they are funny or not but it makes me laugh. :-)

As we have been rebuilding the SQL Client Tools team over the last several months, we have a lot of new engineers. Many of which have been at MS for only a few years now. Being in SQL everyone knows of SSMS of course, but it’s been great time after time showing folks how many things are there. They have no idea how vast it is. UCP is kind of a running joke as one of the most unknown, unused, but massive features hiding within SSMS. I show folks how registered servers works, what CMS is and they get all wide-eyed. The fact that we have things like Point-in-time restore all the way to an AG dashboard. And oh my, the first time I explained what PBM was and the server-side enforcement through SQL Agent. Even I keep finding things that folks have added over the years that I didn’t know were in SSMS now. Sometimes we feel like we are on an archeological expedition and we keep finding troves of SQL Server manageability treasures.

How many people are working on the SSMS team?

We have about a dozen engineers on our core team. The core team covers SSMS as a shell and a good number of the RDBMS-related features. We have partner teams for BI and IS. We also have a partnership model from various SQL engine feature teams that do iterative work on various parts of SSMS. We also have partners from the Tiger team that help out on some features as well. So it’s really hard to say any total number at a given time.

In addition to SSMS, our core team covers SQLPS, SQL Agent, Profiler, SQLCM, Data Collector, and MDW.