Thinking About SQL Server Developer Tools, Codename “Juneau”– Part 1

<Disclaimer>

Folks that are familiar with Visual Studio 2010 SQL Server database projects will find most of this post to be old hat. Additionally, the contents of this post are the opinions of one PM and don’t reflect the opinions of my Architect, GPM, GM, or Microsoft as a whole.   ;-)

</Disclaimer>

When I first joined the team, it took me a bit of time to grok SQL Server Developer Tools, Codename “Juneau” (SSDT). I like to think that I’m a relatively intelligent guy, but in the beginning I just had a mental block on the product. I just didn’t “get it”. It took some time, and patience, from the other members of the team to get my head in the right space. At first this worried me, because if I didn’t get SSDT how would Microsoft expect our customers (many of which will have backgrounds like mine) to get it?

Enter the first of a series of posts. I’m guessing that a lot of folks will be in a similar spot where I was when they start taking a look at/playing around with SSDT. I’m not going to lie, if you are like I was (i.e., SSMS is/has been your SQL Server development tool) there’s a learning curve to SSDT. However, now that I’ve scaled the learning curve I can honestly say that the effort is well worth it – so much so that if I started consulting again tomorrow I would be advising my clients to adopt SSDT. The goal of these two posts is to begin the process of flattening the SSDT learning curve.

Being a big fan of Joel Spolsky, I’m going to use concepts from his most excellent book on UI design in describing, IMHO, the best way to think about SSDT. In Joel’s book the concepts of program and user models are key in designing a quality user experience. Not surprisingly, understanding SSDT in light of these concepts goes a long way in groking how to use SSDT and the UI decisions we’ve made in the product. Given the importance of these concepts, I’ll provide some definitions paraphrased from Joel’s book:

User model: The collection of expectations a user has regarding how to interact with a new software user interface, resulting in the user’s mental model of how the software should function.

Program model: How the software actually functions (i.e., how it is coded), which is a reflection of the user model of the team that developed the software.

The above concepts are simple, intuitive, and powerful. For example, given that the almost universal user model for word processors is WYSIWIG, a team that writes a revolutionary new word processor that isn’t WYSIWIG is going to need to provide great facilities/guidance for their customers to shift their user models to the new program model.

When I started on the SSDT team my user model for developing SQL Server databases was formed by the program models of the development tools I used. This is only to be expected because the program models of SQL Server tooling has essentially remained the same from SQL Server 6.0 through SQL Server, Code Name “Denali”. The following screenshots illustrate this model from SSMS 2008 R2:

The program model of SQL Server tools is imperative development. That is, when using SSMS the database developer crafts T-SQL code instructing the SQL Server engine on what exactly to do to create, alter, drop, etc. the desired database objects. This is worthy to note as writing T-SQL queries is, by way of comparison, declarative – the database developer tells the SQL Server engine what she wants done (e.g., SELECT * FROM Customer) and the engine figures out how to do it. As any application developer can attest, traditionally you spend a lot more time doing imperative SQL Server development early in the development lifecycle than you spend doing declarative development. Given the tools, it is easy to see how the typical developer’s user model for developing and querying SQL Server databases came to be in alignment with the underlying program model of the tools.

Because it serves my purposes for this post (which will be come clear in just a bit), I would also like to mention that SSMS supports two methods of performing database development – Connected and Project. The first is a no-brainer that every SQL Server developer is familiar with and is illustrated by the screenshots above. The second is less well-known (I only learned about my self about a year and a half ago) and is illustrated by the following screenshots from SSMS 2008 R2:

From a user/program model perspective, working with SSMS projects to develop a database isn’t that much different from doing connected development – the model is still imperative in nature.

All of this is important in thinking about SSDT because I can now construct the following table that lists the typical SQL Server database developer’s user model for various SQL Server database development activities and compare these with the user models needed to properly grok SSDT:

As the table illustrates, we’re changing some things in SSDT. However, as I mention above, I’m fully convinced that we’re changing them for the better.

The subject of my next post will be to talk about the decisions we’ve made in SSDT based on the table above and how these decisions manifest in the UI.

Until next time, feedback most welcome and thanx for reading.