As we start to talk about some more of the details of the Consumer Preview release and some of the changes, or just features we haven't had a chance to blog about yet, we wanted to take a step back and re-introduce the team a bit--a reminder of the people behind the features we talk about. Building Windows 8 is a pretty significant undertaking and involves a team with diverse backgrounds and experiences. We're proud of the fact that the diversity on our own team reflects the diversity of the customers using Windows around the world. Last release, one of the members of the team, Larry Osterman, wrote about working on Windows 7 compared to previous releases. In this post, Larry reflects on the Windows 8 project through two other members of the team.
--Steven
Three years ago, I wrote a post on the Engineering Windows 7 blog about the Windows 7 development process. For this go-round, we thought we’d let you hear from some of the newer members of the team, by doing an informal Q&A session with two members of our Windows Runtime Experience team, both of whom started in Windows just before we started planning Windows 8 (so, Windows 8 is their first experience with developing Windows from start to finish).
Tell me a bit about yourself. Where do you come from and how long have you been at Microsoft?
Chris: Hi, my name is Chris Edmonds. A native Oregonian, I attended school at Oregon State University (Go, Beavers!) and have had internships at NASA and Garmin. During these experiences I worked on projects ranging from robotics to avionics and did research on high speed routing for many-core processors. Microsoft recruited me from Oregon State, and I arrived on the Windows team roughly two and a half years ago.
Mohammad: Hello, My name is Mohammad Almalkawi. I am a software design engineer in the Windows division at Microsoft. I have also been at Microsoft for about two and a half years. I graduated from the University of Illinois at Urbana-Champaign (Go, Illini!) where I was working on fault-tolerance and real-time systems integration research.
What do you work on for Windows 8?
Chris: I started working with the Windows team a few months before Windows 7 was released to manufacturing. Shortly thereafter, I joined the newly created Windows Runtime Experience team. The Runtime Experience team builds many pieces of the Windows Runtime (WinRT) infrastructure. During Windows 8 development I had the opportunity to work across many parts of the WinRT.
In the first milestone (of three), I worked to define core patterns of the WinRT system. We break the project into three milestones and divide the architecture and implementation across these milestones to get us from a whiteboard sketch to a finished product. We have to include all the work it takes to coordinate the different technologies across Windows 8. In first milestone (M1), we designed patterns for events, object construction, asynchronous methods, and method overloading. It was important to define strong patterns for these basic concepts in order to allow each programming language that interoperates with the WinRT to expose these concepts in natural and familiar way for their developers.
In the second milestone, I had the opportunity to build part of our deployment story for Metro style applications. Specifically, I worked on registering Metro style applications with the WinRT so that they can be launched and can interact with contracts.
The third milestone included lots of cross-group collaboration, which I learned is crucial to a project as deep and as broad as Windows 8. I worked with a team to define and implement core pieces of the application model for Metro style applications. This work ensured that Metro style apps written in different languages and on different UI platforms behave in a consistent manner in regards to contracts and application lifetime.
Mohammad: I had the opportunity to participate in Windows 8 since the very beginning. We had three major feature milestones (M1, M2, and M3) to realize the goals of Windows 8. Each of these milestones consisted of:
Specification and design phase to tease out requirements through feature crew meeting and active engagement with partner teams in Windows and across the company. A feature crew is made up of the developers, testers, and program managers who work on a specific feature—usually 4 or 5 people. The outcome of this phase was a set of specification documents—functional (pm), development design (dev), test design and a threat model (test)), as well as an execution plan (all of us). This lets us better understand features details and allows us to execute at high confidence with focused efforts.
Coding phase to implement the features identified in the specification phase along with their unit tests and functional tests.
Integration and stabilization phase to integrate the various pieces from various teams together and to fix bugs.
In the first milestone, I worked on the design and development of the discovery and activation of application extensions. This WinRT infrastructure allows applications to participate in OS-supported contracts (such as search and share) and serves as a basis for exciting Windows features, including the search and share charms.
In the second milestone, I was in charge of implementing the Windows metadata resolution feature, which is a key API that ties the Windows metadata generated by the WinRT tool chain and JavaScript and C# language projections.
And in M3, I was in charge for the design and development of the namespace enumeration API, which enabled the Chakra JavaScript engine to support reflection functionality over WinRT namespaces and types. CLR also uses this API to implement metadata resolution and Visual Studio uses it to support Intellisense for WinRT types.
What’s a normal work day like?
Chris: Normal day? One of the things that I really like about working in Windows is that there is rarely a normal day. Depending on the period of the product cycle, I may spend my day writing specifications, writing code, hashing out ideas with people on my team, fixing bugs, or one of many other activities. Even though the activities are varied, my day almost always involves problem solving in some form. Whether it is figuring out the cause of a crash or helping to design features, I get to work with smart people to solve interesting problems each day.
What has been your biggest surprise?
Chris: I think the biggest thing that surprised me about working in Windows was the size of the team and the number of activities that are going on at any point in time. In working on the few features assigned to me I had the opportunity to interact with hundreds of other people across the team to come up with specifications and solutions. It sounds really hectic (and it was a little overwhelming at first) but it always amazes me how well teams communicate together to come up with some really cool solutions to problems. When I think of the number of people who use Windows and the number of ways Windows is used, I guess it seems incredible that we get all this done with as few people as we do.
Mohammad: The thing that surprised me the most at Microsoft is that you get thrown at real-world problems and you will be given the opportunity to own critical pieces from the very beginning. You learn on the job as opposed to training, which is also available if you need it.
Of course you are not left alone in the dark, as there are lots of support channels, domain experts, and senior engineers who are there to provide help when you need it.
How was Windows 8 different from other projects you’ve worked on?
Chris: Having worked mostly on smaller projects at Oregon State and in my prior internships (most code projects are small compared to Windows), the biggest difference is how much code I read every day. I find that I spend a good portion of time reading and debugging code written by other teams before I came to Microsoft, as well as going over code I wrote myself in a previous milestone. This has really made me appreciate well-written code.
What has been your biggest challenge that you had to solve?
Mohammad: Soon after joining the team, I had to makes fixes in unfamiliar code in COM activation. This code is very infrastructural, as a lot of components in Windows are built on top of it, so it was crucial that my changes would not cause regressions.
This code might have seemed straightforward to experts in my team, but certainly that was not the case for a new guy like me. I had to read a lot of code, step through the debugger, and write lots of test cases to improve my understanding and confidence in making the necessary changes without breaking anything.
Can you tell me something about what it is like to come up with the plans for Windows 8?
Chris: Planning Windows 8 takes different shapes for different people on the team. As a part of the planning effort the newly formed Runtime Experience team took a week to build apps using a variety of languages, stacks, frameworks, and technologies. That’s because a design tenet of Windows 8 is that it can be programmed in multiple languages. Part of the goal of this effort was to force each of us use a language that we were not already familiar with so that we could experience the learning curve. I worked on a 3D terrain generation program using IronPython and XNA, a photo gallery app using HTML\JavaScript, and a simple 2D physics engine in C++ using GDI for drawing. From the app building exercises, we created presentations to give to the team on the experience of building each app, along with a list of the good, bad, and ugly of each experience.
What impressed you?
Mohammad: I was very impressed by the quality of the Windows engineering system that we have in place; it supports thousands of Windows software engineers and keeps millions lines of code in the operating system healthy with nightly builds and quality gate runs. The automated quality gate runs include critical end-to-end tests, performance tests, application compatibility tests, static code analysis and a few other tests that we use to quickly discover problems and to tightly control their propagation across branches via forward and reverse integrations.
What is milestone quality (MQ)?
Chris: This milestone is all about getting the code base, engineering tools, and engineering processes ready for the next product cycle. As I learned, MQ is a time to look across the code and do some housekeeping—from just cleaning up source files, to redoing abstractions that prepared us for the work we would do in Windows 8. Code is our asset so dedicating time to maintaining that asset is pretty important. During MQ of Windows 8 I participated in three different efforts. The first was to create a system that automatically reported back code coverage numbers via an internal dashboard for our team based on our daily test passes. This was one of the first things I worked on at Microsoft, and it gave me a great opportunity to learn about our engineering systems. The second effort that I participated in was a code sanitization practice to help standardize the way we use asserts across the code base. Finally, I worked on a prototype system that would use some pieces of our IntelliSense infrastructure to automatically catalog all parts of our SDK.
What are you focusing on now?
Mohammad: Performance, Performance, and Performance!
The features I owned are close to the bottom of the software stack and used very frequently, so their performance is very critical. Therefore, my focus now is on analyzing performance, and prototyping and integrating various performance improvements. We built things from the start to be high performance, so now we are fine-tuning that performance, given the tons of code that has been written to the infrastructure.
How do you validate the work end-to-end?
Chris: As part of a team dedicated to improving the application developer experience, it is important that we regularly take off our operating system developer hats and don our application developer hats. This is done in small ways in our everyday work, but one of the most structured forms of this are the application building weeks. Based on the initial application building week that took place during planning, we took the time each milestone to develop an application using the WinRT, with different teams focused on different languages and APIs. Writing apps on a platform that is still in development creates some interesting challenges, and these weeks are a fun change of pace. These app building weeks (some of which included more teams) have resulted in numerous bugs being filed, and have caused us to rethink and change some of our API guidance in order to make each developer’s experience more natural and familiar. A “bug” can be anything from a fatal crash, memory leak, or security hole, all the way to a report that “something just doesn’t seem right.” We treat everything like a bug and go through a process of categorizing and prioritizing these reports. The reports come from the groups in Windows building on our APIs, other groups at Microsoft, early partners such as device and PC makers, our interns (as you saw at //build/), and from people in the forums who are building apps now on the Developer Preview.
What is the most important lesson you have learned?
Mohammad: I got to experience the idea that “anything that can go wrong will go wrong” given the size and scale of the product, and the large number of users (by the way, we do dogfood our work internally from the very beginning on our primary dev machines). This taught me that paying attention to details and focusing on quality in every line of code is very important for the overall stability of the product. Of course, that is just one of many important lessons I learned so far—I’m still working my way through my first Windows release and expect to learn a few more things during the upcoming phases of the product.
I can’t wait.
Chris: Me too!!
No comments:
Post a Comment