Friday, November 11, 2011

Build business apps in .NET - not HTML & JavaScript

A lot of people are freaking out about the apparent decline of .NET client technologies such as WPF and Silverlight. I’m one of those people. How can one, in good conscience, advocate new development in WPF or Silverlight (or Windows Forms)?

Well I can advocate it, I do advocate it, and I’m sleeping well at night.

A recent comment to one of my post on WinRT provoked an outsized reaction that has become this post. Here’s that comment:

Given that most people who are skilled in HTML5+JS write applications that are cross-browser and cross-OS every day; why would they ever consider writing for a single OS?

This fellow managed to capture in a few words the current mood and madness. My rant follows:

Who are you kidding?

First, hardly anyone is skilled in HTML 5. Period. That’s just wrong on the facts.

Secondly, most people “who are skilled in HTML + JavaScript” – cross-browser or otherwise - do not have a clue how to write a business application in JavaScript.

Most people who write apps that emit HTML do not write much JavaScript; they exploit controls that rely on JavaScript and they may write a little decorative JavaScript but that's the extent of their experience.

How do I know that? I've been hanging out where the experts in JavaScript hang ... and the recurring verities are (a) most people write horrible JavaScript (hence the need for Crockford's "JavaScript - The Good Parts"), the apps are almost unmaintainable when they do, and (c) the appropriate design and implementation patterns for JavaScript are in flux.

This is a fascinating and creative time in the evolution of JavaScript programming. New frameworks are popping up left and right. Lots of lectures and discussions about how to do it right. That's all healthy.

But the sheer wildness and variety of competing and overlapping toolkits/frameworks/guidance reveals the immaturity of the JavaScript environment as a business application development platform.

Get real about business application development

Let me be crystal clear about what I mean when I talk about a "business application" … because I want to confine my remarks to just this one kind of app. I take a completely different position on the appropriate development and delivery platform for other kinds of applications. This post is about business applications only.

[Warning: I will delete every comment that attempts to refute my argument by reference to any other kind of application. I will be especially dismissive of counter-claims which only make sense with regard to consumer facing, social networking, content broadcasting apps. You are simply not paying attention if you respond in that way and I will not waste my time or my reader(s) time with your inappropriate reply.]

Here is what I mean by a “business application”:

  1. It is a "sovereign app". That one app will dominate a user's attention for hours at a time, day after day.

  2. The user is paid to use the app. The person who pays him/her requires that user to get work done with the app as quickly and efficiently as possible.

  3. It is data-centric. The user consumes a large volume and variety of data. More importantly, the user routinely adds and updates that data in all of its variety.

  4. Therefore, the app must be highly responsive and immersive in order to maximize user productivity. It must present data and accept user input at top speed. Every moment spent waiting or wondering or searching around or flipping pages is wasted user time and wasted business owner money.

In my experience, the only apps that hit the required standard of user efficiency are apps that execute predominantly on the client. I don't care if its written in Windows Forms, WPF, Silverlight, Java, or in JavaScript ... it has to execute on the client and make only the minimally necessary trips to the server.

This is the context for answering your question. Why would I write for one OS?

If I'm writing a business app, in all likelihood there is only one OS that matters: Windows. Windows just happens to own 95% of my targeted user base (my estimate) ... today and for the near term.

[Note: The OS-on-a-PC figures are imperfect but the consensus is that Windows has no less than 88% share of all PCs which includes home PCs. Home PCs don’t matter for this analysis.]

Don't bother telling me about mobile. Don't bother giving me statistics on web traffic by OS (where Windows gets 86% of 2011 web traffic, btw). Don't tell me your vision for the future. This discussion is about business apps today and they run on PCs ... period.

If the time & cost of developing and maintaining business apps in HTML/JS were anywhere close to the marks of a .NET client platform I'd say "go HTML/JS".

But they aren't. Not close. Not soon to be close. And that fact is nowhere in dispute, not even among the most ardent HTML/JS fans.

So, as a business person, I've got a decision to make. The economics of today tell me "build it in .NET" because I can do it cheaply, effectively, with great quality using readily available resources, mature tools and experienced developers.

Of course, as a business man, I'll be concerned about the future and the long-term viability of my application. I’m perturbed that the app I am building today will be seen in 3 years as pinned to a legacy technology. That's a tough pill ... and it's why there is so much consternation. No one wants the “legacy” sign hanging around his neck.

But it’s not like everyone is going to forget how to write in .NET. Support won’t vanish. I will be able to find technology and people to keep the application alive in ten or fifteen years. I’ve got time to amortize my development costs and prepare for the inevitable transition(s) down the road.

The alternative - writing a business app in HTML/JS today – makes no economic sense. It doesn’t give me more reach because there are virtually no targeted users that I can’t reach today and for years to come. They are running Windows.

For sure the application will take 2 to 3 times as long to build in HTML/JS. I don’t have – nor can I find - the developers with the skills and experience for building an app like mine. The tools and frameworks they need don’t quite exist yet; the current prototypes are re-released with breaking changes every couple of months. My developers will be following half-baked implementation regimes, borrowed from other platforms (… oh, like .NET), that are as yet unproven for JavaScript business apps.

Yes … I could trust my critical business application development to HTML+JavaScript … if I’m a nutter.

Summary

Let me net it out for you:

  • A tiny % of today's developers are capable of writing an HTML/JS business application.

  • There are almost no examples of such apps today and almost no place to go to learn how to make them.

  • For most business apps there is only one OS that matter: Windows

  • The economics of developing a business app that runs on Windows are vastly superior to the economics of developing a business app in HTML/JS.

All that can change. All that will change. But not this year, not next year, and maybe not in 2013 either.

If you have the luxury of screwing around, have fun in HTML/JS. I know that I have that luxury and I am, indeed, having fun.

If you must write a business app for delivery in the next 12 months, do it in a .NET client technology.

Update 11/12

A discussion of this post has emerged on a G+ thread that you may find entertaining or even illuminating.

Thursday, November 3, 2011

DevForce Code First with AOP

We recently released DevForce 6.1.3 whose signature feature is Code First development of a distributed entity model, implemented with Aspect Oriented Programming (AOP). Let me unpack that for you.

Code First – You write the entity classes and only the entity classes. You don’t use a visual designer. You let the Entity Framework map your classes by convention to database objects and clarify in code those mappings that can’t be inferred.

Distributed Entity Model – “Distributed” is the key word: in a DevForce application, the client may have to rely on an intermediary server to reach the database. In DevForce, you program with a single set of entity classes, the classes you wrote, on both the server and client. DevForce handles the coordination and movement of data across tiers and over the network. The client could be Windows Forms, WPF, or Silverlight. The server could run as a Windows Service, in IIS, or in Azure. The network could be a LAN or the web.

Aspect Oriented Programming – Who needs change notification, property validation, change tracking, lazy loading, client-side caching? You do … if you want to query, save, and bind a WinForms or XAML UI directly to your interrelated collections of entities. That takes infrastructure (INotifyPropertyChanged, INotifyDataErrorInfo, etc) that you should not write yourself. Where is that infrastructure hiding when your source code only says: public string Name {get; set;}?  It’s inside your entity model assembly, after we rewrote it with PostSharp. The infrastructure you need is ready at runtime.

You can read all about DevForce Code First here. There’s a six part walkthrough of a WPF sample here. Right now, I want to talk about why I am personally jazzed about the DevForce Code First approach.

Why Code First?


DevForce has long been friendly to Entity Framework. Heretofore, we integrated closely with the Entity Data Model Designer in Visual Studio and relied upon the resultant EDMX file as the basis for generating entity classes with our own T4 template (which you can customize). That approach is still enormously popular and we remain enthusiastic about it.

But I am smitten by our new Code First option. I like Code First because I think it can reduce the friction of developing and maintaining my entity model. Let me show you a Product class I wrote in Code First:
[ProvideEntityAspect]
public class Product
{
    public int ProductId { get; set; }
    public string ProductName { get; set; }

    public int CategoryId { get; set; } // Foreign key for "Category"
    public Category Category { get; set; }

    public Guid SupplierKey { get; set; } // Foreign key for "Supplier"
    public Supplier Supplier { get; set; }
}

Product has six properties: the key (ProductId), a name, two foreign keys (CategoryId, SupplierId) and two “navigation properties” that return related parent entities (Category, Supplier). There’s no base class … unless I want one. The only evidence of infrastructure is that peculiar ProvideEntityAspect attribute … to which we will return.

This code is obvious and easy to write. The class conforms to Entity Framework naming conventions so there is no need for explicit mapping with attributes or the fluent API at this point. You’re welcome to add explicit mapping as you choose or need to do so. I didn’t need to … and I prefer to stick with the conventions.

I hammered out this class as it occurred to me. I didn’t fire up the EDM Designer in Visual Studio. I don’t have an EDMX file to manage. No partial classes separate the generated code from my custom entity business logic (of which there is none at the moment but it’s coming). There are no companion metadata classes for manipulating attributes of generated properties. There is no code generation for Silverlight clients as there is in RIA Services. The entity source code you see is the same source code living in all .NET server and client environments.

I can evolve this class as I go … with or without a pre-existing database. I can add validation attributes when and where I want them. Or I can add Product validation rules separately if I don’t want them buried in the entity. I can write DevForce property interceptors to inject behavior when a Product consumer gets or set any of these properties. What begins as little more than a property bag can grow to have as much (or as little) business logic as I think the entity requires … without touching the properties; they remain exactly as you see them.

I can write tests for my added business logic - including tests that exercise the navigations from Product to Category and Supplier – without ever contacting a server or a database.

I’m focused on the Product class and just what it needs to function properly in my business domain. The infrastructure is invisible … although accessible when I want it.

