In an article posted by Phil Factor on SQL Server Central he relates how SQL Server Management Studio had to undergo some pretty significant changes in order to support rapidly delivering improvements.

“SSMS got very little love over the years and was merely patched to keep up with SQL Server’s new features. It seemed to most observers that it was in line for ‘sunsetting’, though insiders will only admit that it somehow got neglected, in the same sort of way that one loses the remote in the cushions of the sofa.

What really went wrong for SSMS? Its problems had come with SQL Azure. Because SQL Server in Azure is hosted, it can be updated rapidly. With more rapid developments with ASDW and SQL Azure, SSMS had to be able to keep pace or die. Various attempts were made at hosted replacements for SSMS over the years, before Microsoft finally decided that what was required was an easily-updated SSMS. The idea of regular monthly release was a radical one that required that a lot of behind-the-scenes work had to be done before we, the users, saw anything good happening.

Basically, SSMS had been bound up with the ‘classic’ on-site SQL Server and its two-year release cycle. Before it could be released, there was a rats-nest of dependencies to sort out. For example, SMO had evolved from being the powerhouse behind SSMS to being used by both the server and workstation. PowerShell had grown to become the obvious means of automation for server-based processes via SQL Agent as well as for the workstation-based administrator via SSMS or from the PowerShell console. An example of the problem was that SQL Server’s PowerShell components had been included in the SSMS (tools) installer as well as the SQL Server engine install. This required a redesign of the architecture, with the aim of avoiding sharing components with the SQL Server engine.”

Like any team, I am sure the developers were making the best decisions they could at the time based on their resource and deadline constraints and none of them were actively looking to build something where “there was a rats-nest of dependencies”. The story also offers hope and reinforces that very few decisions made today cannot be changed in the future as new needs arise.

As we continue to evolve our QA processes, stand up continuous integration, host solutions, or whatever else may happen in the future, some of our current patterns and processes will naturally change to support them. We will then go through another round of assessment and improvement as we implement what we learned.

Everyone likes to create amazing things and the challenge is always determining the appropriate level of complexity. Some items may require a lot of forethought, while others may just require someone to use their creative juices and solve the problem before we pre-assess and improve what has not been tried.

The key is to try and keep the main goals in sight and keep solutions as simple as possible.

Note: Check out the first paragraph of Mr. Factors bio if you noticed the SQL-like Pseudonym.

Do you have thoughts on continuous improvement or creating simple solutions?

Do you have a Pseudonym or Nickname?

Let us know in the comments below.