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.