LightSwitch Arrives

| 2 Comments | No TrackBacks

Microsoft is gearing up to announce “LightSwitch”, it’s newest data application developer tool. Targeted to developers of “…all skill levels” it’s designed to permit access to local or remote data sources including SQL Server, Azure and SharePoint. I assume this means that amateur developers will have another tool to work with—assuming they can afford it and their IT organization will let them use it.

Frankly, I’ve known about this new offering for some time but until now, I was under NDA and could not reveal any of its details (or even the name). Now that it’s been released, I have a few choice words to add to the drumbeat…

I'm not that in tune with the amateur market except that it seems to me there are a number of well-entrenched players out there--many with free (or nearly so) tools so I'm puzzled why Microsoft seems to think it can come into the game this late and expect to make inroads.

I am familiar with the collateral damage caused by well-meaning amateur-wielded tools--including Access and Visual Studio (and even C#). Most database/system consultants have been asked to come into corporate environments to deal with security leaks, lost data, poor performance and chaotic development teams. We know that the world is full of lawyers, janitors, receptionists, desk clerks and database administrators that who are skilled at what they do but not so skilled at understanding how to build a secure, stable, scalable and shareable DBMS application--especially in a corporate environment. What we find is that all too often the root of the problem has been one or more "toy" applications written by these "paradevelopers" (to be kind)--applications that grew beyond the capacity of the application and the training/experience of the developer and the tools used to create them.

Yes, Visual Basic eliminated much of the behind-the-scenes work required to build a Windows application but it did not solve (or even address) the many of the concepts needed to build a serious data access application. Case in point: to this day, the drag-and-drop tools included with every version of Visual Studio don't ask for a WHERE clause when building a TableAdapter. In addition there are no tools in Visual Studio to manage rights, backup and a myriad of other data access issues that need to be dealt with to build a successful application. Building an easy-to-use tool does not make an amateur more skilled at making applications and more than a $900 table saw makes a plumber better at making cabinets.

The issues faced by IT organizations were exacerbated by "viral" infestations of these toy applications that spread from one desktop and department to another. In some cases we found these applications (often Access/JET based) were called upon to handle client-sensitive information, patient information, credit card numbers and private Veteran records. With stiffer laws, IT organizations were desperate to (forced to) regain control over their data. A regional hospital reported that they had over 12,000 copies of an unsecured JET application that stored confidential patient data spread all over the state. My fear is that LightSwitch will just add to the leaks and IT workload as corporations try to rein-in these applications.

For decades, professionals have been encouraging IT organizations to lock down the databases to prevent unauthorized access, control scalability and protect the data. To do this we encourage IT organizations to erect security barriers to prevent direct table access, implement limited-rights Views and stored procedures and more recently, add object layers to protect the data. Any application that expects to work with any corporate database beyond the church choir roster had better be designed to work with these realities.

Another problem IT organizations face is that Access applications (and to a lesser extent JET-based Visual Studio apps) cannot be magically transmogrified to work with their secure DBMSs. While the Access or JET apps might access mainstream DBMS systems like SQL Server using local (or User) instances, the approach generated with drag-and-drop code generators must usually be reengineered to work with the locked down corporate DBMS. More often than not, these applications use table-based routines that don't account for multi-user or complex data-integrity issues. Most can't be migrated without extensive re-engineering.

As I see it, Microsoft is proposing to introduce yet another set of compatibility and upsizing issues with LightSwitch. If I was a new developer that was looking for work in a large IT organization, I’m not sure I would list LightSwitch, Access or Erector Set in my list of development tools.



No TrackBacks

TrackBack URL:


Bill -

It's great to hear your thoughts on this. My thoughts on Lightswitch were slightly more charitable, but touched on some of the same ideas.

I think it's helpful to step back a few thousand feet and look at the cycle of complexity that languages and platforms keep going through. I can't think of a single development platform that hasn't eventually grown so complex that it was supplanted by a simpler option.

Look at Visual Basic: VB made its mark in the world by simplifying Windows development to the point where it opened Windows development to a whole new population of developers. I don't think it's possible to overstate how important that was to Microsoft at that time. It fueled the upward spiral of Windows by attracting Windows developers (remember Ballmer's "Developers! Developers! Developers!"?)

I really think this is the sort of dynamic Microsoft is trying to recapture, and I guess it's not surprising to me that they're trying to capture (re-capture?) that market. The $64K question is whether something like Lightswitch will help them do it.

One of the areas where I see a bit of promise for Lightswitch is that it's possible that this could be a great way to ramp up new applications, provided that there's an actual transition path to let the apps "grow up". I mentioned in my post that I'd like to see Microsoft wrap a little bit more product management around tools like Lightswitch to help people match the right tools for a given business problem.

Although I share some of your skepticism, I think I'm going to wait to write off Lightswitch entirely until I see how the market reacts.

(fyi, here are a few more thoughts on why VB was successful)

Sorry I didn't see that this comment was blocked. I understand Microsoft's motivation (as least as it has been expressed to me on any number of occasions over the years) but personally I don't think it required creation of another entirely new development tool to do it. My biggest concern is using LightSwitch for prototyping. While this was a problem for the early versions of VB, the applications (especially in later versions) were scalable given that the developer took a moderate amount of care. I don't see that with Lightswitch. I depends on a shaky foundation of direct table access and... well, my uncharitable remarks are already posted...


Powered by Movable Type 4.21-en

About this Entry

This page contains a single entry by William Vaughn published on August 4, 2010 10:52 AM.

RSScripter and Permissions was the previous entry in this blog.

LightSwitch—the Discussion Continues is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.