It’s not zero friction. But it’s as frictionless an approach to entity model development as I’ve seen. Which means I should be able to move my development forward faster, with higher quality, and a better chance of conveying my intentions clearly to the developer who picks up after I’ve left the project.

Beyond Entity Framework


At first blush, what I’ve described … the Product class I’ve shown … could come straight out of an Entity Framework tutorial. If you add .NET validation attributes to the properties, Entity Framework will perform object validation for you and reject attempts to save invalid entities. These DevForce entities actually are ready-to-go as Entity Framework entities. What value is DevForce adding that’s not already in Entity Framework?

DevForce brings two huge advantages:
  1. DevForce entities are queried and saved in n-tier deployments … such as Silverlight and cloud applications.
     
  2. DevForce entities are equipped to participate in Windows Forms, WPF, and Silverlight UIs.
Native Entity Framework is a strictly 2-tier technology. The client must have line-of-sight to the database. You can’t serialize and de-serialize entity graphs across the web. You can’t compose LINQ queries on a remote client. You can’t query asynchronously and manage exceptions remotely. You can’t prepare change-sets remotely and save them remotely. Such capabilities become possible only if you write a ton of difficult infrastructure … or use DevForce.

You are welcome to march into the wilderness on your own. Go write and maintain the myriad services that shuffle data into and out of DTOs (Data Transfer Objects). Try that on today’s line-of-business application with its hundreds of interrelated entities and see how much time you waste on those subterranean layers while the UI languishes and your customer taps his toes.

If you stay 2-tier and you’re pushing entity data into an ASP Web Form, the native Entity Framework entity may be good enough. Your UI controls can translate the validation attributes to JavaScript. You have little use for property change notification. You’re web server has line-of-sight to the database and can run EF on its full .NET stack.

That is not good enough for Windows Forms, or WPF, or Silverlight … the preferred client environments for line of business applications. These client technologies favor bi-directional data binding. Their controls listen for the PropertyChanged event to fire when something sets the property of a bound entity object. Many grid controls respond to hints they discover in attributes decorating the entity properties. Many controls can cancel and roll back user changes automatically if the entity supports IEditableObject. They can light up with validation error information when the entity supports IDataErrorInfo or INotifyDataErrorInfo.

Entity Validation in WPF

In this WPF sample screen shot, the “Supplier” text box is bound to the Product.Supplier.CompanyName property. DevForce navigates from the Product to the Supplier instance in cache. The user entered a value in mixed case (“All Fine Foods has a name that is far too long”). A “get-interceptor” converts the value to uppercase before returning it to the text box. The property validation mechanism immediately applies the property length validation rule and records the rule violation. The binding, which detects that Product implements IDataErrorInfo, displays the validation message.

Developers want their entities to provide this kind of support automatically. They don’t want to write it. They don’t want to see it. Developers are really tired of writing … or wading through … pages of property definitions such as

public string ProductName
{
    get { return _productName; } 
    set
    {
        if (_productName != value)
        {
            if (Validate(value))
            {
                _productName = value;
                RaisePropertyChanged("ProductName");
            }
        }
    }
}
private string _productName;

That’s all noise and no business value. It should be quieter and simpler:
public string ProductName { get; set; }

Let’s push it a bit farther and think about what must be going on inside a property that returns a related entity. Here is how you write the Product’s Category property in DevForce Code First:

public Category Category { get; set; }

It is as plain, expressive, and simple as ProductName. We have the same need for validation and notification. We have two additional requirements, neither of them met by Entity Framework: (a) we must have the machinery for retrieving, caching and saving the related Category entity on a remote client and (b) we must plug that machinery into the property’s get and set methods at runtime. 

The apparent innocence of the ProductName and Category properties is possible thanks to some nifty work behind the curtain.

Aspect Oriented Programming (AOP)


DevForce makes writing properties as simple as shown while endowing them with the capabilities necessary for participation in the .NET client UI technologies. Clearly the “property as shown” cannot be the actual implementation at runtime. Somehow the infrastructure code has to insinuate itself into the property.

DevForce uses PostSharp and Aspect Oriented Programming (AOP) to inject the infrastructure into your classes. It re-writes the compiled model assembly at build time. That ProvideEntityAspect attribute adorning the top of the Product class tells DevForce that Product is a kind of entity and should implement the behaviors that all entities exhibit. DevForce and PostSharp replace the get and set methods of entity properties with code that ties into DevForce infrastructure. The revised Product class inherits from and implements the interfaces that light up the UI controls. It also acquires support for querying, caching, change-tracking, and saving product data. The Product class, after re-write, is an enriched version of the original Product class you wrote. The Product objects that you “new” at runtime are instances of the enriched Product class. When a binding reflects into an instance of Product, it finds the interfaces it’s looking for.

Many frameworks, including Entity Framework and NHibernate, use an alternative approach called “dynamic proxies.” They leave the original compiled classes alone. Instead, they rely on an external component (e.g., a “Context” or “Session”) to encase new and queried entities in a wrapper class that derives from your entity class. This wrapper overrides your entity’s properties with implementations that delegate (“proxy”) to the framework’s infrastructure.

That infrastructure, if expanded appropriately, could do all of the interception, routing, and notification that DevForce does. You’d have to adapt your entity and workflow to play along. All of your entity properties would have to be virtual. You couldn’t construct them directly with “new”; in fact, you’d have to be careful always to reference the proxied object. You’d also have to get used to debugging with strange wrapper types, sporting bizarre long names.

We like the AOP approach better. We think most people will find it more natural to work with a class that is fully baked at build time rather than maneuver to consume proxies that are emitted dynamically at runtime.

Could this be magic?


I don’t trust all that magic!'” That’s a common early reaction to Code First, AOP (and dynamic proxies). When I rely on Entity Framework naming conventions to map class and property names to tables and columns, how do I know what it did or did not map? When AOP is injecting logic into my classes that I can’t see, how do I know what it is doing?

I push the button on my coffee maker and good, hot brown stuff pours into my cup. That’s magic to me. The compiler turns my auto-property into two get and set methods with a backing field. That’s magic. Then it becomes IL code which becomes machine code which makes the hardware jump. That’s magic.

The difference is that coding by convention and AOP are new magic for most of us. We’re used to the old magic. We probably never truly understood it; we just stopped worrying about it. Before, when the property code was visible and the entity-data map was in an EDMX file, we felt the visceral comfort of touching the code and displaying the XML if we wanted to. But we rarely wanted to. When we did look, we were as often confused by what we saw as not.

What matters most is good diagnostics and easy debugging. I need a clear explanation when things go wrong and I need to know what to do about it. Fortunately, the Entity Framework mapping error messages are pretty good. I think the AOP debugging experience will feel familiar to you. You breakpoint your custom code exactly as you did before. You step through your code as you did before. You test your code as you did before.

I am keen to know what you think after you’ve tried it. We’re eager to hear your suggestions. IdeaBlade issues DevForce updates every six-to-eight weeks so we can respond quickly.

What about existing databases?


I often hear that Code First is only for “greenfield” development and small database schemas. Perhaps half of our customers (re)build existing applications for existing databases with hundreds of tables some of which have hundreds of columns. Heaven help them.

Such “brownfield” development presents at least three challenges:
  1. Getting started … because no one wants to write all those entities by hand.
  2.  
  3. Evolving the entity model and a production database as requirements change.
  4.  
  5. Keeping the model and the database in sync without the assistance of the EDM Designer.
We meet the first challenge with an approach we call “Code Second”. Speaking schematically, you aim the EDM Designer at the database and generate DevForce “Code First” classes. Then you throw away the EDMX file and proceed in Code First style.

I’m optimistic but less confident in my response to the second and third challenges. I know developers in other communities (NHibernate in particular) have confronted these demons and wrestled them to the ground. They’ve survived without Database First tooling as far as I can tell. I’m betting they’ve discovered successful practices we can learn from and adapt.

Code First style entails evolving the model and existing database in small doses, supported by tests. Runtime mapping exceptions are sufficiently informative in the context of small changes; repairing small breaks should be easy. You shouldn’t wake up in shocked surprise one morning to find that the model or the database have been massively transformed. That’s a disaster for Database First as much as Code First; it indicates far more fundamental flaws in your development process.

A new module may require many new entity types to support its scenarios. The new entity types can be related to other types, new and existing. The new model ultimately translates to new tables and foreign key relationships to new and existing tables. I think I would develop a new module as I would a “greenfield” project with stubbed stand-ins for the existing entities and tables.

It may be wise to preserve this separate model and separate database … forever. But if that’s not in the cards, when the new project matures, I’d fold my Code First model into the existing model. I’d script database changes from the generated Code First design database and apply them to the existing database.

I readily admit that I do not have the concrete experience to back up these suggestions. I expect to have more to say on this subject in future posts. One of our customers hired us to help them rebuild their 500 table application in DevForce Code First. I promise to report back on do’s and don’ts.

What next?


I’d love to know what you think. Is Code First attractive to you? Do you have pros and cons to share? Would you explore our walkthrough and give me your feedback? Is there something that bothers you about what I’ve said? Anything you want me to expand upon?

I’m here for you.

Monday, October 10, 2011

Windows 8 Metro apps in JavaScript

I’m having a blast exploring Windows 8 Metro app development and poking around in the preview bits shipped at the 2011 BUILD conference.  Last weekend, I presented on Metro app development using JavaScript at the Silicon Valley Code Camp.

I’ve posted the sample code, my presentation script, and my slide deck on the IdeaBlade wiki.

I have not gone crazy and transferred my affections from .NET to JavaScript. I’m just curious about all the hub-bub. It’s also the only fair way to confront the assertions that JavaScript has grown up and that we’ll all soon be JavaScript programmers.

