Month: August 2010

Posted on

More thoughts on Microsoft Lightswitch

A couple weeks ago, Microsoft announced a tool called Lightswitch, and the response in the development community has been almost universally tepid.  One of these responses really caught my eye, though.  It was from Bill Vaughn, who's been the patron saint of Microsoft data access for as long as there's been Microsoft data access.  This guy knows a thing or two about what works, and he was dumping all over Lightswitch.

Construction in Gibraltar.
Image via Wikipedia

I left a comment on his post, and I thought it had been swallowed up by the great spam filter in the sky, but Bill just  resurrected it (thanks, Bill!) and responded.  It looks like the biggest fear with Lightswitch is that this tool is going to be used to create a bunch of garbage apps that "pros" have to come and clean up later.  This sentiment is echoed across many of the lukewarm comments I've seen elsewhere, too.

But even if all these bloggers are right about the quality of Lightswitch applications, I'm still not convinced that there isn't a place in Microsoft's developer tool portfolio for something like this.
Why?
  • We already have developers cranking out lousy prototypes, but with today's tools, they take longer.  In fact, they take long enough that an awful lot of developers look to platforms like Ruby-on-Rails to do prototyping, and that's not helping the MS developer tool position a whole lot.
  • If a tool like this were positioned specifically as a "non-production use" tool, you'd have at least a chance of setting proper expectations about would need to happen in order to scale apps up for production deployment.
  • There are very few shortcomings in Lightswitch that couldn't be substantially addressed via some sort of code generation.  A modern-day "upsizing wizard" could solidify a database schema, generate an Entity Framework model, even generate stored procedures if you want them.  The work I've done recently with the Code-First functionality in Entity Framework's recent CTP convinced me that the concrete constraints we're used to between DB and data access code might go away soon.  I've also seen some really great schema transformation capabilities in Visual Studio's Database Projects.  When this stuff comes together, I can absolutely envision a "pro" developer sitting down with a Lightswitch application and refactoring it into a high-quality application.

All good developers would rather see an application start out with a proper foundation and high-quality architecture.  We hate seeing messy apps, and we hate cleaning up after junior developers, or worse -- amateur developer wannabes.

But there's a business problem that we can't ignore: we're expensive - especially when we sit down to "do something right."  There is a need need for business owners and managers to produce prototype applications at a reasonable cost.  If Microsoft doesn't provide that capability, someone else will.  You may not like that, but it's a fact.

And here' s another fact:  If applications are being prototyped on someone else's application development stack, guess which stack is going to get first crack at upsizing those apps when they need to be scaled?

Lightswitch might not be the prototyping tool we'd all like to see in its current form, but don't let that distract you from the fact that Microsoft needs to be present in this part of the market.  It's important for them, and it's important for you, too.

Related articles by Zemanta
Enhanced by Zemanta
Posted on

A schizophrenic development platform

It's an occupational hazard, I guess.  The .Net development platform is moving at an absolutely dizzying pace these days, and there's no end in sight.  Ordinarily, you might think that this is great news for Microsoft's customers, because we're getting more innovation than we can swallow.  That's good, right?

Umm...

ADO.NET Entity Framework stack
Image via Wikipedia

Aside from the (somewhat) obvious problem that all the developers who work on this stack have to devote serious time to stay even close to current on this stuff, there's a whole other class of problem that's completely with Microsoft's control to manage, should anyone there choose to do so.  The problem is that Microsoft's Developer Division has a product management problem.  There's so much stuff coming out of this area that it's lost any sense of cohesive design.  Allow me to explore a couple of recent announcements:

Entity Framework CTP (Code First)

I've been playing with this for the last couple of weeks, and there's some very cool stuff in there.  This is stuff that's targeted for some future .Net release (hence, the CTP), but it builds on Entity Framework 4.0 classes - especially data annotation.

