On Redmond in July
Be warned, this is a long post. But the payoff at the end may well be worth the read.
This past week, I had an opportunity to work on a project at Mothership Redmond. In addition to the fabulous weather (highs in the upper 70s compared to the 100s back home, yet sunny and clear skies, go figure), I had was able to catch up with some people who I don't get to see very often: Amy Babinchak, Steve Banks, Mark Crall, Chris Rue, and Oliver Sommer. And those were only the folks who were on the same work project. I was also able to spend some time with Terri Schmidt, documentation manager for WEBS, and Kevin Beares, a name that should be familiar to everyone in the community. and while I do not want to belittle the time I spent with these folks and the discussions we had, the highlight of the trip for me happened on Friday.
Dean Paron, Group Program Manager for SBS, invited me to sit in on a ship room meeting the team had Friday morning. Since I'm not an idiot, I accepted the invitation without batting an eye, even though I had no idea what a "ship room meeting" was. But after sitting in on the meeting, I have a much deeper understanding of the process the team goes through to develop the product and bring it to market. And after confirming the NDA line, I'm blogging about it to shed some light to others who may be interested.
Anyone who has worked on any type of software development project, whether large and formalized like what MS and other large companies use or smaller and independent, will understand some of the basics of the development cycle. In the case of SBS, the process is a little differnet than for other products, because what the SBS team is developing is the "glue" that will allow all the disparate MS component technologies to run seamlessly on the same box. Oh, and there's the management tools, too. But the development folks on SBS are not writing code for Windows Server 2008 or Exchange Server 2007, instead they are taking those products and writing integration code. In many ways, this is a more challenging process, because to meet your own design goals, you have to deal with the building blocks that have been handed to you. If the team found, for instance, that the User Management tools would work a whole lot better if there were a change made in Windows Server 2008, they're not going to be able to go in and modify code in that product. Sure, they could request accomodations from that team while the product is in development, but once Server 2008 shipped, that was what they have to use to build their code.
Once they get the product matured to the point that they're ready for other people to start using it, they make the code available to certain groups of external users. This comes in the form of CTP (community technology preview) releases and then the beta releases. Generally, these external releases start with a very small group of outsiders, then expands to a larger audience as the product gets closer to release. SBS just announced the release of the RC1 build late this week, and it will be available to beta participants early next week. Many more people will look at RC1 than looked at RC0, or Beta 2, or Beta 1, etc.
The goal, as I understand it, of these releases is twofold. Early in the process, the goal is to get feedback on the functionality of the product as well as identifying any problems (bugs) in the code so that those bugs can be fixed in later releases. Later in the process, the functionality aspects are pretty much set in stone and the team is more interested in finding and fixing the problems instead of adding or removing major elements. That's where we are in the process of SBS at this point - the feedback Microsoft is looking for in RC1 is "what doesn't work" and "how significant of an impact will it have if it's not fixed."
People who participate in the beta process access software and feedback through the Connect site that Microsoft has put together for this process. When someone finds a bug, they are expected to enter that bug into Connect, then it gets on the developers' radar and they can start addressing the issue identified in the bug. But just because you enter a bug does not mean it will get addressed by the team the way you want it to. There are several bugs (and suggestions) that I've entered into the system that have not and will not be addressed by development, at least not in this release of SBS. Am I frustrated about some of them? Sure. But I also know I've identified a couple of bugs that did get fixed, and fixed immediately.
OK, so that's what we see on the outside. When I sat in on the ship room meeting Friday, I got to see what happens on the inside. And I have a better understanding of how and why the process works the way it does.
After Dean introduced me to the team in the meeting (more to confirm that I was under NDA), Cassie Hicks opened the list of outstanding bugs and went through them with the team to determine which bugs would get addressed and have fixes entered into the system before the next build was done, which was scheduled for Friday night. As each bug was introduced, the owner of the bug identified the status of the bug, and if a fix was not imminent, there was a brief discussion about what the next steps of the bug would be. No, I can't discuss any of the bugs that were brought up in the meeting, but it was pretty cool to see the process in motion.
Following the ship room meeting, a pizza party ensued celebrating several teams that had releases that week, including the announcement of SBS 2008 RC1. I was invited to attend with the rest of the team, which was an honor, and got to listen to all of the thank yous to all of the related team members who helped with each of the releases. While everyone ate, I was able to talk a little with Boodhisatva Deb and Sean Daniel, as well as Cassie Hicks. But the icing on the cake, so to speak, was getting to witness Kevin Kean have his head dunked in a large bowl of whipped cream (and yes, you can just make out my face in the background of the video).
All in all, a great week in Redmond, but now it's time to return home and take care of important matters. After I deal with a 4 hour delayed flight, that is...