What is all this noise about “programming in standards-based HTML5 and JavaScript” … which is technically possible in Windows 8 … although in practice you’ll be so imbricated in Windows that you might as well have written it in COM.

I exaggerate … slightly. I’m not being critical though. You want to program for the iPad? You’ll use Objective C. For the Android? You’ll write in Java. At least for a Windows 8 device you can write your app in Javascript … or C++ … or C#/VB. The languages are (mostly) open; the application code is locked in.

I had tons of fun following along with Chris Tavares and Chris Sells as they built a Metro RSS Reader in JavaScript. The resulting demo app looks like this:

WinJsDemo-Part 5

I stole borrowed almost everything I showed from Chris’ talk … unless I pinched it from Luke Hoban’s talk.

It’s always a kick to take a new technology out for a spin. The Microsoft folks are doing wonders with JavaScript on Windows but it’s still a dog walking on hind legs and always will be. I get … and approve of … what they’re doing: embracing the fresh faces coming out of school who “know” (be very wary of that verb!) HTML and JavaScript … not C#. That’s smart business.

I expect to keep playing with JavaScript and writing about my experiences. I’m sure that it’s the perfect tool for many jobs. HTML and JavaScript (of a more general variety) may turn out to be the universal solvent for cross-vendor mobility apps.

But not now and not soon. When it’s time to get serious about writing business applications, I’m sticking with the XAML technologies, Silverlight especially. Far more productive, less painful, and less risky in the hands of muggles … which is to say, most of us.

Thursday, September 22, 2011

“Desktop” could be Win 8’s killer feature with consumers

Crazy? Or just counter intuitive? Give me a moment to explain.

The story everyone tells goes something like this: Microsoft is strongly entrenched on the PC and in the enterprise. But (XBox and Kinect aside) it’s lost touch with the consumer. Lose the consumer and you will lose the enterprise. It’s only a matter of time before iPads displace PCs just as PCs displaced IBM 3270 terminals. Microsoft must respond quickly with consumer-friendly mobile products.

I agree for the most part. And I feel terrific about the Windows 8 preview and tablet that Microsoft unveiled at //build/. Microsoft definitely got some of its mojo back. I’m not just on a “sugar high” as some would have it. Windows 8 is a giant step in the right direction. Regular folks really do like that Metro look. The “developers’ preview” is obviously not as polished as the iPad but there is time before release to perfect the fit and finish.

Unfortunately, it won’t be released until December 2012 (give or take). Fifteen months! In a few weeks, after we’ve sobered up, that’s going to feel like forever. Sure, when the grand day finally arrives, we’ll be cheering for the underdog, the version 1.0 Win 8 newbie against the heavyweight 3.0 iPad market leader.

Hmmm. Should we be worried about a replay of the Windows Phone adoption debacle?

Lessons from Windows Phone 7

There is nothing seriously wrong with the Windows Phone itself. It’s a joy to use, in some respects superior to the iPhone and in no material respects is it worse. It’s where Metro was born … the same Metro that’s going to wow the tablet market in 2012. Critics loved it … as they love the Windows 8 preview.

We can’t fault Microsoft for losing sight of the consumer. The Windows Phone is totally consumer-focused; two years in and we still lack an enterprise story. To make sure we get the point and avoid all possible confusion, Microsoft killed off WP7’s enterprisey predecessor.

How is that working out? Microsoft’s share of the phone market has declined steadily and is headed for 1%. Great phone, unwavering consumer focus, pitiful results.

But wait,” they say, “it will all get better with Mango!” Really? Mango is indeed a huge technical improvement. But I don’t understand why that will make a difference in the marketplace. It is not sufficiently different from the iPhone. Seriously, what will I be able to do with a Mango phone that I can’t do with the iPhone? I’m sure you have a list; will anything on that list be enough to change consumer behavior? Will any of it change the foot-dragging behavior of the sales channel? I don’t get it.

Look, I completely buy the consumer friendliness bit. The traditional desktop experience doesn’t fly on the phone and it won’t fly on the tablet. The way we write business apps today is totally alienating. So I’m down with the design vision: “Metro good, touch good, square windows bad, icon overload bad, mouse-and-keyboard bad.”

The Metro-ish design changes are absolutely necessary … but they aren’t sufficient … because the iPad (like the iPhone) has a commanding lead in these respects.

Windows 8 can be super great … and still bomb at the box office. “Great” isn’t good enough. If it were, Apple might have displaced Microsoft on the desktop long ago. The Mac was always prettier and easier to use. Didn’t matter; share never broke 10%. Twenty years and the Mac couldn’t knock Microsoft out of the ring. It was Microsoft’s ring.

If “great design” isn’t good enough, what is good enough? What does Microsoft have that Apple lacks? What would make someone choose a Microsoft tablet over an iPad tablet … maybe even put down the iPad and take up a Win 8 device.

Enterprise software

I argue that consumers – not all, but millions of them – would put down their iPads and buy Windows 8 tablets if they had the ability … nay, the ease … of running their existing enterprise applications on that same fun tablet.

We consumers aren’t just sitting around watching the Price is Right while stuffing Twinkies into our mouths. Most of us have jobs. Many of us use computers on the job. And while we may season our days with guilty pleasures (“hello, Twitter”), we occasionally get work done.

News flash: people take their work home! Americans especially. The work we take home is often written for and running on a Microsoft Windows machine.

Why does Microsoft appear to be running away from this obvious fact? Microsoft could … and should make work life – the life bound up in Microsoft-based business applications – a high-profile component of the Win 8 marketing plan.

Unfortunately, conventional wisdom says they shouldn’t do that. Conventional wisdom says that mobile devices must cater exclusively to an infantilized consumer.  Little baby consumer want pretty applications that are fast and fluid. Little baby consumer want an RSS reader with big pictures … like this one straight from the Jensen Harris Metro-style keynote:

image

Say what? Geez, who doesn’t need a little pizzaz in his life but call me different: my RSS reader is for reading. Jensen, dude, you’re showing me eight pointless photographs when I want a list of twenty titles and abstracts … you know, something I can use.

But I digress …

Where did we get this limiting caricature of the consumer? I think we bought it from Apple.

Where did Apple get it? Market research? I don’t believe it. I believe Apple made it up. It’s too convenient.

Apple has no enterprise play. They couldn’t promote enterprise applications on the iPad because they have no enterprise applications to promote. So they follow the Apple playbook: if we can’t do it, you shouldn’t want to do it. They pretend that mobile is some kind of other worldly, purely personal experience where work does not belong.

The sad thing is that Microsoft is falling for it. They fell for it with the phone. They’re poised to fall for it again on the tablet. By slavishly chanting Apple’s mantra, Microsoft effectively disarms itself.

Let me be crystal clear.  The tablet is not a PC. Mobile is not the office. Traditional business application UX is tired, clumsy, and unfriendly; todays business apps are as ill-suited for work as they are for play. WIndows 8 Metro is cool beans and a necessary way forward.

But its not all about fun and games. Apple owns that market anyway. Microsoft must wrest it away from them. Microsoft can’t win with great design. It can’t win share with advertising.

Let me channel today’s consumer for you. I …. don’t … care! Microsoft, I think you’re irrelevant. You’re going to have to rip that iPad out of my hands and compel me to use Windows 8.

Convince me, Microsoft, that I can play while I work on that one hot device that covers both my personal life and my job life. Convince my boss that the Windows 8 tablet is both a match for the iPad and a productivity platform for enterprise applications … at no additional cost.

Perfect execution of the perfect Windows 8 design won’t move the needle in 2013. By then it will be “me too, too late”. 

But enterprise software is the differentiator that Apple can’t match. Exploit that. Don’t let Apple fake you out. Leverage your strength. The enterprise angle must be a strategic element of your consumer play.

That’s why I think the Windows 8 “Desktop” stack is the killer feature in Windows 8. Ignore the voices that tell you otherwise. Is “Desktop” too confusing to some consumers? Work on making it less confusing. Don’t kill it; invigorate it.

Energize your enterprise developers – hundreds of thousands strong – who want to Metro-ize their business apps. Stop telling them what they can’t do in Metro. Inspire them to build great Metro business apps. Get moving on the roadmap for the enterprise store; get a proto-type out there. Reassure your corporate customers and developers that you mean business by investing meaningfully in the evolution and marketing of the mature technologies they use today. Praise Silverlight 5 and get hopping on Silverlight 6. We aren’t writing business applications in HTML and JavaScript today. We’re not going to have production ready HTML/JS apps in 2012. That’s just jerking us around. If you really don’t think Metro is the answer for all desktop application needs, then paint us a Windows future that is an answer and build us a bridge from here to there.

I realize I’m proposing an “and” strategy – consumer apps and business apps - not an “or” strategy. “And” strategies are dangerous because they tend to defocus. You have limited resources to be sure. But you can’t just go to market with a carbon copy of Apple’s strategy. They’ll kill you like they’re killing you on the phone. How many billions will you spend for a few points of share? Redirect a fraction of those billions to make enterprise software a first class, integrated pillar of your tablet … on day one. That’s a damn cheap hedge against a repeat of the Windows Phone launch if you ask me.

Tuesday, September 20, 2011

Metro Business Apps

At //build/ we learned that Metro is for content-centric “immersive” apps and Desktop is for data-centric “enterprise” apps. Jensen Harris said it in his 8 traits of great Metro style apps. Joe Stegman repeated it in his talk, Metro style apps using XAML: what you need to know. That’s the Microsoft party line and outsiders have been repeating it.

Don’t believe it. The real world doesn’t honor marketing boundaries. Expect to see data-centric applications appear on Win 8 almost from the moment of release.

Why am I so sure? Because the same divide has been crossed elsewhere. You’ll find business applications on the iPad today. Is the iPad any friendlier to enterprise apps than Metro? Tell me how … because I don’t see it. I don’t see any way to keep business applications out of Metro.