One of the things I've been struggling with in working with this tool is figuring out how validation is supposed to be done when you move beyond simple property annotations.  In addition to not finding any guidance about advanced validation, when I tried to use one of the more recent validation interfaces in an n-tier sample application, I found that it wasn't marked for serialization over WCF, which really slowed me down.  There are now at least two flavors of attribute-based validation (that I've seen), and object validation includes the IValidatableObject stuff and the Validation Enterprise Block in the Codeplex Enterprise Library.  Which one is the one validation to rule them all?

There's also a real sense of work-in-progress around the database generation stuff.  It feels like that capability is intended mainly as a prototyping capability , but the transition to a "real" project is very unclear at this point.  Again, tons and tons of potential, but it's not crystal clear what the positioning and role of this tech will be going forward.

Visual Studio Lightswitch

I read about this one today on Jason Zander's WebLog.  This looks like a next-generation Access-like tool.  The usage scenarios that are described for this tool are slanted distinctly toward hobbyist programmers, and there's undoubtedly a market there.  What is again not quite clear is where this tool is intended to fit in the Visual Studio lineup, and once again, what the "upscaling" path looks like.

In both of these cases, we're seeing some hints of really cool technology, but it's happening in a bit of a vacuum.  Either or both of these, for instance, could wind up usurping an existing VS technology, or living shoulder-to-shoulder with it, and either one could obviously end up withering on the vine, but am I the only one who feels like Microsoft is just throwing this stuff out there to see what sticks?

A technology that time forgot?

Do you remember Dynamic Data Entity Projects?  I wrote about my first impressions about Dynamic Data back in December of 2007, though these bits didn't reach release status until .Net 3.5 SP1 was released in November, 2008, and by most standards, this stuff didn't get usably stable until .Net 4.0 came out.  We're now less than two years removed from that original release, and it seems like the whole world has already moved on -- Dynamic Data is the next best thing to legacy code now.

Dynamic Data sites clearly seem to target prototype sites and/or hobbyists, but given that I don't hear "boo" about Dynamic Data any more, it would appear that Microsoft didn't really light those groups on fire.  Rather than evolving that platform to meet the needs of those customers, though, it looks like Microsoft's strategy is to throw some more bits out to see if anything else sticks any better.  It's clear that some of the ideas in Dynamic Data found their way into ASP.Net MVC, and then on to EF4 Code-First, and Lightswitch, too, but if we end up with three or four products out there that are jockeying for the same real estate, Microsoft's message is going to be lost.

Remeber the Kin

You could make the argument that Microsoft's mobile platform is the most important front that Microsoft is fighting today.  They're badly behind, and they really need s solid base hit to keep Microsoft in the mobile game.  Despite this, they gave us the Kin.  And then they took it away.  This wasn't the Developer Division, obviously, but it speaks to the same overall lack of strategic product line  management that's showing up in developer tools in a big way.

What customers need

Microsoft, if you're listening, here's what we, the decision-making developers and architects of the world, need from you:

  1. Publish a product roadmap.  Let us know how you see these new previews fitting into the Visual Studio line.  If they're intended to replace some existing technology, then say so.  If the technology is going to get folded into a future release, such that the "preview" project disappears altogether, then tell us that, too.  If you really don't know, then I guess I'd just as soon you tell us that, too, though I should warn you that printing "TBD" next to "Future Direction:" on all the lines of your spreadsheet won't do much to convince folks that there's someone steering the boat.
  2. Each of the new tools you introduce has limitations.  Please tell us where they are.  Product "X", for instance, might not do well in an n-tier deployment.  Product "Y" might have a hard time handling certain kinds of data relationships.  Whatever the case, we'd love to know about the limitations up front, rather than finding out after the fact that we've dug ourselves an architectural hole.
  3. Document how and when you expect development technology to die.  Most of the developers I know would agree that the world would be a better place without Datasets, yet they live on.  Despite the fact that Datasets are recognized as Model-T technology, there's no document from Microsoft that I can show a manager to explain that we're trying to get off these things because they've been around since men were drawing flow charts on cave walls, and that EF has now solidly replaced these as a mainstream technology.  Web Services were fantastic when that's all we had, but there are now all sorts of applications where WCF would be preferred -- can we get this sort of information in a *really* simple format?

If Microsoft were able to articulate direction on a couple of these items just a bit more clearly, I'd bet it would go a long way toward creating a big 'ol developer comfort zone.  In the mean time, I'm back to figuring out which validation interface I'm going to use.

Related articles by Zemanta

Enhanced by Zemanta