I've been meeting regularly with Bruno Terkaly, Microsoft Dev. Evangelist for Northern California, who has updated his WPF presentations to include discussion of issues I've suggested are important to developers moving to WPF -- but which always seem to be left out or misrepresented in Microsoft presentations and published resources. Bruno has reported getting some "thank-you"s from audience members specifically related to the new material, just as I got "thank-you"s from developers in reaction to my original blog post on the subject.
WPF is a GREAT technology, but developers need open, honest discussion of the pain points they can expect to run into as they make the transition. Examples of less-than-helpful guidance includes the often-repeated advice to simply "hand the project to the designers", while all the developers in the audience are wondering "WHAT designers? We can't even get approval to hire TESTERS!" Xaml is frequently portrayed as low-level tooling support, which can safely be ignored, while failing to mention that Visual Studio lacks design-time support for basic WPF features (DataTemplates, for example), and Expression Blend, which DOES offer support, is promoted as a tool for designers. Any suggestion that developers avoid working directly with Xaml is especially unfortunate, since it takes just a few weeks to become completely comfortable editing Xaml directly, and this approach is MUCH more productive, and leads naturally to better-refactored, more maintainable markup.
After describing similar issues involving other Microsoft technologies, including difficulty in trying to make sense of Microsoft's recently-announced "Azure" cloud computing platform (Bruno says I can take credit for the fact that essential white papers are now grouped together and accessible when you click on the link labelled... er... "White Papers"), I was very kindly invited to attend an informal upcoming get-together of local Microsoft dev. community figures, where I'm hoping to compare notes. I've also managed to finagle a breakfast meeting this weekend with Microsoft's Karl Shifflet, where I'll have the opportunity to discuss these issues directly with the WPF Program Manager. Last night, I attended an excellent presentation on Azure, by David Chappelle, where I mentioned some of these issues, and was surprised to hear him express similar sentiments (confusion over the dual storage systems in Azure, the lame attempt to paint the lack of schema support as a feature instead of the honest -- and more palatable -- reality that ALL cloud vendors are adopting a very similar approach...). He also seemed to agree with my impression that these issues are occuring more frequently, with evidence of development by independent teams (who don't talk to each other)... showing through at the seams.
I've suggested Microsoft could benefit from having internal developer ADVOCATES, focused on identifying and fixing these kinds of issues, rather than just developer "evangelists", who operate more as an extension of Microsoft marketing. Responsibilities for such a team might include...
The idea is a little naiive, of course, and developers already have access to a wide variety of ways in which to report issues, but the current “scattershot” approach, leaving it up to each individual team to report and respond to issues in its own way, may be part of the problem. A small team that served as the developer community voice INSIDE Microsoft, that was explicitly tasked with helping to identify and resolve these issues, regardless of which dev. or documentation group might actually be technically responsible for that particular area… could reduce frustration among Microsoft's target customer base, and probably also reduce the time dev. and marketing team members spend, having to repeat answers to the same questions, from a variety of sources.
I'm really enjoying the opportunity to discuss these issues with knowledgable people in the Windows dev. community, and I'd love to think that something in one of these discussions could trigger real change.