We’re in the home stretch after five long years of development. As we close in on the RC1 release of WPF, I figured I should put together a few quick notes on where we stand as of today.
One of the counter-intuitive things about large-scale software development is that the goal at this stage of a development process is not to fix every bug, but rather to bring the product to a known level of quality. There’s a big difference between these two things. Every time you fix a bug, you obviously introduce one or more changes to how the platform operates. Even if those changes fix the bug, they may well also have some other unintended side-effects, even with the most careful layering and architectural design. As a result, products tend to go through a stabilization phase where the number of bugfixes made goes down, and the “bug bar” (the severity of a defect required for a bugfix to be accepted) goes up.
Over the last few months, the WPF team has been gradually raising the bug bar until we’re now pretty much at the stage where the only bugs that we’d accept fixes for are those that would cause a system crash, a loss of data, or some legal or geopolitical issue. In turn, the active bug count has been dropping slowly but steadily – minor bugs that don’t meet the above criteria are still investigated, but are likely postponed for the first maintenance release.
Incidentally, we’re not purely marching to the beat of our own drum in making the decision of when the product is ready to ship. One of the launch criteria is partner sign-off, and right now we’re preparing to start to distribute internal release candidate bits to a small handful of partners who’ve been working on real applications based on this technology for a number of months or even years. We’ll probably distribute a few builds to them, and ask them the question “are there any issues left in the product that would prevent you from being able to ship your own application”. We did a similar process for Visual Studio 2005, and it helped us verify that we were at the level of quality that we thought.
A positive sign of how the churn has dropped is that as we prepare to ship the RC1 release, I’m not aware of a single API breaking change between the July CTP release and RC1 (lots of stability, fit’n’finish and performance fixes though – the last couple of months have made a lot of difference, in my opinion). If you’ve got your application ported to the July CTP bits, you’ll never again be forced to make a change to your source code in order for it to run on the RTM bits of WPF, which I’m sure will be a great source of relief for those of you who’ve experienced the pain of moving code forward from CTP to CTP release until now. Right now, binary compatibility is looking good too – this is all evidence of how things are stabilizing. It’s exciting to see – I think we’re all hungry to ship the product so that you can all get your hands on a final, production-quality release.
Obviously we’re not quite at the same level from a tools perspective – neither the Visual Studio extensions nor Expression Interactive Designer are at a release candidate stage, although they’re coming along quickly behind. However, the SDK documentation is looking in great shape – that team deserves a lot of credit for the way they’ve documented 20,000 APIs while keeping up-to-date with all the breaking changes. Now they’ve got a couple of months to work furiously on some more conceptual material that will help people to grok the platform and beat that infamous learning curve.
In short, there’s never been a better time to start to learn WPF, and RC1 will be a great time to start pushing ahead with anything that you’ve been saving until more stable bits are ready. There are several hundred customers and partners that are already mid-development with some great WPF applications, and I’m really excited to see what happens as WPF starts to truly hit the mainstream for .NET developers.