They tell us “Metro is optimized for immersive content-centric apps”. Well Viagra was optimized to treat hypertension. What’s your point? What is more “immersive” than a business application that fills the users screen for hours at a time?

I had lunch today with one of our long-time customers. They showed me their iPad port of their DevForce-based Windows Forms desktop application. It’s almost a complete port and they don’t foresee any barrier to finishing the job.

It looks remarkably like a typical Windows Forms app: the same gray background, same simple icons, same grids and forms over data, same tabbed interface. They made adjustments of course to accommodate touch and asynchronous server communications. There was no attempt to fancy it up; it doesn’t pretend to be a typical consumer facing iPad app.

Customer acceptance has been fantastic … because it does the job in a familiar way. We could talk about UX design all day and it wouldn’t change a thing. The UX app is exactly what users expect. And not just existing customers; the iPad version appears to be driving new sales.

What could keep them – or anyone – from porting to Metro WinRT? Three obstacles come to mind.

  1. Must deploy with the Windows Store
  2. Metro app certification
  3. Paucity of data-centric features

Our customer could leap these hurdles effortlessly.

Windows store deployment

I’m mildly concerned that there is no substantive enterprise deployment story. Ted Dworkin mentions it once in his talk, Introducing the Windows Store, before returning to the talk’s thesis:

We have an enterprise story that supports their unique needs … but fundamentally the Windows store is the only place that Metro-style apps can be acquired. (11:20)

I can hardly wait for that “enterprise story”. Big companies simply will not deploy their apps through a Microsoft store. I hope that Microsoft talks sensibly about an acceptable alternative – probably in the form of an enterprise store – within the next six months. I’ll take up this subject in a later post.

However, smaller companies may not be inhibited by the lack of private store. Our customer delivers its iPad client as a free app via the Apple store. Anyone could download it … but only their customers actually would. You can’t do anything with it unless you’ve first deployed the companion backend server; you acquire the server and pay for that server separately.

Metro app certification

Apple’s iOS interface guidelines run over 100 pages. Yet our customer passed Apple’s certification with a Windows Forms UI. Would it pass Win 8 Metro App certification?

It wouldn’t pass the Windows Phone certification which dictates fine points of UI style such as application navigation. We don’t have a software certification guide for Metro apps. But we have some clues sprinkled among the //build/ talks and we have the example of applications shipped in the preview.

My reading is that the Metro specs would not adversely constrain a business application experience – even if the application looked like a Windows Forms MDI application. I saw rules about screen and image resolutions requirements. I didn’t seen anything that dictated how I use the back button. I can’t have a child window; I can overlay the screen with some something that achieves a modal dialog effect. The keynote on Day 1 demonstrated conversion of Scott Guthrie’s Silverlight business app. I look at the Metro version of Internet Explorer and I know I can write a conforming business application.

Missing data-centric features

The Metro preview and sample applications emphasize content consumption. There are essential input controls such as textboxes, radio buttons, list boxes. But they appear to have forgotten about data grids.

if you follow this space, you remember that I dislike data grids; I think they’re a design cop out. That’s my opinion, shared by a tiny minority; the rest of you want your data grid … and you should have.

The Validation attributes in System.ComponentModel.DataAnnotations are missing as are related interfaces such as IDataErrorInfo and INotifyDataErrorInfo. Apparently, in it’s wisdom, Microsoft thinks that client-side validation of input is unnecessary even for consumer apps. I hope they reconsider before release but we’ve survived without them before and can do so again.

Why would you want to build a Metro Business App?

Metro apps will only run on Windows 8 (and later … if you’re the optimistic sort). I’m guessing Windows 8 won’t release until this summer of 2012. Most companies have not yet or have only recently adopted Windows 7; optimistically, a significant number get to Windows 8 late 2013. Most of us don’t write software today for first deployment in 2013.

The Windows 8 tablet is the wild card. If it has the hoped for reception in 2012 it could be a factor in driving Win 8 into the corporation … not as a replacement for existing desktops but as the viral alternative to the Apple iPad. We can dream, right?

If the Win 8 tablet is a hit, you’ll want to be on it … and not just in the blue “Desktop” stack. Some reasons:

  • ARM tablets, with their better battery life, could dominate. Metro apps will run on ARM. Desktop? They will probably only run on power hungry Intel tablets.
  • High performance Metro XAML in native code with GPU acceleration; Desktop XAML is managed code with more limited GPU support.
  • Ready-to-wear Metro Visual Studio templates.
  • Superior touch support and easier access to tablet hardware.
  • Win 8 “contracts” for integration with other Metro apps and cloud services
  • Better cloud integration facilitating “continuous applications” that move application state across devices as the user switches from phone to tablet to desktop.
  • Ride the software platform that Microsoft is promoting and evolving.
  • The “Hotness” factor … don’t discount it!

Those are big draws. Why should I toe the “Desktop for LOB” Microsoft line when I can sneak into Metro and party with the cool kids?

Get ready for Metro

Whoa, cowboy. This is the time to pay attention to Metro … and little more. Right now I wouldn’t take my business application beyond exploratory stage in Metro or WinRT.

How would I build production applications? I’d write them in Silverlight until the fog clears. I’d write with a Metro mindset. I’d isolate anything in Silverlight that isn’t in Metro – hide it behind a service interface - so I’d be prepared to swap out the implementation later.

See Brian Noyes high-level discussion of what this entails in his post, “Silverlight Developers have the smoothest road to metro.

If I could I’d design all new screens to follow the Metro style guidelines. The Windows Phone 7 Metro style was crossing over to Silverlight design before Build; Win 8 should accelerate that trend.

If Metro is as successful in the consumer space as we hope, business applications will be written as Metro apps.

Fortuitously, I noticed that Rocky Lhotka agrees as he explains in "WinRT and business apps”.

Tuesday, September 13, 2011

The BUILD Report #1: Sinofsky keynote

 

Here’s my unedited feed/stream-of-consciousness from the cheap seats in the arena where Steven Sinofsky is giving his Win8 Keynote.

Build Keynote from cheap seats

Sinovsky opens touting WIn 7 and IE 9 market success to date.

Claims touch is so compelling that once you have it on your screen you’ll want on all screens; not my experience in the last year … and that’s not because it doesn’t work. Don’t like leaving the keyboard. As the demos proceed, I start to wonder if I’m going to have to use touch to use Win8. See below

Emphasizes that no matter how new Win8 is, everything running on Win7 will run on it. Reiterated throughout the keynote. That’s important to business which must migrate more slowly and a strong contrast with Apple. Means you can be sure the .NET apps you write today will have a good run on the next h/w and OS.

Win8 memory footprint and CPU efficiency improves on Win 7 … by a lot. That’s encouraging again for companies with tight capital budgeting.

Julie Larson-Green demos. Nice “picture password” = gesture login. No password … just gestures. Sweet. Audience applauds. Twitterverse agrees. Business should like too.

The demo is all touch. It’s a little balky but that’s not what concerns me. I’m not sure I want to interact this way. Great for casual user (consumer) but, when you live on a computer, do you want to touch? Maybe I’m freaking out prematurely. It’s not that much different from using a mouse. They recognize my anxiety and reassure us that keyboard and mouse are there for everything. Later, S “I’m a keyboard person” reiterates and demos later (although he does mouse in his demo).

The “chrome-free” browser gag went over well. But it really IS nice that the IE browser has no chrome. Very metro … and the cleanliness works (despite the onstage demo struggles).

The “fast and fluid” principle is more than fluff. It’s a design principle that makes a genuine difference in comfort. Shown effectively in Julie’s demo.

“How to build”

