WPF: Is It Time Yet?

For the past few years Microsoft has been pushing WPF as the future user interface framework for .NET. During that time I have seen numerous demos and presentations showing amazing user interfaces. They would describe the new model of separating the designer from the developer, and how successful they were. I would usually ask two questions as a response. First, how many designers and developers were involved. Second, how close to the original time and resource estimate was the actual effort. The answers to this would be one of the main reasons I have not yet embraced WPF.

Before I share the answers to those questions, I want to formally list the criteria I am using to decide on WPF over Win Forms (in priority order).

• Resources needed to develop (question #1)
• Time needed to develop, and the ability to predict this (question #1)
• Third-Party support for the framework
• Performance of the framework
• Tooling available

That list is the litmus test that I apply to switching frameworks. I am not looking for all to be better, but for me, the moment to switch is when the answers for one framework are close enough to demonstrate momentum. My goal, is to ensure that there is critical mass behind a framework before switching. That ensures that the most expensive and critical resource, people, is not used inefficiently.

This list is the result of years of seeing software frameworks come and go. Anyone remember WTL, OWL, Rogue Wave, DCOM, or the myriad database API’s from Microsoft? All of these required significant investment to use, but left the mainstream early enough into their lifespan to be an expensive diversion. Why are they so expensive? Mainstream appeal has a direct impact on the availability of ‘common’ knowledge, and the cost of employees. It is a direct supply & demand curve issue. Not enough supply (knowledge) increases the cost of the available supply to those demanding them. Secondly, with less common knowledge, it becomes harder for teams to accurately predict development times. This means cost overruns are more common (unless you know teams that come in under estimates?).

This brings us to current state of WPF. In the past year Microsoft has definitely ramped up their love for WPF. With the release of Expression, Visual Studio 2008, and .NET 3.5, WPF has definitely received a lot of attention. Tooling support has been growing significantly, and later this year (?) Visual Studio 2010 will have a new WPF designer built in. More importantly, VS2010 will use WPF directly for much of its user interface. The performance and stability of WPF has vastly improved from its first version. Startup times are similar to that of a Win Forms application and performance of some features exceed that of Win Forms. Further, WPF adds functionality that is difficult to achieve in Win Forms. WPF has reached the point at which the number of books on shelves at the bookstore (my own informal study) are exceeding those of Win Forms.

Third-Party support is still a problem though. Many companies that provide Win Forms components have some WPF products released or in production, the number of components available is still dismally short of those available for Win Forms. This is still a sore point and is a significant factor to consider in the move to WPF.

However, the two questions I mentioned in the beginning of this post are, I think, the most critical. First was how many people, and second can the project cost be accurately estimated. Early on in the life of WPF, the demonstrations user interfaces were either trivial or had a number of experts (read as Microsoft or partner WPF experts with significantly more experience than the available developer) and no realistic time constraints. Time estimates were given as ‘we had three months to put something together.’ This is not reflective of the world I live in. The schedules we have, and the resources (people and time) that we can apply to a user interface are more constrained. Time passed, and the answers have definitely changed. At PDC I asked a number of developers using WPF about their process, and the number of people involved was much closer to that of Win Forms. If they had more, they usually had one person more, that was designated as the designer. I was surprised by the number of cases in which they said that projects had less dedicated user interface developers. Instead the companies has created a design group that did the user interface work for multiple projects, and the development teams had one or two developers dedicated to integration. This was an amazing transition, and is definitely a major change in the way we build user interfaces. One of the more public success stories was that of BabySmash. Scott Hanselman describes his efforts to learn WPF in his blog post Introducing BabySmash - A WPF Experiment. At his PDC talk Scott mentions that someone else did the user interface design for part of the application. More importantly, to me at least, was that it was done remote. This means that much of the user interface design can be physically separated from the development effort. In the development world I work in, outsourcing, near-shoring, and a host of other models exist to partition development efforts. Further, it is common to hire design firms to come in design something using mockups or PowerPoint that the development teams need to implement. Now it feasible to farm out the entire process for user interface, with its own acceptance testing process independent of application functionality. For me, BabySmash was the point at which this model Microsoft was promoting hit home.

Of course, reality eventually set in when it came to the second question. This is where the problems started to show. Almost all of the people I asked said that their WPF projects ran far beyond their estimates. The two reasons seemed to be lack of knowledge about specific WPF functionality that they discovered they needed late in the process, and missing third party components. One person described how they had assumed that the common dialogs existed natively for WPF, utilizing the same design model. No such luck. They were forced to use the old style version or build their own. The complaint was that it just looked ‘wrong’ for the application, in that they didn’t utilize the skinning work they had done with the rest of the application. It would have the older Win Forms look, and not the modern WPF look they had spent so much time on. So, these groups chose to build their own. While a single dialog didn’t take too long to build, it added time to the project. When you consider the need to build a few of those dialogs, then the other controls that are not as easily available in WPF, and you have significant cost overruns. You also have a project that is no longer focused on the business needs of the end user, but the plumbing that adds little value to the overall project, yet is still necessary.

Where does this leave us on the question of time for WPF? I would say very close to making the switch to WPF, but not quite there yet. We are at the tipping point between the old and the new, and will probably be in this limbo for the next year. When more third party components start to come out over of the year, and these same companies start shifting their focus primarily to WPF, then we will have crossed over to when WPF is the safe decision. For now, I think we are no longer in the Win Forms is the safe choice mode, but instead are stuck with neither being the safe choice. Choosing Win Forms will yield user interfaces that are dated, unless you invest in them to look more WPF like. Choosing WPF means investing in the plumbing necessary to fill in the functionality gaps left after leaving Win Forms. The choice is tough. Either way, building applications while the community transitions frameworks will be more costly, and require significantly more upfront analysis to identify which way to go for each specific application.