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?
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:
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.
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:
- 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.
- 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.
- 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
- Visual Studio LightSwitch brings development to business managers (infoworld.com)
- Visual Studio suits up for business apps (go.theregister.com)
- Top Ten Questions and Answers on Data - Microsoft Answers them (msdn.microsoft.com)
- Without writing a single line of code (sempf.net)