Redmond Review

LightSwitch: The Answer to the Right Question

• By Andrew J. Brust
• 07/27/2011

After nearly a full year in beta, Visual Studio LightSwitch was released on July 26. And not a moment too soon: Microsoft needs an approachable line-of-business dev tool in its bag of tricks and customers need one to get their apps done. But many developers I'm friendly with are dismissive of LightSwitch. I've been trying to formulate an answer to their challenge. In thinking about it, I believe they may be asking the wrong question.

People in the dev world tend to split products up into framework-based tools that generate code, and elaborate development platforms where code is crafted. Framework-based tools provide efficiencies, but seem to do that at the cost of power and flexibility. Rich coding platforms eliminate limitations and, while they lack certain efficiencies, their power appears to make them more practical overall. Under this dichotomy, only the elaborate development platforms appear acceptable for real-world applications. So LightSwitch is dismissed.

But that's based on a false choice. People tend to fit things they haven't seen before into categories they already know. That's a reasonable thing to do, but sometimes a new template is required. I believe that's the case with LightSwitch.

Why It's Different
LightSwitch defies the frameworked versus crafted categorization scheme. It encourages declarative and schematic specification of an application, and yet it still accommodates imperative code. This isn't about painting controls on a form and then throwing in a bunch of load/save and validation code. Developers build data models inside LightSwitch, and define queries, validation and business rules as part of that model. Screens aren't designed in a WYSIWYG fashion, but instead are described, in terms of layout and data content. It's as if developers are editing markup, but in a UI rather than with angle brackets in a text editor.

Most tools automate at the expense of offering control. Somehow, LightSwitch provides for both. Sure, screens can be generated on the fly at runtime or statically at design time. But they can also be designed manually, or first generated and then heavily customized. A rich event model lets developers write lots of code, if that's truly needed. And because LightSwitch is part of Visual Studio and .NET, it permits development of conventional classes and can reference external assemblies in its projects. Support for six types of extensions, from screen templates up to full-on Silverlight controls, allows for a collaborative workflow between hardcore .NET developers and focused LightSwitch pros.

Perhaps most important, LightSwitch targets Windows Azure and SQL Azure -- and I dare say it does so better than anything else in the Microsoft stack. Come armed with the appropriate IDs and credentials, and LightSwitch can shift gears from desktop to cloud, simply by taking you through a different path in its publish wizard.

Honest Appraisal
LightSwitch isn't a code generator. It's not Access or SharePoint, and it's certainly not Excel. But LightSwitch can be used in place of those tools to create a bunch of applications that otherwise would live in Access databases, SharePoint lists or, even more likely, Excel spreadsheets. We're much better off letting LightSwitch implement those apps using responsible technologies like Silverlight, SQL Server, RIA Services, the Entity Framework, IIS and Windows Azure. Somehow, the LightSwitch team eliminated the stack's complexity without compromising its power. Yet another apparent tradeoff transcended.

There are many workers who are organized, logical thinkers, and in their work have well-defined routines and procedures that manage structured data. These routines and procedures constitute bona fide systems. Many of these systems may be maintained in spreadsheets, where they're essentially manual; the spreadsheet is not much different from a paper notebook when used in this manner.

In terms of justification, using LightSwitch to materialize these systems into real applications and databases is no different from developers organizing repetitive code into well-written functions and services. In both cases, refactoring occurs. In both cases, the outcome is positive. And while the personnel and skill sets may differ in each scenario, the validity of each is unified and unshakable. One team at Microsoft really gets that. I think the market should, as well.