So there is this contradiction that many people have when they first dig into WPF. Let’s take a hypothetical developer. Let’s call the developer Jane. She attends a conference or goes to a user group meeting and gets interested in WPF. She reads the literature and marketing materials and hears a message of productivity and how quickly she can built great looking apps with new UI paradigms. She’s heard this tagline: “all this WPF goodness and it only took X weeks to build!”
So, with this expectation, Jane starts digging in, playing with some samples, doing “hello world” type applications and testing out different features of the platform. The API makes basic sense, although feels a bit foreign. Then, after that initial scratching of the surface, Jane wants to do something more complicated. And as she starts plumbing the SDK or searches for samples on the internet in vain, she feels, well, not so productive. The more she searches through the SDK, the more she realizes how deep WPF is, how many APIs there are, how many levels and layers to unravel and understand. Not to mention the fact that many of the APIs in the SDK are not extensively documented. Cryptic errors, XAML runtime crashes, databinding that doesn’t work, animations that don’t behave: the list of potential pitfalls is numerous. And, at this point, Jane is start to question the touting of productivity of the platform. Was she sold a bill of goods?
Let’s be clear: WPF comes with a curve. I’ve now watched a bunch of developers hit that curve. And the curve is steep. We’re talking between two weeks to two months of curve depending on the developer and the level of experience/intuition the developer has. There will be moments of total mystification and plenty of moments of illumination. It is at once painful and enjoyable, if the developer delights in the discovery of a deep and well thought out UI platform. It is at once familiar and alien. There are many similarities to other UI development paradigms: styles feel like CSS, well sort of. XAML code behind feels like ASP.NET, well sort of. 3D feels like DX or OpenGL, well sort of. Routed events feel like .NET events, well sort of. Dependent properties feel like properties, well sort of. The list could go on. But admidst these (sort of) familiar metaphors there are so many alien concepts that must be mastered: control templating, storyboards, databinding come to mind immediately. It is not a trivial curve and don’t expect to be productive on day 1 or even week 1 or even month 1.
Where the productivity kicks in is after the curve is hit. Once you grok how much power is latent in the platform, how much is done for you, how well thought out the infrastrucutre and platform is, you can really start to fly. I’ve seen this happen again and again: these aha moments. In fact, I continue to have them myself and I’ve been working with WPF for two years! The four partner projects I referenced in my previous blog post also are testaments to this phenomenon. All four of the projects had developers who were at the top of their game in their area of programming expertise, which ranged from DX to Flash to Win32 to Java to .NET. All hit the curve and all then started getting majorly productive once they understood what the platform was doing on their behalf. I have numerous concrete examples of this, which I hope to start sharing as much as I can in future posts.
I’ll be curious to hear if this little mini-essay resonates with the WPF early adopter community out there. Have you hit the curve? Are you hitting the curve? What helped? What hurt? What’s it like hitting the curve? The more we all document the curve, the better. In fact, that’s really one of the central goals of my blog: to faciliate hitting curve and document landmines as best as I can.