There has been a recent influx of simplified integrated development environments in a number of environments. The goal of these IDEs is to make it possible for Line Of Business users (LOBs) to build data driven applications easily and simply. This is an admirable goal, but there are a few problems. For some reason, even though the problems recur again and again, the same mistakes are being made.
First is the assumption of the needs of the user. In a boxed IDE like Microsoft Access or the new LightSwitch, the user only has the tools that are given to them. The moment that the requirements change, a blackbox is introduced. Sure, you can build a custom control to show the flash ad in your advertising management application, but the moment that a code change needs to be made, when a flash version changes or whatnot, the dev can't be found, the control isn't in TFS, no-one knows how to fix it, what language it is in, or anything. The whole app goes down the tubes beause one custom component was lost.
Second is application lifecycle. Applications like LightSnack ... er ... LightBeer ... uh ... LightSwitch have a short shelf life. Need an example? Infopath. A number of companies bet the farm on Infopath. Where are those apps now? The bit bucket. Yes, I know InfoPath is still around, but it isn't an effective technology anymore. Do you really want to bank on the existence of LightSwitch in two years, much less twenty? I don't. Sure, you can 'graduate' the code base to Visual Studio, but how does that code look? How aboutwhen a VS upgrade comes around? Will it hold together then? And I am not picking on LioghtSwitch - Access has all the same problems. I recently spent weeks at the Ohio Department of Health upgrading an Access 2003 application to Access 2007 when 2010 was already out. Shelf life of a tightly integrated IDE has to be taken into account.
Third is the famous "Just because you can doesn't mean you should." You can't build EBay in WebMatrix (or even the Original Web Matrix), but it doesn't keep people from trying. Then when the business is depending on it, the failure becomes evident through a scale problem or a requirements or scope shift, and then the 'fix' becomes an emergency. This is just not a good idea, but it seems that no one will take a moment and consider the implications either when building the IDE or planning the applications.
Finally, this flies in the face of every architectural best practice out there. Here. Take my data and just write something in some generic tool to edit it. What? That's not how I want my organization to be run. You may not edit that data without using the controls provided, I am sorry. I don't want ot have to manage 100s of little applications, built on tens of little IDEs either. That's not how Enterprise Architecture is supposed to work. So you think enterprises won't try and use this? See point three above. If they can they will. (hat tip to @srkirkland)
Unlike a lot of developers, I don't have the 'I'm a professional developer and I write code so I think drag'n'drop tools suck." I am not like that. I am a pragmatic guy. I use simple tools for simple organizations' simple problems all the time. But I go in knowing that the solution has a limited lifespan. Honestly, the tools that are coming out today won't be used like that. They will be used like Infopath and Access, to write LOB applicaitons that will become essential, and then go stale and have to be rewritten in a hurry.
These kinds of IDEs lead to the kinds of practices that lead to failed IT strategies. Consider carefully before using them.