Scaling Agile Across the Enterprise

Earlier this week we, the Developer Division at Microsoft,release a series of short videos telling the story of how we made the transformation from our old waterfallian ways to a scaled agile way of working.

Here is where you can find all of the videos.

This is the story of a division of 3,000+ engineers who had been following a well defined waterfall approach for years, even as we were advocating Agile and all of its virtues. In truth, we weren’t the hypocrites that statement indicts us as. In fact, we had small agile teams popping up all throughout the division for years. In true agile fashion, the momentum grew as more and more small teams saw the value in Agile. We had many small agile teams working within a waterfall framework. As the momentum grew we decided to make a change.

I love the was Soma (S. Somasegar, our Corporate VP) puts it when he talks about how he made a decision about Agile. He says the decision he made was not to implement Agile, it was top not stop teams from trying Agile.


As our business needs changed and the need for our release velocity to increase, Agile gained more momentum, until a few years ago when the momentum had grown enough that we decided to formalize Agile across the division. That meant getting the entire division onto the same sprint schedule (we have 3-weeks sprints, and all teams start and stop sprints on the same day). Over time we moved into a new building that was designed with Agile teams in mind (team rooms, focus rooms, etc.).


Today we are on sprint #66 and we have had countless releases since we began this transformation, including releases of Visual Studio Online every three-weeks, and internal releases of the Visual Studio clients, to several public releases of Visual Studio (2012, 2013) and related updates.


I encourage you to check out the video series (rather than have me retell it here). There is some great insight shared by my peers and me, and lots of footage of how we work, where we work, and what we do.

Here are links to the individual videos in the series.


Everything we do around development — collaboration, testing, and customer feedback — has changed.


Waterfall vs. Agile

Today, we think about how fast we can translate an idea into reality, and get it into customers’ hands.


Visual Studio Transition

We needed to work more incrementally, deliver to customers faster, and let feedback make the product better.


The Agile Shift

We didn’t decide we were going to be agile starting tomorrow. There was gradual buy-in with teams and leadership.


Physical Transformation

We moved out of our individual offices, and put teams together into the same room.


The New Normal

We need to make sure we’re hearing our customers, and learning from them as we’re building the software.


Employee Response

We’ll talk about what’s working and what’s not working… the idea is continuous improvement.


Measuring Success

We need to know that what we’re building scales for software teams around the world.



Your software development efforts have to aid your business. That’s why they are there.


Overcoming the New Visual Studio UI

In a blog post last week, Monty Hammontree, the Director of User Experience for Visual Studio, announced the UI refresh for Visual Studio. This is a project that I had some involvement in (mostly as a reviewer) while still at Microsoft, and have been waiting patiently for this announcement so that I could talk about it.

iconRefreshPersonally I love the new UI. Sure, its not perfect, but it is a huge improvement over where Visual Studio has been for the past ten years. What is surprising to me is the amount of negative reaction the blog post has gotten. Some of my favorite comments from the blog post are:

Okay, i get wanting to reduce distraction and “lighten” the UIs feel… but GEEZ! Why do good ideas always get taken too far? This UI is SO bland and SO dead, I’d be afraid of it putting me to sleep on the job as opposed to reducing distractions. ICH! – Aaron – 23 Feb 2012 10:20 AM

Is it a desktop app?  Is it a metro app?  Decide and stop mangling the two UIs together.  The capitalized titles hurt my eyes.  They’re distracting and out of place. – Mike – 23 Feb 2012 10:26 AM

…While I do like introducing simplicity, I won’t be installing this if there is no option to replace these very low contrast lay-outs. And I’m pretty sure other people will don’t want to upgrade to this either, which will cost you some Metro developers in the long term… – Tom Wijsman – 23 Feb 2012 10:31 AM

Windows 3.1 is back? – Andrey – 23 Feb 2012 10:52 AM

The monochromatic color scheme is so bad it is distracting.  Instead of staying out of the way, my eyes are drawn to just how bad it really is…It is so bad and so distracting that a new word should be created to describe how bad and distracting it is…like baddistracting or bastracting.  The monochromatic scheme is bastracting and should be stopped. – jparramore – 23 Feb 2012 11:38 AM

Anyway, you get the point. There is a lot of negative reaction to the new UI. But is the new UI really that bad. Is it possible that it is actually a significant improvement, and we, the develoeprs who use and love Visual Studio, are just not ready to accept change?

A Bit on Metro

The Metro design echoes the visual language of an airport or metro system signage in both its design and typeface. The goal of the Metro design style is to create contextual relevance through content – primarily icons. Icons should be clear and understandable, and leverage real-world metaphors that are familiar to users. They should have simple geometry and limit the amount of fine detail.

Simplicity is the key. Every icon should be as simple as it can be (and no simpler). The primary purpose of the action the icon enables should be clearly and cleanly represented by the icon.

