Developing a Beta at Microsoft

We are currently working on Beta 2 of Windows Workflow Foundation (WF). For details on our release schedule you should read the official corporate information or contact your Microsoft representative. I thought outsiders would be interested in the development process at Microsoft as well as the status of the WF product development.

 

I have to summarize this because so many people fill so many important roles that it is impractical to try to mention them all here in any level of detail.

 

The Windows Workflow Foundation team includes doc, operations, development, test and program management organizations plus release management. The program managers each focus on a vital piece of the software puzzle. They develop plans for and manage the implementation of all the things that go into our product, serving as a liaison with related stakeholders as needed. For example, Technology Adoption Program (TAP) Managers plan how we will engage customers during the development process who wish to build and release solutions that employ WF. These managers work with customers to help them adopt WF, guiding them as they upgrade to our eventual release version of the product and serve as their representatives here in the product group.

 

Beta versions of product are very different from released products, of course. Beta products are intended to help customers evaluate and learn our products and their use is governed by the EULA or other agreements. The process, goals and standards are different than in a final release and you must make sure you understand the implications of Beta software before you use it.

 

So what is the team up to these days?

• Development has accomplished their goals for this Beta, the product is functionally complete and, subject to final testing, we have met the quality, performance, stress and other development goals for this release.
• Operations has branched our code library which allows us to simultaneously prepare one version of code for Beta2 release while continuing to work on the v1 code. Other build activities include code signing and running certain verification tools on the builds. During the time between the branch and release of Beta2, some fixes could be done in both sets of code.
• Our User Experience group has turned in what we expect will be the final Beta 2 user documentation and it is in our build. They are verifying certain tasks while continuing to develop doc for our final release product next year.
• Test has declared that our most recent build meets initial quality standards to declare it as a candidate for release. This opens up the floodgates on a long list of tests and verification by a range of other people who will determine if this build accomplishes the goals that we have set for Beta 2. Test has also started a new automated test pass on this release candidate.
• Localization is verifying that the goals for this release are complete and is managing the localization process. This includes the conversion of visual elements into Japanese and German but eventually may include many other languages.
• Our TAP Managers continue to support our early adopters, including coaching them on the changes from Beta 1.x to Beta2.
• Legal will verify that we have met corporate goals for the release, including such things as the approved EULAs are in the product setup and logged in our internal systems.
• Security is verifying that we have accomplished our product and corporate security goals and is preparing for our final Secure Windows Initiative audit for this release.
• Performance & Stress has made our Beta2 release goals for the product, subject to final test signoff.
• We continue to coordinate progress with our ‘internal partners’ who includes, among others, the Office group, Visual Studio, Longhorn and WinFX.
• Test is completing a series of Release Criteria tasks including verifying the bits are signed, virus checking the build, double checking installation and uninstall, etc.
• Privacy is verifying that we are in compliance with corporate standards for this release.
• Support is verifying that Symbols are on our public symbols server and that our support plan is on schedule.

There are dozens of other things that go into our product. We scan the product checking for undocumented APIs. We scan the product to verify that it does not contain images, symbols or words that fail our “geopolitical” standards. We use tools and techniques to scan the product to make sure the code meets corporate code quality standards.

 

My days are filled principally with managing towards a smooth and on-time release of the product. I lead daily bug ‘triage’ meetings where the project leadership team reviews the outstanding bugs and dev and test report on their progress. I send a lot of email and organize a lot of meetings to follow up on the status of the outstanding project tasks. I am also tracking us against functional and quality requirements from Microsoft products that we are releasing with, such as Office and WinFX and working with the Program Managers who are manage our relationships with these groups. I also lead a weekly project leadership group meeting which is principally focused on project status issues, planning and updates from various team members. Also at these meetings we review other project related issues such as anything impacting our release criteria.

 

So that is a quick snapshot to give you just a taste of what it is like to deliver a Beta product to market at Microsoft. There are a lot of important roles, filled by hard working and smart people all dedicated to producing the best workflow technology possible. I hope that you will take time to research Windows Workflow Foundation, which is a powerful and exciting technology for building workflow enabled applications.