S: “You pick the language/platform you want to use”. Windows Runtime (WinRT) with client tech (HTML, C++, C#/VB) riding above without privileging any one of them. S. reiterates this point several times throughout, trying to drive that home.

The first development demo starts with JavaScript templates in VS. That might make a XAML worrier nervous. But I’m convinced that S means it and that XAML is first class. The port of the Silverlight 2 demo was effective (note to self: what am I to make of a port of Silverlight TWO). This is a big deal to “my people” so I’ll be talking more about that for sure.

Metro is the privileged design language … which is a good thing for business app devs as I’ve said elsewhere before.

 

“Windows” javascript api grants access to the OS somehow, as in “Windows.Storage.Pickers.FileOpen …”

Big cheers for Blend as an HTML/JS tool. Expected, sure, but it’s still important. The layout ease, the Metro-built-in is nice and productive. Some noise about how this isn’t new in the world. So what. The issues isn’t whether it breaks ground but whether it delivers on the productivity promise. Looks like it will.

The write-build-show cycle is crisp.

Windows App Store: Store menu in Visual Studio. Built-in licensing model includes trials (but can put your own in). That shows seriousness. They will have a certification process. What about bureaucracy (we know how ugly that is in WP7)? They hope they can allay with (a) a process queue and (b) automated compliance checking tools [big applause for that one]. Now making it easier to find s/w in categories (a problem in today’s WP7 marketplace).

The Win App Store is written in HTML/JS. They ballyhooed as a vote-of-confidence in that app technology. Is there a reason it should be HTML/JS? It could only host apps for Windows platform so no x-plat justification. Could have been … should have been? … in Silverlight.

So what about deployment of LOB apps in the metro/immersive app environment.

XAML segment

Sinofsky cheer leads. That’s important to dispelling the belief/suspicion that S hates .NET.

Nice job of taking an old SL2 Gu app and migrating to Win8 w/o changing the app itself.

Then metro-izes by swapping one XAML control for a new Win8 grid control + 2 lines of code-behind + manifest tweak to make it searchable in Win8 => looks metro. Nice. Search and runnable from the dekstop.

This deployment is to the NEW Win8 look. In the prior Win8 show, they created fear that would only run in the old Win7 shell. This time, not seeing an old shell. Only showing one shell. AND XAML apps run in it. I couldn’t see any distinction between HTML and XAML app in the shell.

Another tweak and it runs in the phone. Very nice. Ok, demo alert, right? It won’t be that easy in reality. That doesn’t diminish the direction; they are putting their back into making XAML apps metro and their deployment easy with tooling.

S emphasizes again that Win8 is supportive of your technology choice.

The sensor fusion stuff could get you thinking about how tilting the tablet could be used in a bus app UX. It’s easy enough to justify exploring it and using it without fear that you’ve saddled the non-geek dev with incomprehensible, maintenance problem. NFC (near field communication) support makes it easier to write apps that interact with the physical world. POS and field inspection apps come to mind.

Renovated OS tools

Control Panel, Task Manager, PC Reset … just plain nice for developers. Hyper-V in the Windows client.ISO mounting built-in.

“Ease of Access” support could matter to those of you who have regulatory requirements affecting your app’s UX.

Ink / Touch disambiguation revives pen and the accuracy that comes with it. Take that, Steven Jobs.

Windows Live is the backbone of the roaming features with which you propagate settings across devices.

Cloud Integration

Chris Jones talking about Cloud Services. The mail client is HTML/JS … as it should be as it must be x-plat. The app metro design is straight out of WP7 mail app. It certainly is responsive. But have to say that some of the views are clunky.

The WP7 hub paradigm is now on Windows Live. People, Photos, Mail. The hub paradigm works; this is a great move.

“Every Win8 user has a SkyDrive”. Of course that is great for consumers. But this could be a terrific guarantee for bus. app developers too … assuming that business allows that kind of personalization in the app. When you know that SkyDrive is there, the integration is there, and it’s easy to reach … you can consider making that integral to the app w/o worrying if the user is configured for it … because she always is.

I don’t think it’s Drop Box (no auto synchronization), but its great ‘cause it’s in there. Now what about security? I haven’t been that careful with my Live password. Time to get serious. Would need to work on that if I was building Windows Live into my application assumptions.

Not available today? The APIs are there today but we’ll have to wait a little for the releases in the cloud … and that’s ok.

The Big Giveaway

Hard to deny the enthusiasm for the Samsung tablet – an Opra moment.

The Mom Factor

Dan Wahlin told me (I paraphrase) “My mom would love Windows 8 – she would get it – and that’s important to the Microsoft business application developer. The Microsoft platform has to succeed broadly; if the consumer deserts Microsoft, so … ultimately … would business apps.”

I agree strongly.

Release Schedule

The “Preview” looks impressive… for a preview. S says “No release date because driven by quality, not the date”. Sure … but I get the feeling it won’t be far off. They’re going wide tonight (8 pm PST) at dev.windows.com. No activation. That’s a strong statement because you know how many people are going to write apps on that preview in volume.

The BUILD Report: get it while it’s hot

The Microsoft BUILD conference starts tomorrow. My IdeaBlade buddies will be there. I will be there. In a flurry of small posts over the next four days I’ll be reporting on what’s being said officially and unofficially, on stage and in the hallways. I’ll give you immediate reactions and instant analysis from the perspective of the business application developer.

I’ll be interviewing many fascinating folks and passing along their insights …I hope with attribution.

Clearly I can’t cover everything. And “instant analysis” is … well it’s instant. Enough said?

When I get back, catch my breath, and have time to reflect, I’ll try to make sense of it all.

Meanwhile,  ride with me, send in your comments and questions, and enjoy.

Posts in this series:

The BUILD Report #1: Sinofsky keynote

Tuesday, August 9, 2011

And the (ORM) survey said …

In mid-May 2011 I ran a short survey about ORM usage among .NET developers. I wrote a draft of this blog post back then … and forgot to publish it (doh!). I’m finally doing so now in August in hopes that it remains relevant. I don’t know if attitudes have changed (do you?) but what the heck … I might as well …

The Survey

The survey was prepared on and hosted by SurveyMonkey, a free/low-cost survey site. It ran from Monday, 9 May, to Wednesday, 18 May, 2011. It consisted of two questions. Here’s question #1:

ORM_Survey_q1

If … and only if … you answered “Entity Framework” did you get to see question #2:

ORM_Survey_q2

The survey permitted only one survey answer per person but you could come back later and revise your answer if you wished.

The Results

You can see the survey results on the SurveyMonkey website.

I downloaded all 896 individual responses as of May 18 into an Excel spreadsheet.The spreadsheet is useful if you want to correlate comments with question answers. The comments can be entertaining.

Here’s a picture of the statistics as displayed in the spreadsheet:

ORM_Survey_stats

Survey Goals

The survey seeks insight into how developers of .NET data-driven applications prefer to manage their data. More specifically:
  1. Would they use an ORM … or not.
  2. If they would use an ORM, would they use Microsoft’s Entity Framework; the popular, open source NHibernate; or some other ORM tool.
  3. If they would use Entity Framework (EF), which style would they use to develop their entity models. As of version 4.1, EF offers three styles called “Database First”, “Model First”, and “Code First”.

    For you readers who don’t know what those styles are, I recommend Julie Lerman’s summary of these styles (she calls them “workflows”) and her May 2011 MSDN article on the subject.

I wanted developers to respond as if they were:

  • building an application with a medium to large model
  • free to choose the data modeling/access technology
  • required to work with an existing relational database of many tables, filled with irreplaceable production data.

Survey Design

In this section I talk about how the questions were formed, how I found the respondents, and survey bias.

The questions

The survey only had two questions – and you couldn’t reach the second question unless you answered “Entity Framework” to the first. I was adamant about keeping it short. I hate long surveys and assume others do too.

I really wanted to ask demographic questions. I wanted to know about respondent backgrounds, what kinds of apps they built in which client technologies for what kinds of customers. Were they architects, trainers, or practitioners? Were they actually committed to building with the selected technologies or only hoping to do so or merely advising others to do so?

I backed off mostly because it would have bulked up the survey but also because I had no hypotheses at that time that required demographic information. As a general rule flailing away with pointless questions invites spurious correlations. If the survey results suggest new hypotheses, someone can pursue them independently.

Some folks were miffed that they couldn’t answer the EF development style question unless they intended to use EF. Sorry … sort of. Question #2 is about how EF people would use EF. How an NHibernate person would develop an NHibernate model is interesting but out-of-scope. Moreover, I didn’t want to muddy the interpretation with advice to EF developers from people who wouldn’t use EF. The second question is not a vote on best practices or preferred technologies; it’s trying to surface the practices that EF people intend to use.

A number of respondents want to pick more than one answer. They wanted checkboxes instead of radio buttons. Sorry but you’ll have to come up with your own survey. I deliberately forced you to choose … as you would have to choose when faced with one application to build. You were not granted the consultant’s luxury of saying “it depends”. I left you room to vacillate in the comments.

I have one regret about question #2. I failed to make clear that the “100+ table, RDB application” context that I described in question #1 should apply to question #2 as well. That was my intention. I didn’t say so in the phrasing of the question; it is clear from some of the comments that many respondents weren’t sure about this. I’ll never know the degree to which that uncertainty skewed the results.

I’m going to do the only responsible thing and blame my survey reviewers for failing to raise the alarm before I launched the survey; shame on you guys!

The Sample

The sample is far from “scientific”. I did not ask an independent, qualified research group to identify and survey an unbiased sample. I simply announced the survey on Twitter on May 9th. I asked everyone I could think of to re-tweet it; many of them did. I learned that IdeaBlade announced it on the DevForce forum but no one, to my knowledge, sent email to any of our lists. I figure if you answered the survey, you learned about it on Twitter. Which means you probably follow me or follow someone who follows me.

It’s reasonable to suppose that we have interests, opinions, and experiences in common. We are in none of these respects the norm for the general .NET developer population. Accordingly, I’m reluctant to apply my interpretation to that broader population. Well … kind of reluctant.

Frankly, I am too cheap to do it properly. While I think the survey questions are defensible, I’ll concede that the sampling technique is not … and introduces a significant bias of some sort. Of what sort? I take that up next.

Survey Bias

Many of you took me to task on my approach to sampling … and we’re free with your conclusions about how that would bias the results. My secret pleasure in this is that you had so many different and conflicting notions about what that bias would be.

Some were sure that it biased the survey toward EF. Some said it biased the survey against CQRS and NoSQL. Some said it biased the survey against native ADO approaches. Some said it biased the survey in favor of egghead pontificators who have no practical experience.

Some people see a bias in the survey’s goals. I suppose there is an existential “bias” in one’s research interests. I’m please to ponder the significance of wanting to know one thing versus another. Don’t stop there; ask me why I’m running a survey about ORMs instead of world peace.

I’m more concerned about survey bias. What factors in the questions, the sampled population, the conduct of the survey, and the interpretation of results that undermines the survey’s avowed research goals?  I’m sure there are plenty of such factors. I’m not sure where they point.

I was twice accused of confirmation bias, which in brief means “a tendency for people to favor information that confirms their preconceptions or hypotheses regardless of whether the information is true.”  I’d be more susceptible to this charge if I had preconceptions to confirm. Take question #2 for example. I don’t have a theory about which EF development style people will prefer. I guessed that “Code First” would win about 10% of the votes, not 42%. But I was no more invested in the outcome than I am when guessing the number of jelly beans in a jar.

Question #1 is a more delicate matter. My company placed a bet several years ago that EF would eventually dominate the .NET ORM space. Around 66% of survey respondents favored EF; NHibernate was a distant second at 18%. This outcome is certainly consistent with my expectations. Is that evidence of “confirmation bias”? You can’t call a survey “biased” simply because the results seem to favor the author’s prediction. You have to explain how the question or the conduct of the survey favored EF. I don’t understand how that could be in this case. The question seems innocuous to me. And while my twitter-verse is indeed ORM friendly, it is not pre-disposed for or against EF; I’ve got a ton of EF-hating friends.

So you still think my audience tilts towards EF? Maybe it does. But is it significant? The gap between the EF preference (62%) and the preference for all other ORMs (18%) is 44%. How do you explain that?

Bias toward ORM uses

As I see it, the gravest potential for misinterpretation would be the misguided assumption that most developers know about, care about, or use ORMs.

People reading this blog as well as people who took the survey are acquainted with ORMs. We either use one or have used one. We like them or we hate them. Remember, only 7% of respondents said they wouldn’t use an ORM

The sample must be severely skewed if only 7% say they won’t use an ORM. I know that the majority of developers in the general population don’t use an ORM. How do I know ? OK … I don’t have hard facts. But I have strong anecdotal evidence. Most of our customers and prospects have never used an ORM before. I’ve been to a lot of user group meetings and, based on a show of hands … on several occasions …, a tiny few of the attendees know squat about ORM.

We have to be careful in our interpretation of this survey. We can’t say much about developers in general. We might have gleaned something useful about developers who use ORMs.

Interpreting the Results

I wasn’t surprised by EF’s dominance … as I noted above. It seems EF v.4 is finally over the bad press that greeted v.1 and is begrudgingly accepted as “viable” even by staunch NH supporters.

I was surprised at the affection for Code First. Few could yet have tried it. Evidently it taps into some disaffection with the “database first” workflow and its visual designer. People I deeply respect have tried it a few times and they like it a lot. They haven’t built anything significant with it yet … but what they like about it resonates strongly with me. I’ll have more to say in a future post.

On the other hand, “database first” has ardent fans (read the comments). It’s the majority choice and will remain so as long as most developers who conceive of their applications primarily in terms of the data they store. Database management tooling is capable and the practice of simultaneously evolving schema and code is entrenched.

I’ve tried both “database first” and “code first” development. There isn’t an obvious productivity winner. One could pick a side on other grounds, but only a clear productivity edge will shift the balance among active developers.

So it looks like “Code First” will have a strong following much sooner than I expected. But it won’t hurt “Database First” which will remain the popular choice.

My Commercial Agenda

I’m a curious guy … but I don’t run surveys for the fun of it. The survey was honest but it wasn’t innocent.

Consider the survey’s framing context: an application built to accommodate a 100-table existing database. My company, IdeaBlade, makes and sells a product called DevForce. DevForce helps you build data-driven, Rich Internet Applications. Our sweet spot is the customer who intends to migrate an existing Line-of-Business (LOB) application to Silverlight or WPF. The existing data store is almost always a relational database.

This customer is torn about how to get there. He’s acknowledged that the application will have to be rewritten back-to-front … which opens the door to a new data access architecture. But he’s not completely free to start from scratch. He has an existing business to run with real customers and real data. He’ll have to maintain the existing application while building its eventual replacement. He is naturally reluctant to rip out the database or even restructure it. I wanted the survey to elicit responses from professional developers facing a comparable situation.

EF First

The attention to Entity Framework is no coincidence either. DevForce is not an ORM and can work with any source of data; our value really kicks in after you’ve defined your entities and figured out how you will persist them.

But DevForce is cozy with the Entity Framework. Close alignment with EF was a business decision, not a technology judgment. It has worked out well for us and our customers. The survey results indicate that we made a sound choice … and shouldn’t bother integrating with NHibernate or another ORM; the commercial demand is simply not there.

You may feel differently. You’re not selling an infrastructure product. You may have good technical reasons to prefer a different ORM. I suggest, however, that you factor industry trends into your decision.

Code First

We really wanted to assess the appetite for the new EF “Code First” style. DevForce currently favors the “Database First” and “Model First” styles. We extend the EDM with our own attributes, the EDM Designer with our own properties, and we can generate our own classes from the conceptual model’s XML.

Should we stick with those workflows or add support for “Code First”? We suspected that “Code First” would attract an audience. We weren’t sure how big or when.

The survey tells us it’s going to be big soon; nearly 42% of EF respondents chose “Code First” as their preferred style, just 5 points below “Database First”. So we’re hustling on our Code First support. We just released the first preview which gets us more than half way home. You can read about it here and I'll have more to say in future blog posts.

Got an opinion? I want to hear it.

Friday, July 1, 2011

Read “Win 8-Longhorn Dream Reborn”

Unless you’ve been taking a long and much needed vacation in the woods, you’ve heard something about Windows 8, Microsoft’s promotion of HTML5, and it’s coy silence about the future of .NET.  You are probably a little spooked if you’ve committed some part of yourself, your product, or your company to WPF or Silverlight. Does anyone know what is really going on?

I have no revelations for you. I wouldn’t be allowed to blog about revelations if I had them. I don’t have anything fresh to say either. I do have opinions ... details of which must await a future post.

In summary until then ... I’m not worried. While we at IdeaBlade are exploring what it means to have a DevForce JavaScript client, no one should mistake that interest for wavering in our commitment to .NET. We are confident that XAML clients will thrive for a long time to come.

Of course that’s what we think. Microsoft has done a fabulous job of creating uncertainty about the future of Silverlight and .NET. I’ve had plenty of conversations with colleagues and customers who are paralyzed by doubt. Frankly, that’s not good for our business. I don’t think its good for your business either. Perhaps you can afford to wait … and wait … for some magic moment of clarity. Will we know more in three months at the BUILD conference? Sure … although if I’m certain of anything it is that Microsoft will keep the mixed messages coming.

You have to make a decision at some point based on the best information available. To that end, I direct your attention to a highly-regarded, week-old article in ars technica by Peter Bright: “Windows 8 for software developers: the Longhorn dream reborn?” It’s well-written, well-reasoned, and grounded in a bit more than opinion and rumor … as in the author is talking about what’s actually in some of the early bits.

I’ve read it over a few hundred times and … honestly … it still seems right to me … right down to it’s stirring conclusion:

Far from being a developer disaster, Windows 8 should be a huge leap forward: a release that threatens to make development a pleasure for native, managed, and Web developers alike.

Here are my favorite excerpts:

  • Windows 8 will ship with a pair of runtimes; a new .NET runtime and a native code C++ runtime.
  • There will be a new native user interface library, DirectUI
  • A new version of Silverlight (v.6? codenamed Jupiter?) will run on top of DirectUI
  • DirectUI is built around a core subset of current WPF/Silverlight technology and includes support for XAML.
  • This core will give C++ programs their modern user interface toolkit and, at its heart, it will be the same toolkit that .NET developers use too.
  • XAML and the WPF-like, Silverlight-like way of developing GUIs are going to be absolutely central to Windows development in the future.
  • It gives parity to native C++ and managed .NET code. Instead of being separate, each with its own different capabilities and strengths, they will be peers.
  • Want to write an immersive application in native C++? That's cool. Want to use C# and Silverlight? That's cool too. Both will be supported. Far from being left behind on the legacy desktop—which was the impression that many took from the presentation—native C++ and managed C# will both be first-class, supported ways of developing immersive, touch-first, tablet-friendly Windows 8-style applications.
  • HTML5 and JavaScript will be an option too [with] greater access to operating system functionality than regular webpages … Feature-wise, they should be at the same level as .NET and native programs. It's just that they'll use an HTML5 programming model and JavaScript.

Wouldn’t it be great if Microsoft came out and said this? Or said anything?

They won’t … not until their BUILD conference in Anaheim in September. Microsoft isn’t deaf. They know all about developer anxiety on this score and have decided to do nothing to allay that anxiety.

Fine. Be that way. Meanwhile, those of us who have work to do are wise to keep moving along the .NET client track.

Related Articles

A David Burela post, "Premature cries of Silverlight / WPF skill loss. Windows 8 supports all programming models", offers a wealth of detail extracted from the Windows 8 Milestone 3 leak, all consistent with the ars technica article.

On July 6, InfoWorld published their take on these matters in "The fall and rise of Microsoft Silverlight"

Silverlight found a foothold in Windows Phone and has more recently emerged as a key component of the Jupiter application framework and programming model for Windows 8. If Silverlight has become less important as a rich Internet application (RIA) framework, it has become more important to Microsoft's desktop and mobile platforms overall.

Again, it's more tea-leaf reading than hard news ... but it reflects the emerging consensus that .NET and XAML clients remain at the forefront of Microsoft development technologies.

Stephen Forte of Telerik posted his musings on the future of XAML clients. Noteworthy to me is what Telerik is actually doing about it:

I don't see Silverlight as being dead, but rather reborn bigger and better. Instead of being its funeral, the Build Conference will be Silverlight and XAML's graduation party. At Telerik, we are also going to double down on our XAML strategy. ... We see Native XAML as a massive opportunity and will continue to support our XAML tools now and in the future.

That's putting serious money where their mouth is. Why not you?

Friday, June 10, 2011

Intersoft ClientUI does Photos

I’ve written twice before, here and here, about the Intersoft Solutions MVVM sample that relies on DevForce for model development and distributed data access. The sample is most notable technically for its MVVM style and the surprising fact that the source code compiles both to WPF and to Silverlight. Just about every line is the same across platform … including the XAML. The dual-platforming is a signature feature of Intersoft’s UI control suite … and DevForce itself. We’re both kind of proud about it.

I’m writing this post to tell you that the good folks at Intersoft have added some new features in version 3 of the sample. I encourage you to check out Jimmy’s post to learn the details, see some gorgeous screen shots, and download the source code.

Uploading photos

My favorite new feature is the ability to upload images from the client. Intersoft offers a new UXFileUpload control to manage the user interaction and the mechanics of copying an image to a directory on your server. To quote Jimmy, this control enables “multiple file upload, progress indicator, upload cancellation, and a fully customizable look and feel”.

In the featured scenario, the application stores the URL of the uploaded image in the Contact entity which is saved in turn to the Contact table in the database. The sample shows how to bind the UploadedFileUrl of the upload control to a property of the Contact in a manner consistent with the MVVM architectural style.

Here’s a screen shot of the “Edit Contact” screen displaying the photo.

Other cool stuff

Intersoft keeps adding to and improving its controls. One of them, the UXMaskedInput, gets a workout in this sample where it

  • Automatically uppercases the ID input
  • Limits the zip code to five digits
  • Masks the phone numbers in the Phone, Cell and Fax textboxes

If you’re looking for beautiful controls, an MVVM mindset, and developer productivity for your next WPF or Silverlight application (or your next WPF+Silverlight application) … head over to Intersoft and see what they’ve got going.

Tuesday, May 24, 2011

Use wildcards to include resource files in a project

Just discovered from Keith Rome’s blog post that you can use wildcards to include files in a project. This is occasionally useful as when you have lots of resources.

For example, in the IdeaBlade Bookshelf sample application (based on John Papa’s BookClub sample) there is a folder of 58 images:

clip_image001

You can add and remove these files by hand. I admit it’s not that hard to do by clicking “Show all”, scatter selecting the ones that aren’t already part of the project and adding them. But it’s still a maintenance chore.

Alternatively you can edit the project file once to pick up all of the jpgs and never worry about it again.

Begin by opening the project file in a text editor (or within VS by unloading the project and editing the project file; commands for this purpose are available from the context menu).

Each of the image files is mentioned by name in an <ItemGroup/> as shown here.

clip_image002

Replace the entire <ItemGroup/> block with the following:

  <ItemGroup>
    <Content Include="Assets\Images\*.jpg">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content> 
  </ItemGroup>

Save and reload the project. Henceforth, the images will be self-included.

As long as a matching file (any jpg) is in the folder, the build will pick it up. Remove the file and it disappears (no lingering missing link). You may have to click “refresh” in Solution Explorer to get the project to show you the latest list.

Of course you can no longer set properties on the files individually or include/exclude individuals. But it’s a pretty cool trick when you have a pile of identical resources like this.

Who knew?

Monday, May 23, 2011

MVVM Backlash

I and many others have pushed hard for Model-View-ViewModel (MVVM) design over the last few years. No wonder people are pushing back. Two recent conversations have stirred me to reexamine my affection for MVVM screen design. What surprises me is that I’m feeling we slightly oversold it.

In the end, I am unrepentant: I continue to practice MVVM and recommend it to others.

But today I am going to take it down from its pedestal and give it a good thrashing. I’ll admit begrudgingly that you can build a large, maintainable application without it. I will discover that MVVM has only two truly distinctive technical advantages: automated testing of the view logic and integrated design time data. Lots of developers don’t care about either. MVVM may not be for those people.

I’m not going to call them bad programmers. They could be good programmers. They could be great programmers. Are you being bad when you don’t write view-logic automated tests? I’m inclined to say so but not prepared to hang you for it.

Disquieting conversations

I have had a long running conversation with sage and MVVM skeptic, Billy Hollis about MVVM. Billy finds a way to talk trash about MVVM just about every chance he gets. His oeuvre on the subject consists largely of twitter bon mots, barbed asides in lectures, and assorted podcast witticisms. He may have penned his opinions on MVVM somewhere but I don’t know where. Therefore, at some risk of misrepresenting his position, I summarize his position as follows:

  1. MVVM is a way for code-addicted developers to deflect attention from the horrible designs they inflict on users,
  2. MVVM complicates development with little or no compensating benefit,
  3. there is too much strident, jargon-filled, punishing MVVM rhetoric that alienates the mass of developers.

I agree completely with #1. MVVM does nothing to improve UX; our obsession with it robs us of time better spent enriching our design education and delivering more satisfying applications. Nonetheless, I expect to continue that trend with this post and more MVVM commentary to come. I do not apologize; while it is one of my obsessions, it’s your fault if you make it yours.

I ruefully acknowledge his 3rd objection although I believe we’ve largely outgrown it.

Objection #2 – that MVVM adds complexity without benefit – is the controversial claim that I address today. That leads me to my second conversation, the one precipitating this post.

John Papa is developing an outline for his forthcoming video series on MVVM. The series targets developers who know nothing about MVVM. It will explain what MVVM is and explore MVVM techniques.

But why bother with MVVM in the first place?  Why not do the most obvious thing and write all code in the View’s code-behind? What is wrong with that? John wants to address those questions in his video in a direct, matter-of-fact way that any developer can appreciate. That isn’t going to be as easy as he first thought 

MVVM is second nature to John as it is for many of use. We’ve forgotten how we got here. We can recite the academic arguments. We have the PowerPoint slides we’ve used over the years. But if you were susceptible to academic argument, you’d be using MVVM already.

What if we couldn’t get by with the old bromides like “Separation of Concerns” and we couldn’t thump Martin Fowler’s pattern book from 2003 like a bible at a revival meeting? How would we demonstrate that MVVM is better than code-behind?

John kindly called me to puzzle this through with him. We had some fun watching the wheels come off. This post is my account of what we learned. It represents my conclusions, not John’s … although I hope he agrees with me.

The usual arguments for MVVM

Here are bullets from a hypothetical MVVM benefits slide; I’ve drawn them from several presentations, blogs, and discussions.

  • Separation of concerns (SoC)
  • Loose coupling
  • Data Binding
  • Designer / developer symbiosis
  • Reusability
  • Avoid spaghetti code
  • Consistent, maintainable, scalable
  • Support for design time data
  • Automated view-logic testing
  • Multiple views over the same view logic

John and I kicked these around. It turns out that many of them don’t hold water.

We ruled out “separation of concerns” and “loose coupling” right away because they are just jargon to many people.

[update: "ruled out" was a poor verb choice. What I meant was that we didn't want to chant "SoC" and "Loose Coupling". We wanted to get behind the familiar rhetoric. These principles remain fundamental to us ... as I explained in the next paragraph.]

To me they are a convenient short hand for guidance that has always served me well. But for many they’re just slogans, shouted from a little red book.

John and I aren’t sending anyone to re-education camp. We wanted to show concretely how code-behind necessarily betrays you and ViewModel saves you. When we really looked, we realized that ViewModel isn’t intrinsically more SoC or more loosely coupled than code-behind (stay tuned).

Data binding? The practical implementation of the MVVM pattern requires a powerful data binding infrastructure. But you don’t have to use MVVM to use data binding. You can bind the view to the code-behind.

Designer / developer symbiosis” refers to the ability of a designer and a developer to work on the view independently without risk of corrupting the other’s work.  In MVVM, no matter what the designer does to the View, the ViewModel code is untouched. Nothing the developer does to the ViewModel code affects the View XAML. Upon closer examination (see below), I feel that MVVM doesn’t have a strong advantage here … even when (as is extremely rare) the project is blessed with a crew of designer people to assist the developer people.

The “spaghetti code” argument is a canard. MVMV in not inherently more “consistent, maintainable, and scalable.” Bad code is bad code whether it’s in the ViewModel or the code-behind. The view logic is not magically transformed by refactoring to a separate class. If you are inclined to reduce repetition and externalize dependencies into supporting services, you will do so in code-behind as surely as you will do it in a ViewModel. If not … well we’ve all seen train-wreck ViewModels haven’t we?

Design time data support? Check! John and I believe developers and designers are more effective when they design, maintain and evolve the view in Blend (or Cider) using design time data. A ViewModel can easily deliver design data to the tooling and “real” data to the runtime application. The code-behind cannot provide design data to the tooling because the design tools don’t execute the code behind.  I expand on this point below.

Automated view-logic testing? Check! We agreed that automated testing of code-behind is so difficult as to be impractical. Billy agrees too. Score one for MVVM. Of course if you don’t do automated testing of view logic …   I talk more about this below.

Multiple views over the same view logic? Check! ViewModel is for you if you think you’ll need different views for different users – perhaps as part of a localization requirement or perhaps because the presentation should vary based on role. You can build such variation into a single xaml view but that gets messy quickly.

Definitive benefits

Three claims survive close analysis; ViewModel has a decisive advantage when you care about

  • design time data
  • automated view testing
  • multiple views over the same view logic

Do you really care?

I do care … as I said at the top. I care about view-logic testing and design time data. Multiple views are usually just a nice-to-have; but I care a great deal about the first two.

The unfortunate reality is that many (most?) developers don’t seem to care about these things. I can want them to care … but I haven’t figured out how to make them care.

I believe the “design time data” argument may become attractive. Not many people design with data yet. I think that’s because they don’t know about it. Once they discover it and see how handy it is … and see that ViewModel is easy … that could shift the balance.

People have heard the argument for testing for years. I don’t think there is anything new to say, nothing more persuasive to say, that hasn’t been said. The testing adoption statistics are not encouraging. My anecdotal evidence is not encouraging. You know how many ViewModels I’ve seen tested in the wild? You know how many ViewModels I’ve seen tested in a book, article, or demo that cites “testability” as a reason for MVVM? I want to say “none.”

Actually I’ve done it and I’ve got a BookClub demo that shows how. ViewModel automated testing is the way IdeaBlade professional services rolls.

Please, please, please prove me wrong and tell us all where we can see some ViewModel testing.

I might do it if it’s easy

I fear that the unequivocal arguments for MVVM will have only a tenuous grasp on the hearts of many developers. I will argue until the cows come home that MVVM inclines you toward good practices (e.g., SoC, loose coupling). I must admit that if you have good discipline you’ll be fine without it.

I remind you, pace Billy Hollis, that MVVM won’t do a thing for your application’s user experience. Don’t get caught up in the code at the expense of the design! That’s unbalanced. That’s not healthy.

I suppose what I am saying (and lot of people are saying ) is “take this MVVM medicine … it’s good for you … even though you may not feel different right away. ”

That means MVVM must be easy to do. If it were hard you would be mad to follow our lead on the strength of these assurances. We’re telling you to create an extra class – the ViewModel class – for almost every View in your application. You might write a hundred “extra” classes in a big application. That’s a tough sell right there.

Fortunately, MVVM is easy to do. There’s always someone around to make a good thing harder than it needs to be. Laurent Bugnion’s MVVM Light proves it doesn’t have to be hard. I hope you’ll find – as we have – that you’ll quickly get the hang of it and it’s smooth sailing once you do. Design data and automated testing will rapidly reveal their value.

I have a good feeling about John’s video series. I think it’s going to help you feel good about MVVM.

Appendix: Observation Details

The remainder of this post explores a few of the earlier observations in a bit more detail. Indulge yourself if you will.

Separation of Concerns

Code-behind is code that supports the view. It sits in its own file, apart from the XAML file that determines what the user sees and touches. It’s purpose is to assist the View in presenting data and responding to user gestures. Well that’s the definition of a ViewModel too.

To be sure the view and its code-behind are the same class. In this respect, the visual design and view logic are technically comingled in a clear violation of SoC.  Practical consequences attend. But are they sufficiently compelling? Or can a good developer achieve practical separation with little effort?

Naïve developers tend to crowd the code-behind with logic that doesn’t belong there. I’ve seen people implement data access in code-behind. I’ve done it myself … in quick demos. That’s a bad idea for a real application. But it’s not a better idea when you relocate that code to a ViewModel. Pesistence logic belongs in a service that you make available to the ViewModel … or the code-behind.

The same argument applies to logging, and navigation, and all other cross-cutting, re-usable tasks that should be treated as external dependencies by the ViewModel or code-behind. You either think this way or you don’t.

I considered a detailed discussion of Robert Martin’s SOLID principles as they apply to using or not using a ViewModel. It struck me as an arid exercise. Only “single responsibility” and “dependency inversion” seemed to have practical relevance; there’s not much use for inheritance or interfaces in view design. I’d make the same argument as I did for SoC.

Culturally ViewModel is more aligned with SOLID thinking but, as I said, you can get the practical benefits in code-behind without much effort.

Loose Coupling

The code-behind approach makes it easy to tightly couple the UI elements to the code. That sounds really bad. I think it sounds bad. Then I try to think of all the awful things that will happen to you … and I don’t come up with any; not unless you care about testability which I do. But bear with me. If I didn’t care about testability – if I merely paid it lip service – would tight coupling matter? I’m having a tough time showing how.

It’s not as if the View and the code-behind are living separate lives. How often (outside of tests) would you instantiate one without the other?

Moreover, if I do care about tight coupling, I can easily loosen it in the code-behind approach. Nothing stops me. It’s no harder (or easier) than coupling to a ViewModel.  I can data bind the xaml to the code-behind and use Behaviors to bind to methods and events in the code-behind. All I have to do is set the view’s DataContext to this in the constructor. Done. The choice is mine.

Automated Testing

Testability is MVVM’s sole uncontested and incontrovertible advantage. I can think of no one who argues that it is practical to test logic in the code-behind.

Update: Bill Kempf took up the challenge in a follow-up blog post that shows you can (a) write a code-behind ViewModel and (b) test it. Thus he reminds us that MVVM is a pattern admitting of many implementations ... including, it seems, a code-behind implementation. p.s: Bill was making a point, not a recommendation. Be amused by it but please don't follow it!

ViewModel testability alone should be sufficient reason to adopt MVVM designs. And MVVM proponents dutifully recite MVVM’s testability advantage.

Too bad so few MVVM proponents actually write ViewModel tests. Find me a demo with automated ViewModel tests. Do they even exist? The hypocrisy is mildly amusing.

One possible explanation: demo ViewModels don’t seem worthy of tests. The first ViewModel you write is typically just a bunch of properties. Property tests are low priority because they generally lack decision logic. Testing simple getters and setters is a complete waste of time.

Even a primitive ViewModel gets its model from somewhere, typically a data service. However, in the beginning, the data service is usually a fake that always delivers the goods in a timely fashion. Nothing goes wrong so you let it slide. Later, if you are inclined toward automated testing, you will test the data service independently of the ViewModel.  VM testing can seem a well-intentioned luxury that you never get around to doing.

In fact, in a mature ViewModel there will be plenty to test. The VM is an integration point for asynchronous services and user interactions. Users do weird things and services fail. How does the ViewModel handle service exceptions? How does it handle null results, empty results, one result, multiple results? Does it signal changes to IsBusy at the right times … as when the service fails? Can the VM run offline? What if the user isn’t authenticated? What if the save fails with a concurrency failure? How does the VM respond to tombstoning if this is a Windows Phone application? Does the VM signal view state transitions? Does it wait for view animations to complete and, if so, how do you test the timing? Does the VM send messages? Does it respond to messages? How does it learn which data to show? What if the requested data item doesn’t exist or is invalid?

I don’t anticipate all of these possibilities at the start. Instead I write a few minimal ViewModel tests to put the structure in place. Once I get the hang of it in a new project, this takes a couple of minutes for each new VM. If it takes longer, I count myself blessed because I’ve discovered trouble in my MVVVM triad before the heat is on. I act immediately to get it pointed in the right direction; then I move on. Let me repeat, I make no attempt to test everything. I make sure I have at least one test. Then I add tests for whatever happens to catch my interest.

Over time I’ll trace a number of bugs to the VM. Over time I’ll add capabilities or refactor portions of the VM to helper classes. When I fix those bugs, add new logic, or refactor, the friction of adding supporting tests is low because I’ve established a base line.

This approach works for me. I’m not a testing fanatic. I skip tests even when I know that I shouldn’t. But let me say this: I never regret writing them. I’ve been saved by tests many times and suffered as many times for lack of them. If we work together on a project, we’re going to write tests together. That’s how I roll.

Design time data

John and I believe strongly in the virtue of designing screens with realistic design data that is shaped exactly like the runtime data. We can’t think of any way to satisfy this requirement in the code behind approach. The design tools don’t run the code-behind so the code-behind can’t deliver design time data.

Some folks recommend Blend’s XML sample data, a secondary data source that doesn’t depend upon a ViewModel. That’s a viable way to drive out the first draft of a view. I feel it is a significantly inferior alternative because:

  • You can’t re-use the sample data as fakes for developer, QA, and automated testing.
  • Many data types (e.g., DateTime) are represented as strings in sample data. You don’t bind to a string as you would a DateTime. That means you write two bindings – one for design, one for production – or devise some other hideous workaround.
  • Complex object graphs are trickier to maintain in XML sample data
  • You have to update the sample data structures as your model evolves
  • Sample data files tend to be scattered around your projects, complicating maintenance.
  • It’s tedious at best to keep the sample data out of the production builds.

The first objection is a big one for me. I’ve always got fake data around during development and testing.

Forget about automated testing for the moment. Everyone tests their applications in some fashion. You make a change to a view, you want to see how it looks … now … before you forget what you changed. You want quick turnaround, not a long delay while the application tries to reach the server … which could be down. View development shouldn’t depend on a data service that’s broken or hasn’t been written yet.

It will take effort to create and maintain fake development and test data. I don’t want to do that twice – once for runtime simulations and again – in a completely different format - for view design.

Designer / developer symbiosis

We can’t count this as a huge plus for MVVM. The separation of the XAML and the code behind is pretty good to begin with. It is not like Windows Forms where the changes made on the design surface produced reams of code-behind. The risk of developer/designer cross-contamination is low and reasonable, easy-to-follow work rules reduce it further.

There are no technical obstacles to a designer and developer working on the view simultaneously because the view xaml and code-behind are in separate physical files.

The greater risk is that a designer or developer will introduce breaking changes that aren’t detected until runtime. MVVM is no help here at all. In fact, the risk of conflicting changes is slightly higher due to View/ViewModel separation. Each party works happily in isolation, unaware of the effects on the other. The compiler is no help … as it might be if the designer’s changes happen to corrupt the code. ViewModel automated tests don’t help because, by nature, they don’t consider the view at all. 

On the plus side, ViewModel discipline prohibits references to View components; it even prohibits references to most types in the presentation technology. If you follow that discipline, you free the designer to explore visuals and interaction patterns without worrying about breaking the code. While technically, you can be as rigorous in code-behind, the temptation to be lax is almost irresistible. Accordingly, I count “Designer / developer symbiosis” among the cultural claims to MVVM advantage.

Caliburn

I am a Caliburn fan but I am positioning it as an afterthought in today’s discussion. Caliburn is an UI framework grounded in MVVM. Caliburn automatically wires visual components to code by applying conventions. It can automatically wire a button named “Save” to the “Save” and “CanSave” methods in the ViewModel. The designer doesn’t add behaviors to the XAML; the developer doesn’t write ICommands. There is less manual work for everyone. And Caliburn offers other convention-based time-savers throughout the UI development workflow. Its contributions could weigh heavily in the balance for MVVM.

On the other hand, it’s one more framework to learn and it’s not in the MVVM mainstream. Developers new to MVVM are usually new to the entire XAML platform; they are overwhelmed by foreign concepts and unprepared to shoulder the additional burden of learning Caliburn. Great as it is, the road to Caliburn is bumpier than it could be. We at IdeaBlade are doing our part to smooth that road.