420.xamlLook all around your life and you will find these icons. They are not only on airport and metro signs, they are on your electronics, your clothing tags, and the dashboard of your car. You are so used to seeing Metro style icons, that you have developed an ability to quickly understand instructions and information based on a simple icon.

Metro style’s main goal is to make understanding information and instructions at a glance easy. The challenge is always balancing what you need to know with how much you can consume. For example, look at the laundering instructions on a piece of clothing. There could be 5 or 6 icons there, some of which you may not understand. That is likely because they are not within your domain, or context. I guarantee you that anyone working in a dry cleaning facility understands them all at a glance.

A Good Metro Implementation Focuses on Content

I think of the dashboard of my car, an Audi A6, as a great Metro style implementation. It provides me easy access to the information that I need in context, and easy way to switch context (e.g. between audio entertainment and navigation), and draws my focus and attention to the content that matters (speed, RPMs).


Most command buttons have an easy to understand icon (seat heaters, parking brake, fans, etc.). Some things use text (On/Off, Nav, CD/Aux, etc.) instead of icons. In either case it is easy to quickly infer the meaning and intent of the button. All of the command buttons and interfaces are the same color – white icons and text (redish backlight if its dark) on a black button. Essentially a monochromatic UI that makes finding and using the commands easy, but focuses my attention on the important stuff – warnings and content.

    • Warning information is indicated with a different color than the rest of the UI. For example the “Passenger Air Bag Off” warning and the check engine icon are both yellow.
    • Content that requires my focus and attention is white, such as the speedometer and tachometer, and the navigation screen (which includes a small set of other colors to indicate route, landmarks and warnings).

I can’t imaging how distracting it would be to drive my car if every icon and button were a colorized button. It would make finding and focusing on the important content much more difficult. As it is, I know to focus on the white content, and pay extra attention to any yellow content.
The new Visual Studio UI is attempting to do exactly what my Audi dashboard does. Make it easy for you to find information and commands, but draw your focus and attention to the content that matters most (aka your code).

Resisting Change

The fact of human psychology is that we tend to resist change before we embrace it. This seems to be the tone of many of the comments on Monty’s blog post. Many people are likely going through the stages of grief – Shock, Denial, Anger, Bargaining, Depression, Acceptance.

    Many people seems to be in the first four or five stages.

Shocked by the change.

WO WO WO. Let’s get one thing straight. There had better be a GIANT button in there to “MAKE IT LOOK LIKE IT USE TO.” – Don’t “Windows 8” me! – 27 Feb 2012 3:07 AM

Denying the change.

Why not keep the current GUI? it seems that your vs11 will be the worst design ever… please, see all these post, reconsider your transition… – ammin – 26 Feb 2012 5:15 AM

Anger toward Microsoft for the change.

I assume these god damn awful UI changes are meant to hide the lack of real changes over VS2010? – Steve – 27 Feb 2012 10:56 AM

Bargaining with Microsoft regarding the change.

Folks, we need to organize & mobilize to fight this: talk to your co-workers, give them link to this page, ask them to comment here. – Dee – 25 Feb 2012 9:32 AM

Depressed about the change.

Don’t care.  It is what it is and nothing anyone says here can change that. – Not Anal – 27 Feb 2012 12:12 AM

Its not clear to me that the mass of Visual Studio developers will reach acceptance of the new UI, nor is it clear to me if the bargaining will result in change. I like to believe that both will happen.

The Path Ahead

My opinion is that this is a step in the right direction. Of course, its near impossible to actually tell if its an improvement with out extended usage of the new UI, to see if it improves my productivity or not. This means that for many people there is likely a step of “testing” that must occur prior to acceptance. The testing may be challenging at first because we have to unlearn a few old things in order to learn some new things. Like the Audi dashboard example above, this happens almost anytime you buy a new car as well. Basically things work the same – there is a speedometer and tachometer, although they may be in reverse positions from what you are used to; there is a console for controlling audio, heat and AC and possibly navigation; and there are warning indicators, but possibly different ones, or they are in different positions. Testing the change requires a little patience in order to fully determine if the change is manageable – that is to say, you may not be able to affect the change, but you can determine your acceptance of the change.I encourage everyone to withhold judgment until you’ve had a chance to try the new Visual Studio UI. Once you’ve given it a fair chance, provide actionable feedback to the team via Monty’s blog (e.g. “There had better be a GIANT button in there to “MAKE IT LOOK LIKE IT USE TO.” isn’t really actionable).

As someone who leads product development, I can tell you that there is nothing more important than hearing from customers. It is the challenge of the product development team to determine actionable, real feedback from shock, denial, anger and depression driven feedback. A good product development team will be innovative and creative, and it may not immediately resonate with the customer, but if they’ve done their job right, the customer will accept and embrace the change in the long run, and have a better product experience as a result.

My favorite Henry Ford quote:

If I asked my customers what they want, they simply would have said a faster horse.

Henry Ford went on to introduce a radical change and innovation, that was met with both immediate acceptance and criticism. Can you imagine if that change had not been widely accepted?

Language Choice in Windows 8 is Not About Portability

Every time I go to talk to folks about Windows 8, the same questions pop up. I blame this largely on Microsoft’s silence about Windows 8 following the release of a tidal wave of information followed by the Windows 8 Developer Preview at Build in September. C’est la vie. This too shall pass.

One of the topics of conversation that comes up repeatedly is how to choose between using HTML5 + JavaScript or XAML + C#/VB (aka .NET) to build Metro style applications. What are the factors that you should consider before making your choice? Is HTML5 better? Is there a future for XAML? How do you choose?

Inevitably someone in the conversation cites the portability of HTML5 and JavaScript as the answer. It goes something like this…

“You should use HTML5 and JavaScript for Metro style applications because its portable and XAML isn’t. If you build with HTML5 then you can use the same code for your website or other platforms because its standards-based….HTML and JavaScript.”

This couldn’t be further from the truth. The use of HTML5 + JavaScript in Windows 8 is about as proprietary as using XAML + .NET. Consider the “Hello World” of the modern era – an RSS feed reader.

If you are going to build a feed reader into your Metro style application using HTML5 and JavaScript, it would look something like this:


<!DOCTYPE html>
<meta charset="utf-8" />
<!-- WinJS references -->
<link rel="stylesheet" href="/winjs/css/ui-light.css" />
<script src="/winjs/js/base.js"></script>
<script src="/winjs/js/ui.js"></script>
<script src="/winjs/js/binding.js"></script>
<script src="/winjs/js/controls.js"></script>
<script src="/winjs/js/animations.js"></script>
<script src="/winjs/js/uicollections.js"></script>
<script src="/winjs/js/wwaapp.js"></script>
<!-- RssReader references -->
<link rel="stylesheet" href="/css/default.css" />
<script src="/js/default.js"></script>
  <h1>RSS Reader</h1>
  <div id="downloadStatus"></div>
  <div id="template" data-win-control="WinJS.Binding.Template">
    <div class="postTitle" data-win-bind="innerText: title"></div>
    <div class="postDate" data-win-bind="innerText: date"></div>
  <div id="posts" data-win-control="WinJS.UI.ListView"
    data-win-options="{itemRenderer: template,
                       layout: {type: WinJS.UI.ListLayout},
                       selectionMode: 'single',
                       onselectionchanged: selectionChanged}">
  <div id="contentTemplate" data-win-control="WinJS.Binding.Template">
    <div class="postTitle" data-win-bind="innerText: title"></div>
    <div class="postDate" data-win-bind="innerText: date"></div>
    <div class="postContent" data-win-bind="innerHTML: content"></div>
  <div id="content"></div>


(function () {
  'use strict';
  WinJS.Application.onmainwindowactivated = function (e) {
    if (e.detail.kind === Windows.ApplicationModel.Activation.ActivationKind.launch){
      downloadStatus.innerText = "Downloading posts...";

      var syn = new Windows.Web.Syndication.SyndicationClient();
      var url = new Windows.Foundation.Uri("");
      syn.retrieveFeedAsync(url).then(processPosts, downloadError);

      // Define an event listener for the onselectionchanged event.
      posts.addEventListener("selectionchanged", selectionChanged);
      // Process the declarative controls

  function selectionChanged(e) {
    content.innerHTML = "";
    var selection = posts.winControl.selection;

    if (selection.length) {
      var post = postItems[selection[0].begin];
      var contentTemplate = WinJS.UI.getControl(

      contentTemplate.render(post).then(function (element) {

  var postItems = [];
  function processPosts(feed) {
    // Clear the process indicator
    downloadStatus.innerText = "";
    // Iterate over the items
    for (var i = 0, len = feed.items.length; i < len; i++) {
      var item = feed.items[i];
      var post = {
        title: item.title.text,
        date: item.publishedDate,
        content: item.summary.text,


    // Populate the ListView control's data source
    posts.winControl.dataSource = postItems;

  function downloadError() {
    downloadStatus.innerText = "Error loading posts.";


The Results

The resulting application creates a simple two column RSS feed reader, with post titles on the left, and post content on the right (in HTML):


Now imagine you wanted to use the same code to make your RSS feed reader website. Immediately you have to cut out all references to the WinJS JavaScript files, since WinJS is a JavaScript wrapper around key WinRT functions.

<!-- WinJS references –>
<script src="/winjs/js/base.js"></script>
<script src="/winjs/js/ui.js"></script>
<script src="/winjs/js/binding.js"></script>
<script src="/winjs/js/controls.js"></script>
<script src="/winjs/js/animations.js"></script>
<script src="/winjs/js/uicollections.js"></script>
<script src="/winjs/js/wwaapp.js"></script>

For example, the Metro style RSS feed reader application uses WinJS to manage a lot of the UI look and feel, data binding and how you interact with the application, including controls, animations, etc. All of that functionality will have to be rewritten in non WinJS format.

You are forced to rewrite key functionality, such as the feed syndication capabilities written in JavaScript which leverage Windows.Web.Syndication.SyndicationClient – a WinRT class that manages the network interaction between the client and the feed provider, including the asynchronous calls to get the RSS data and parse and format it correctly.

var syn = new Windows.Web.Syndication.SyndicationClient();
var url = new Windows.Foundation.Uri("");
syn.retrieveFeedAsync(url).then(processPosts, downloadError);

You have to rewrite the data binding of the feed items to the HTML layout.

// Populate the ListView control's data source
posts.winControl.dataSource = postItems;

// Process the declarative controls

<div id="template" data-win-control="WinJS.Binding.Template">
  <div class="postTitle" data-win-bind="innerText: title"></div>
  <div class="postDate" data-win-bind="innerText: date"></div>
<div id="posts"
  data-win-options="{itemRenderer: template,
                     layout: {type: WinJS.UI.ListLayout},
                     selectionMode: 'single',
                     onselectionchanged: selectionChanged}">
<div id="contentTemplate" data-win-control="WinJS.Binding.Template">
  <div class="postTitle" data-win-bind="innerText: title"></div>
  <div class="postDate" data-win-bind="innerText: date"></div>
  <div class="postContent" data-win-bind="innerHTML: content"></div>

That doesn’t feel very portable.

The conclusion is that your language choice when building a Windows 8 Metro style application has next-to-nothing to do with portability.

Before you get on your soap box, yes you can reuse some of the assets from the application. For example, the CSS is reusable between Windows 8 and the web. Some of the JavaScript is likely reusable, if it isn’t tightly coupled to WinJS or WinRT. But that’s it. Most of what makes the app work is dependent on WinRT, so its not portable – WinRT only runs on Windows 8.

Get Comfortable

So what should your language selection be based on? Comfort.

Microsoft architected an application development stack that does what Microsoft does best – provides flexibility and gives YOU choice. If you want to build an application for Microsoft’s upcoming platform, you can choose the language that you are most comfortable with. Microsoft isn’t making you learn an entirely new stack – just learn the new bits – and use the skills you already have.

Choose XAML

If you are a .NET developer currently working in WPF or Silverlight, then XAML+.NET will be right up your alley. Sure you will have to learn WinRT and some new syntax, but most of what you need to know you already do.

Choose HTML

If you are a web-standards developer, familiar with HTML and JavaScript, then use those skills. Use HTML5, JavaScript and learn WinJS and WinRT.

Either way Microsoft has made developing for Windows 8 very approachable. Make your language selection based on your skillset and what is comfortable for you. Don’t feel like you have to lean a new language. Use what you know.


A bad picture is worth a thousand long discussions.

While here at Build I’ve been in lots of conversations with customers, other attendees, Microsoft MVP’s, Microsoft Regional Directors, and Microsoft engineering team members. One of the recurring topics that I’ve been talking about ad nausium is the “boxology” diagram of the Windows 8 Platform and Tools (shown here).

Now let me tell you, I have drawn a lot of these “marketecture” diagrams in my time and its not easy. These kind of diagrams are never technically accurate. There is simply no easily digestible way to make a technically accurate diagram for a complex system that renders well on a slide and is easy to present and explain. The end result is that you create a diagram that is missing a lot of boxes – missing a lot of the actual technology that is present in the system. Unfortunately that is exactly what has happened here – the Windows 8 boxology is missing some of the actual technology that is present.

One of the conversations that has come up is around the missing box in the “green side” (aka Metro style apps) for the .NET Framework and the CLR. Do VB and C# in Metro style apps compile and run directly against the WinRT? Is this the end of the .NET Framework?

Others who have done some digging into the bits are wondering if there are two CLRs. What the heck is going on in Windows 8?

I spent some time with key members of the .NET CLR team last night (no names, but trust me when I say, these guys know exactly how the system works), and here’s the skinny.

Basic Facts:

  • There is only one CLR. Each application or application pool (depending on the app type) spins up a process and the CLR is used within that process. Meaning, a Metro style app and a Desktop Mode app running at the same time are using the same CLR bits, but separate instances of the CLR.
  • The .NET Framework 4.5 is used in both Desktop Mode apps and in Metro style apps. There is a difference though. Metro style apps use what is best described as a different .NET Profile (e.g. Desktop apps use the .NET Client Profile and Metro style apps use the .NET Metro Profile). There is NOT actually a different profile, but the implementation of .NET in Metro style apps is LIKE a different profile. Don’t go looking for this profile – its basically rules built into the .NET Framework and CLR that define what parts of the framework are available.
  • Whether a Desktop Mode app or a Metro style app, if it is a .NET app, it is compiled to the same MSIL. There isn’t a special Windows 8 Metro IL – there is, like the CLR, only one MSIL.

A More Accurate Picture

A more correct (but still marketecture that is not wholly technically accurate) would look like this:

In this diagram you can see that the CLR and the .NET Framework 4.5 are used for C# and Visual Basic apps in either Desktop Mode apps (blue side) or Metro style apps (green side). Silverlight is still only available in Desktop Mode as a plug-in to Internet Explorer (yes, out of browser is still supported in Desktop Mode). Another addition in this diagram is DirectX, which was strangely absent from the original diagram. DirectX is the defacto technology for high-polygon count applications, such as immersive games. DirectX leverages the power of C++ and can access the GPU.

This biggest confusion, as I mentioned, has been around the use of the .NET Framework across the blue side and green side. The reason for the, as I call it, .NET Metro Profile is because the Metro style apps run in an app container that limits what the application can have access to in order to protect the end user from potentially malicious apps. As such, the Metro Profile is a subset of the .NET Client Profile and simply takes away some of the capabilities that aren’t allowed by the app container for Metro style apps. Developers used to .NET will find accessing the WinRT APIs very intuitive – it works similarly to having an assembly reference and accessing the members of said referenced assembly.

Additionally, some of the changes in the Metro Profile are to ensure Metro style apps are constructed in the preferred way for touch-first design and portable form factors. An example is File.Create(). Historically if you were using .NET to create a new file you would use File.Create(string fileLocation) to create the new file on the disk, then access a stream reader to create the contents of the file as a string. This is a synchronous operation – you make the call and the process stalls while you wait for the return. The idea of modern, Metro style apps is that ansychronous programming practices should be used to cut down on things like IO latency, such as that created by file system operations. What this means is that the .NET Metro Profile doesn’t provide access to FileCreate() as a synchronous operation. Instead, you can still call File.Create() (or File.CreateNew()…I can’t recall right now) as an asynchronous operation. Once the callback is made you can still open a stream reader and work with the file contents as a string, just like you would have.

Ultimately all of this means that you have some choice, but you don’t have to sacrifice much if anything along the way. You can still build .NET and Silverlight apps the way you are used to, and they will run on Windows for years to come. If you want to build a new Metro style app, you have four options to choose from:

  1. XAML and .NET (C# or VB)You don’t have to giving up too much in the .NET Framework (remember, you only give up what is forbidden by the Application Container), and you get access to WinRT APIs for sensor input and other system resources.
  2. XAML and C++You can use your skills in XAML and C++ in order to leverage (or even extend) WinRT. Of course you don’t get the benefit of the .NET Framework, but hey….some people like managing their own garbage collection.
  3. HTML and JavaScriptYou can leverage the skills you have in UI layout, and make calls from JavaScript to WinRT for access to system resources, and sensor input.
  4. DirectX and C++If you’re building an immersive game you can use DirectX and access the device sensors and system resources through C++ and WinRT.

Hopefully this adds some clarity to the otherwise only slightly murky picture that is the Windows 8 boxology.

Don’t forget to check out


Build: Day 0

Here I am at the Starbucks in the Marriott Anaheim, which is connected to the Convention Center where Build will take place beginning tomorrow. Already people are milling about and I’ve seen a few friends and former colleagues (in fact, Dave Mendlen, my old boss, and the new CMO for DevExpress, gave me a ride from the airport). There’s a bit of buzz in the air, but also still a lot of uncertainty.

With all of the leaks there have been, it seems the more connected people have an idea of what will be said tomorrow, although they are still unsure what it will really mean. It seems the confidence in Microsoft will not come from them getting into the touch-centric user experience model, nor from a light weight, long-battery life tablet/slate form factor (such as implied by the Windows 8 on ARM announcements at the last CES). The confidence will come from implementation. How well can Microsoft enter this space, or how badly can they mess it up. Those seem to be the two camps.

A lot of folks I have spoken with don’t think Microsoft has the ingenuity to get into this game the right way. Perhaps its from years of tablet devices that were merely laptop PCs that could be used with a stylus. On the goos side for Microsoft, that means the bar is relatively low – simply don’t screw up and whatever else you do will be acceptable.

On the other hand, I know a number of people who believe Microsoft is going to do what Microsoft historically has been good at – enter late and envelop the market. We’ve seen this with the OS wars of the early to mid 90’s, the browser wars of the late 90’s and even the game console market in the 00’s. Unfortunately we have yet to see this with the smartphone market, where Microsoft is still effectively in last place.

Personally I am a believer. I think we will see and hear things tomorrow that will wow us, make us curious, and inspire us to learn a new way of programming for the Microsoft stack. I am not without concern, however. There are plenty of ways Microsoft can mess this up, but I don’t think they will. I believe that Sinofsky and the Windows team have been working diligently to make a compelling experience for Windows developers, such that it may even do what they want mosts, and attract non-Windows developers to the platform. I also think the Developer Division has been working hard to create a compelling tooling environment for the platform. I think most people will be happy with what they see….it just may take a few days.

Telerik is here at Build, but we are here mostly as attendees. We are hear to hear from Microsoft and learn from Microsoft. Our goal is to provide great additions to the Microsoft development tools, through UI controls, additional productivity tools, and whatever else may be appropriate. Of course we could come to Build and totally blend in, so if you are here, look for us and ask for a t-shirt. In fact, Tuesday morning, look for me driving the .NET Ninja Mobile (a Lamborghini with the Telerik logo) and take and post a picture of yourself with me and I’ll give you a t-shirt and a coveted pass to the GeekFest party on Thursday. If you need a ride to the conference Tuesday morning, send me a direct message on Twitter (@dseven) and I’ll come pick you up and drop you off in style.


Goodbye Microsoft. Hello Telerik.

If you keep up with me on Twitter you know that last Friday was my last day at Microsoft. I joinned Microsoft as a vendor in 2004 after I sold my company ( – I was hired in to fix a broken community program that dotnetjunkies had been part of, and a few months later accepted a full-time position to implement the supporting infrastructure. It was my second tour of duty (my first was in 1999-2000, where I met my dotnetjunkies partner). Over the past seven years I was fotunate enough to have some great experiences running a development team, and owning the product management of one of the most successful and widely used IDEs on the planet, Visual Studio. Itwas a good run, but it was time for a change.

Today was my first day as an empployee of Telerik – whom I believe to be a fantastic company that is doing some very innovative work, and working in a very agile way. While today was uneventful (travel day from Seattle to Boston for my onboarding and a management summit), it was a good day. I spent a lot of time thinking about what is to come. About the excitement the coming months and years will bring. I thrive in fast moving, agile, start-up style environments and expect that the culture at Telerik will suit me well.

There is of course an immense pressure that I feel as well – I supose anyone transitioning jobs, especially after seven years, is likely to feel a sense of pressure to prove themself quickly. My hope is to balance that pressure with the common sense to not try too hard too soon. A friend of mine gave me a book a while back – The First 90 Days: Critical Success Strategies for New Leaders at All Levels by Michael Watkins. This is a great (and short) read for anyone moving into a new leadership postition either in a new company, or a company you already work at. The cornerstone is to understand why you were brought in, and implement a matching strategy for the first pivitol 90-days. The wrong strategy, while successful in another situation, could spell dissaster. The right strategy – one that matches the purpose for you to move into the role – should yield good or better (potentially stellar) results.

As I embark on my first 90-days, I plan to share what I can. Telerik has a reputation for being very connected to the community, as I have been for over a decade. If you’re interested, then plan to hear from me regularly as I share the amazing work we are doing here at Telerik.


Visual Studio LightSwitch Feature Matrix

On his blog yesterday, Soma (Sr. VP of Developer Division at Microsoft), announced that Visual Studio LightSwitch Beta 2 will be coming soon. I can tell you, we are really excited about LightSwitch, and apparently you are too (you’ve downloaded over 100,000 copies of Beta 1).

One question that comes up a lot is, what can LightSwitch do versus what can Visual Studio Professional do? What’s the difference? Well, the difference is pretty clear.

Visual Studio LightSwitch is a specialist tool for building line-of-business applications for the desktop and cloud, while Visual Studio Professional is a generalist tool for building anything you can imaging for Microsoft platforms.

Take a look at this feature matrix and you’ll see what I mean (we’ll get a formal version of this up on soon).

Visual Studio LightSwitch

Visual Studio Professional

LightSwitch Runtime



Visual Studio Project System






Team Explorer (Team Foundation Server integration)

2, 3



Predefined Screen Templates



Application Skinning and Theming



Data Entity Designer



Business-oriented Data Types (e.g. EmailAddress, PhoneNumber, etc.)



Automatic Data Input Validation



Windows Azure Deployment



SQL Azure Support



Visual Basic



Visual C#



Visual C++


Visual F#




Silverlight/XAML Editor


LightSwitch Application









Console Application


Database Projects


Office Applications & Add-ins


Setup Projects


SharePoint Applications & WebParts


Test Projects


Visual Studio Add-ins


Windows Forms


Windows Phone






XNA Games


1 Only available for LightSwitch applications. Requires Visual Studio LightSwitch and Visual Studio Professional to both be installed.
2 Team Explorer will integrate with LightSwitch but must be installed separately.
3 Requires a Team Foundation Server Client Access License (CAL).

I hope that helps!


Data Storage in Visual Studio LightSwitch

With the recent release of Visual Studio LightSwitch Beta 1 to MSDN Subscribers, I have gotten a few questions. As questions come in, I’ll do my best to answer them here. One of the first questions I got was about how LightSwitch applications manage and store data source connection information – aka connection strings.


Question: In a Visual Studio LightSwitch application, where is the connection string to the database being stored?

LightSwitch applications can work with several types of data, including “local” application data, external SQL Server or SQL Azure data (or any other database supported by the .NET Framework), SharePoint data, and other external data exposed through WCF RIA Services. If you choose to get data from an external source, the Attach Data Source Wizard shows you your options.

Choose DataSource

On the other hand, the “local” application data is a reference to a SQL Server Express database that is created if you choose the “Create new table” option as shown here.


This application data is defined and stored in a local SQL Server Express database. For example, in the Vision Clinic demo we have used, the first step was to create a new table to store Patient data. in fact, in the demo we are defining an entity model, and creating a Patients (plural) table in the local application database using SQL Server Express. Notice in the following image that in the Solution Explorer there is a Data Sources node containing an ApplicationData node containing a Patients node. Patients is the table that was created in the ApplicationData database.



The ApplicationData.mdf file is a SQL Server Express file that is created and stored in the $ApplicationRoot\bin\Data directory. When connected to with Server Explorer, you can see that the Patients table is there, along with the ASP.NET membership tables.


So where is the connection string to this database stored? In a Web.config file that is created in the $ApplicationRoot\bin\release directory.

  <add name=”_IntrinsicData” connectionString=”
    Data Source=.\SQLEXPRESS;
   visual studio 2010\Projects\VisionClinicDemo\
    Integrated Security=True;Connect Timeout=30;
    User Instance=True;MultipleActiveResultSets=True” />

When the application is published (Build | Publish menu), the Publish Application Wizard asks if you want to publish the database directly to an existing database, or if you want to generate a script file to install and configure the database


If you choose to publish to a database, you are then prompted to provide the database information.


If you choose to create an install script file, you are prompted to describe the database that will be scripted.



All in all this is the standard approach to managing database connections in a multi-tiered application. The Web.config in the application tier contains the database connection information. As will all Web.config files, you may encrypt the connection information.


But what about the connections to other data sources, like SQL Azure or SharePoint?

A connection string is a connection string is a connection string. They all get stored in a the Web.config file.


<add name=”_IntrinsicData” connectionString=”Data Source=.\SQLEXPRESS;AttachDbFilename=’e:\my documents\visual studio 2010\Projects\VisionClinicDemo\
Integrated Security=True;Connect Timeout=30;User Instance=True;MultipleActiveResultSets=True” />

<add name=”PrescriptionContosoData” connectionString=”Data;Initial Catalog=PrescriptionContoso;User ID=[removed];Password=[removed]” />


Of course, all of the data in a LightSwitch application is represented by entities. The entities are defined in the ApplicationDefinition.lsml file (stored in $ApplicationRoot\Data). This is simply a reference to the data source(s) represented by the entities in the application. Each data source is described in this file, and the entities representing the data objects are described here as well.

<EntityContainerGroupProperty EntityContainer=”VisionClinicDemo:ApplicationData”
Name=”ApplicationData” />
<EntityContainerGroupProperty EntityContainer=”VisionClinicDemo:PrescriptionContosoData”
Name=”PrescriptionContosoData” />

<DataService DataProvider=”EntityFrameworkDataProvider”
EntityContainer=”:PrescriptionContosoData” Name=”PrescriptionContosoDataDataService”>
<ConnectionProperty Name=”DataProviderName” Value=”91510608-8809-4020-8897-fba057e22d54″ />
<ConnectionProperty Name=”DataSourceName” Value=”067ea0d9-ba62-43f7-9106-34930c60c528″ />
<ConnectionProperty Name=”ProviderInvariantName” Value=”System.Data.SqlClient” />
<ConnectionProperty Name=”SafeConnectionString” Value=”Data;Initial Catalog=PrescriptionContoso;User ID=admin01@server01″ />
<ConnectionProperty Name=”ConnectionStringGuid” Value=”1e9905dc-b519-4003-9387-1272a768b256″ />
<ConnectionProperty Name=”ProviderManifestToken” Value=”2008″ />




All in all, LightSwitch applications are built using standard best practices. In the case of connection strings, they are stored in Web.config files in the application tier, and have all the support of ASP.NET configuration files, including encryption.


Myth Busting Visual Studio LightSwitch

Earlier this week, at the VSLive conference in Redmond, WA (on the Microsoft campus) Jason Zander announced a new Visual Studio product that we’ve been working on – Visual Studio LightSwitch – the simplest way to build business applications for the desktop and cloud.

This is exciting for us – we’ve been working on this product in secret for some time now. Finally we are able to share this work with the world.

Of course, as can often happen, the announcement was followed up with some confusion. Since we aren’t releasing the Beta 1 bits until August 23, 2010, no one (other than the 700 people at VSLive using the hands-on-labs) can actually see LightSwitch in action and get a feel for it. As a result, there is some confusion around what LightSwitch is, what it does, and who should use it. So let me try and dispel a few myths.

Who is LightSwitch for? Who should use it?

LightSwitch is intended for anyone who needs to quickly and affordably create line-of-business applications. LightSwitch is also an ideal tool for professional developers who need to build great-looking custom applications and want to kick start the development with a business application based on the LightSwitch templates.

How is LightSwitch different than Microsoft Access?

Access provides the tools to build and maintain database applications. LightSwitch provides the tools and templates to develop line-of-business applications that can pull data from Access, SQL Server, SQL Azure, SharePoint and any data provided by a WCF RIA Service (Access is not a supported data source in Beta 1). LightSwitch applications can run on the desktop, a web server or in the cloud. As the needs and usage of the application grow, because LightSwitch applications run on the .NET Framework, and use the Visual Studio project system, they can be opened in Visual Studio 2010 Professional and higher, enabling more sophisticated customization of the application.

Can LightSwitch make LOB applications for Windows Phone 7?

LightSwitch is intended for building line-of-business applications that connect with existing applications, legacy systems, Web services, and the cloud. LightSwitch includes support for a variety of form factors, however; development for applications running on mobile devices is not supported at this time. LightSwitch supports publishing applications to the desktop, a web server, or the cloud (publish to cloud is not available in Beta 1).

Does LightSwitch use WPF for desktop applications, and Silverlight for Web applications?

LightSwitch currently creates Silverlight 4 applications. Since Silverlight 4 supports running out-of-browser, or in-browser, LightSwitch can easily generate the application form factor that you prefer.

How do I open a LightSwitch application in Visual Studio Pro?

There is no magic here. LightSwitch is a Visual Studio product. It uses the Visual Studio shell, and the Visual Studio project system. LightSwitch applications are Visual Studio applications. To open a LightSwitch application in Visual Studio 2010 Professional, simply open the .lsproj (LightSwitch Project) or .sln (Solution) file. Of course, you will need the LightSwitch runtime to support the application. If you have Visual Studio 2010 Professional (or higher) installed, simply install Visual Studio LightSwitch. The LightSwitch runtime and LightSwitch project templates will be installed and available through Visual Studio 2010.

When I define a new data source in LightSwitch, what is being created?

LightSwitch can work with several types of data sources, including Access (not available in Beta 1), SQL Server/Azure and SharePoint. If you decide to create a new data source (aka Application Data in LightSwitch lingo) you are defining a new SQL Server database. Under the covers LightSwitch uses SQL Server Express and creates a new ApplicationDatabase.mdf file for the new, local application data. You can also define new tables in other connected data sources (provided your credentials have the permissions to create tables). For example, you can connect to an existing SQL Server or SQL Azure data base, and choose the Add Table option to create a new table on your remote data source. If you don’t have the appropriate permissions, the Add Table option will not be available (as shown here).

How is LightSwitch different than WebMatrix?

WebMatrix is a tool that includes a Web server (IIS Developer Express), a database (SQL Server Compact), and programming framework (ASP.NET). WebMatrix makes it easier to create new websites from scratch, or use Microsoft’s Web Application Gallery to customize popular ASP.NET and PHP open source community applications. It is targeted at non-professional developers, primarily. Although WebMatrix seamlessly integrates with Visual Studio’s professional development tools, it’s not related to LightSwitch. In contrast, LightSwitch is targeted at professional developers looking to create custom LOB applications leveraging data from multiple sources that can be easily deployed to the desktop or cloud.

Does LightSwitch support version control?

Yes. LightSwitch comes with the Visual Studio Team Explorer installed making connecting to Team Foundation Server easy.

Does LightSwitch support custom controls?

Developers can create custom controls, themes and skins for LightSwitch applications. This is done in Visual Studio 2010 Professional and made available as a vsix installation (the Visual Studio Gallery is supported).

LightSwitch is great for developers (also overheard as ‘No it isn’t’)

Its important to understand the role LightSwitch will play in the world of a professional developer. If you are a Coder™ (make your living, or aspire to make your living writing code), LightSwitch may not be for you. Of course, you may use the LightSwitch runtime and project type inside Visual Studio 2010 Professional if you want to quickly build an LOB app or jump start some project development, but typically this isn’t you. The real user of LightSwitch is probably Code-Enabled™ (someone who has some basic coding skill – not like you – who will write or copy-and-paste code as needed to get what they need done). These are typically professionals in some industry who need apps for projects or specific needs, who you can’t be bothered with (think of the account manager who keeps asking you to build a tracking tool for them, and who you reject because you don’t have time). The reality is that there are a lot of Code-Enabled™ out there, and they will find a way to build what they need. The pain for you comes when their app “grows up” and you inherit it, are tasked with maintaining it, or worse yet, have to extend it. This is really when LightSwitch is good for developers. If the LOB app was built with LightSwitch, you are now inheriting a .NET based application, build on standard best practices (such as n-tier architecture with clear tier separation, data in SQL Server, proper data architecture, validation on the appropriate tiers, etc.). So while you may be thinking LightSwitch is not for you, it can still make your life better.

I promise more to come, including some demos. In the meantime, check out Jay Schmelzer’s The Anatomy of a LightSwitch Application Series.