The Power of the Sticky

One of the nice things about working at Microsoft is the cool speakers that come to visit. I remember a few years ago when a 12 year old prodigy (I don't remember his name) visited Microsoft to discuss his vision of the tech world and where it was going. After a 1 hour lecture, with slides and a small tailored suit, he opened up the floor to questions and answers. With around 100 Microsoft employees attending, there were lots of questions. He had interesting answers all around. His youthful ambivalence to difficult technical challenges was refreshing. Someone asked a question, and I don't remember what it was, but I'll never forget his answer, or at least the beginning of it: "Well, I'm a technologist, so I try to solve every problem with technology..." That introspective understanding of how he attacked problems was very insightful. I began to wonder if I was the same way. Certainly, since that discussion I've noticed my tendency to solve everything with technology, but as I get more experience working with different teams I am more and more persuaded, that technology is the least of our challenges. All around us are routines and tools that everyday people use to solve everyday problems, most of which are not technological solutions. Preeminent among these today are 3M's humble product the Sticky. People use these so consistently that I am now persuaded that for all of America's economy to collapse, we need only see 3M stop production of the humble sticky. ;) There are plenty of solutions to be had and lots of simple problems to be solved, but not all need to, or should be solved with technology. The problem I am now faced with is, how do you distinguish between the two?

Old Mac Lab Macs

There have been a lot of comments and questions about what happens to our old Mac Lab Macs. My comment about them being recycled left too much to the imagination. :-) For example, Drew Merkle left this comment on my Tour of Microsoft's Mac Lab post:

Please, please, tell us that when you write "recycled" you really mean someone took the antiques home or gave them to a collector or a museum. Even to those who are not the biggest fans of Microsoft this stuff is true history. Sadly, those close to it don't always understand it as such. An "original" Mac (whether it be a 128K Mac or a Mac XL) once owned by Microsoft would be very valuable indeed. The birth of Excel 1.0, not to mention its predecessor, Microsoft's first GUI spreadsheet known as Multiplan, quite a significant milestone in human history if only because of the number of lives eventually touched. Oh, please, please say those antiques didn't actually get recycled... That would be really bad Karma. Could have even auctioned them off for the Bill and Melinda Gates foundation. There must be a lot of readers out there just shuddering to think of the tragic waste.

When I found out they were headed for the trash I felt exactly the same way. So here's what we did: 1. We gave as many as we could to Microsoft's Museum but they didn't need or want every single one we had so... 2. We found loving homes for a bunch of the Macs with Microsoft employees who love Macs, some inside MacBU, others not. 3. We somehow found more storage space for the rest :) Fun Fact: At Mac World 2004 we had a special Microsoft Mac timeline at the booth with a few of the old Macs, all of which came from our Mac Nursery and Sandbox areas. So Drew Merkle the Macs are okay. :)

The High DPI Transition

I suppose I'm pretty slow realizing this, but in reading Dave Hyatt's post "High DPI Web Sites" and then John Siracusa's excellent post "Declaration of resolution-independence" I finally realized what all this means for developers: one more expensive transition and lots of work for great graphic artists. Typically when you purchase your graphics you buy them at a given resolution. For an app icon you currently only have to purchase: 1 app icon at 16 x 16 pixels 1 app icon at 32 x 32 pixels 1 app icon at 48 x 48 pixels 1 app icon at 128 x 128 pixels Or for each toolbar icon you'll need: 1 toolbar icon at 32 x 32 pixels (NSToolbarSizeModeRegular) 1 toolbar icon at 24 x 24 pixels (NSToolbarSizeModeSmall) For each document icon you'll need: 1 app icon at 16 x 16 pixels 1 app icon at 32 x 32 pixels 1 app icon at 48 x 48 pixels 1 app icon at 128 x 128 pixels Now according to this document, "Icon Services in Tiger has been extended to support icons that are 256 x 256 pixel in size" so we really should add 1 more app icon size and 1 more doc icon size, but let's just say we're on a budget. The point is with icon design you typically pay per pixel size. To make you application look good on a high resolution screens you'll need to re-purchase either higher resolution versions of your icons, or purchase the full PDF or PSD versions which cost a LOT more than say the 32 x 32 version of the same graphic. For icon designers this could be quite the wind fall. :-) Just for fun: For those of you who don't have Quartz Debug installed here are some interesting screenshots taken from my MacBook Pro with Tiger 10.4.6 at different resolutions:

36 DPI 72 DPI (Normal) 144 DPI 216 DPI As you can see, the text scales just fine, the graphics on the other hand, well, they could use some work. It would really be interesting to know if Apple considers 3x (or 216 DPI) the upper limit for high resolution displays.

Mac Lab: Questions and Answers

Wow. There are quite a few comments and email feedback on my last post and some great questions too. Let me try to answer some of them. First and foremost... Question: What does it sound like when you reboot all those Macs at the same time? Answer: Very cool. It's the most interesting BONG you've ever heard. Each of the Macs boot just a bit ahead or behind the other, sort of in waves, so the bong keeps going for quite some time. At one point, I had "Victoria" speaking text when ever failures occurred in the OS restore process. When something bad happened you'd hear her speak the error message in the same kind of way. It was cool, but it totally freaked out people in the Sandbox area, so I removed it. :-) Question: Are you going to be fired? Answer: This question was actually from my Mom. Yesterday I was actually home sick in bed and the phone rings and it's my Mom telling me I'm on the front page of digg.com or something like that. (I was a little groggy) Any how, she was reading through the comments on digg and wanted to know! So, for my Mom and everyone else, I'm typing this response in my humble office at Microsoft on my MacBook Pro, so, no, I am not going to be fired. Question: Can we see a video or of the Mac Lab? Answer: Actually, you can see some video, but you need to sift through a movie I posted earlier. Question: Why is it that your system scales better with machines rather than CPU horsepower? Answer: This is a great question and I think a very interesting discussion. I'll try to answer this in another post. Question: This is the Redmond Mac Lab, but what about the California Lab? Answer: The part of MacBU that works in California indeed has a nice lab too. In fact we got the idea for the plasma display and training area from their lab! They had a projector setup and desks so people could see. We basically cut our racks in half to get the same effect. The Redmond Mac Lab is a bit bigger, but not by much. Question: How long does it take to build Office with Xcode? Answer: Good question. Honestly, I don't know. Maybe later on I'll be able to post about that. :) Comment: "these tapes work just great, except when they don't." They always fail when you need them most.. You guys should get a SAN and dump your backups on there. Response: We actually recovered 95% of the data from a huge RAID server we had setup before the failure, so we were okay mostly. Apple XSAN stuff looks pretty cool. We might move to something like this in the future. Question: Can you recommend a good training facility in Ontario Canada? Answer: No, sorry. If you really want to learn about the Mac, I'd suggest getting one and reading what's online. There's lots of great stuff on the web. Questions: "So I have three questions...1) what is your electricity bill for all those Macs ;) 2) do you have any insider info on when MS going to release a universal binary for Office and 3) do you do have any Powerbooks, iBooks or Macbooks in the lab?" Answers: 1) Our electricity consumption is classified. Sorry. ;) 2) We ship Office every 2 to 3 years. I'll let you calculate when we ship next. We've publicly said our next version will be Universal. 3) We have plenty of Mac laptops. They are hard to see in the photos I posted, but they are there. The day I took the photos I had moved them aside to setup a server scenario, so you don't see them, but we've got 'em all. Question: So what do you guys actually use to "drive" the automated tests of Microsoft office. Applescript? Or something home-grown? Answer: Great question. This is a big part of what my team in particular does. This question deserves its own post. Stay tuned. Question: I remember a story a while back about this being the one place where iPod usage isn't frowned upon at Redmond. Answer: Actually, we all got iPods as "ship gifts" when we shipped Office 2004. I personally believe MacBU was responsible for the whole, "Everyone at Microsoft has an iPod" story way back. Question: How can I become a Mac Office beta tester? Answer: This is asked enough I think I'll answer this in a post. Question: Where else have the Mac BU staff worked? Are most of them career 'softies or have many of them come to the MacBU from other companies? If so, where else did they work? Answer: That's kind of a private thing to be sharing about others. Sorry, no answer on this one. Comment: I notice you don't have an Apple ][ integer machine like the one I have. For a year and a half, from August '77 til January '79 the only way to load or store data was an audio cassette tape. If you wanted to do decimal numbers you had to buy a floating point card. Response: Good point. We don't do much testing on the Apple ][ Comment: I think you could do with some PowerBooks/MBPs in your setup. as well as iPods :-) Response: We make a point to purchase every major hardware revision Apple releases. When the iPod was announced, we actually got one for the Mac Lab! We said we needed it for File/Save testing. ;-) Question: I am also quite interested in the general results of the testing. For example, do any/most issues you find just effect a certain version/language of OS X, or the issues are common across the lots of versions etc? (ie is the "test under every version of OS X" strategy uncover many issues, or just a couple here and there?) Have you had any cases where you have changed your testing methodology due to issues that _didn't_ get picked up? Answer: I'll try to answer this in a later post. Great questions. Question: Have you considered using NetBoot instead of bringing the OS down onto the computer? Answer: Yes. In fact when we got the Mac OS Dev Preview 1, I had 21 Blue and White G3s booting from one of the server boxes. Since then we've been monitoring this very closely. When we do the cached local restore on average it takes about 15 minutes to switch OS builds, and there's very little network traffic since the .dmg is cached locally. If anyone has got NetBoot or NetInstall working on this scale with this kind of performance, please email me. I'd love to chat. Comment: "Man, if you guys are every hiring let me know. I wish I could hangup my job as a system engineer doing mostly all pc networks. I am mac addict to the core. And I have to say, you have an awesome job. I am jealous." Response: We are always looks for brilliant Mac folk. http://www.microsoft.com/jobs is the place for you to start. Question: Paraphrased, "I'm 13 and I'd like to do an internship at MacBU. Can I?" Answer: I think there are some child labor laws that we might have to work around here. I suppose it doesn't hurt to try. Check out http://www.microsoft.com/jobs Question: Why are you using blogger? Answer: A couple of reasons: When I started the blog, I wanted to be able to include pictures. Back then the MSDN blogs didn't support pictures. I also wanted something that was easy, simple and free. On a more personal note, I liked the way the blogger sites look in Safari. The other sites don't always looks so hot in Safari. Question: Why doesn't X do Y? When are you ever going to fix Z? Answer: For some deeper discussion on how to request bug fixes or feature improvements please check out: Matt Linderman - Useless, absurd, must, need, appalled, just, infuriating, essential, etc. Brent Simmons - How to manipulate me Rogue Amoeba - Pistols At Dawn or How Not To Request A Feature I'd add that if you want Apple to change something in their products, you should visit: http://www.apple.com/feedback/ If you want to give feedback to MacBU there is a great place to do that as well: http://www.microsoft.com/mac/default.aspx?pid=feedback Question: Have you ever considered using Xgrid with your system? Answer: Yes we have. In fact, last summer the intern on our team and I looked into this. We still might use it, but a big part of automated testing isn't so much the "distribution problem" that Xgrid solves as it is the "state management" of the machines. Something more like what Apple Remote Desktop does might be more interesting. We haven't totally thrown out the Xgrid option, but right now we've got a working system and lots of testing to do every day. On the fun side of things, we actually had SETI@home running on all the machines while they were idle, which was fun to watch, as well as good for one of our team members SETI rank. ;-)

A Tour of Microsoft's Mac Lab

Today I'll stop my 3rd person perspective. I'm going to write a little bit more about what I do to help MacBU ship great software and provide some color around what's it's like to work on Mac software at Microsoft. Often when we have press events or special visits from our MVPs I'll give them a tour of the Mac Lab and explain what we do. They've always found it very interesting and so I thought I'd share a virtual tour of our Mac Lab. Let's get started:

Lab Door

We start with the door. The Mac Lab is about 2000 square feet of solid computers. The calendars you see down the side of the wall we use to mark team birthdays as well as special events. The CD on the door is an old Apple Software Restore CD from the last beige Mac Apple produced, the Power Macintosh G3.

The "Sandbox" and Plasma display

The first area in the Mac Lab is what we call the Sandbox. This is where we keep all significant hardware configurations Apple has released that run our products. We'll use the Plasma display to, watch DVDs and play games, uh er, I mean, do important training presentations. ;-) It's actually very useful because everyone can be in front of a computer and still see the main screen and follow along. Often other groups at Microsoft (the games group, hardware drivers group and even the Windows media group) will come and schedule time in the Mac Lab to test their software on the different hardware configurations.

Old iMacs and iBooks in the distance

More Macs

We have lots of Apple hardware. You can see here the old colorful iMacs along with some of the old iBooks. You can also see two of our Lab Technicians working on the backup systems, but more about that later. Up until a few months ago we had every significant hardware revision Apple has ever released since the dawn of time. We even had a section of the Lab we affectionately called the "Mac Nursery" where we kept all the older Macs going. We even had an old SE/30 and IIci and super expensive Mac II all connected via PhoneNet running Spectre, just for fun. It's always super fun to boot Word 1.0 or Excel 1.0 on these old machines and see how much things have changed. Due to lack of space in the Lab we had to put all of these older machines into storage and recycled the following:

• Macintosh (original)
• Macintosh SE
• Macintosh SE/30
• Macintosh Classic
• Macintosh Centris 610 <-- I had this one in my room during high school
• Macintosh IIci
• Macintosh IIsi
• Power Macintosh 7100/66
• Power Macintosh 7100/80
• Power Macintosh 7500/100
• Quadra 650
• Power Macintosh G3
• Duo Dock with Powerbook Duo 2300c
• Power Computing PowerCenter Pro 210

May they rest in peace.

ADIC Backup Robots

One of the realities of working with computers is that things fail. More often then you might think. We've used different backup robots, but ever since we moved to ADIC we've never had a robot failure. They just make great stuff. We have 3 robots and use Veritas Backup Exec. It works pretty well, as you can see:

Lots of backup tapes

We also do offsite backups just incase "The Big One" hits, but for regular use these tapes work just great, except when they don't. Recently we had a failure and lost 400 GB of data! We restored it from the tapes and then discovered that the Mac version of the Backup Exec agent had a corruption bug causing the restores to be compromised! Veritas folk were super responsive and they should have a new Mac agent out soon. Backup software and file systems are in the class of software that simply must work, all the time. Alas, this is not always the case.

I'm going to skip the "Build Lab" section of our Lab since it's very much in transition. Maybe I'll post about that later. For now, on to our automation system!

Mac Office is one of those "software in the large" projects. There's really no way a team of our size would be able to adequately test all of Office without the use of automated testing. Every day we get a new build of Office from the build machines, we copy it to our Xserve RAID connected to our dual G5 Xserve for access by our 249 automation machines. We then run thousands and thousands of tests on the new build. Typically we get 4 builds of Office each day: English Ship, English Debug, Japanese Ship and Japanese Debug. We run our entire battery of tests against all the builds and then report any failures to testers via email. The testers investigate the failures, log any bugs and then move on to their other duties as testers. This turns out to be very effective, if used properly, and over time it allows testers to focus on things humans do best, while letting computers verify the repetitious and mundane, but necessary, testing. It all started with our Blue and White G3s years ago. At first when testers would upgrade their test machines, instead of recycling the machines, "The Lab" would get them to add them to our automation machine pool. I think we had about 20 machines to begin with.

Venerable Old Bluies

After some time we started getting Gray G4s...

Speedy G4s

Then we upgraded to some dual proc machines...

Dual G5s

Then Apple give us a special gift. :-) You'd be probably be very surprised at the cost of running all these machines. There's the obvious electricity costs, but also cooling costs and even the physical space costs. Additionally, our system scales, not with CPU horsepower, but with quantity of machines. Most of the tests we run don't run significantly faster on a dual G5 vs. a single G4. So when Apple announced the Mac mini it wasn't minutes before we were considering how to use it for our automation system. The Mac mini has all the perfect qualifications:

1. Low power
2. Low heat
3. Small
4. Easy to pack together
5. Inexpensive

So we got a few to test things out...

Mixed Automation Rack

And then we made the big purchase:

Rack A, B and C = 150 Mac minis!

These work extraordinarily well. You might wonder how we control all these Macs. We use two methods: KVM switch box and Apple Remote Desktop. Thanks to our Lab Manager's great relationship with the IOGear folk we have a very reliable solution these days. It seemed like it took for ever to find a USB KVM switch box that didn't leave the machines "headless" after random reboots. The 8 port USB KVM from IOGear has been rock solid. So what does it look like to sit in front of 64 Mac minis? Like this:

64 Mac minis: 1 keyboard, monitor and mouse

This works very well when you must access the machines physically. Even so, just scanning each Mac for 1 second gets very old, very fast and Apple Remote Desktop comes to the rescue! When we need to see all the machines at once we just select them and BOOM! they're there. It also gives us what I believe is the one true reason Apple invented the 30 inch Display. ;-)

The 30 Inch Display: Fulfilling the measure of its creation.

ARD displays 50 machines at a time and when you have a capable machine, it uses the "cube rotation" effect to move from one group of 50 to the next. I got a picture of the effect mid rotation below:

Rotates like butter!

So how does it all work? Like this: On each machine we have two volumes: ChangeOS and Mac OS X. The Mac OS X volume is where we install the different versions of the OS. We boot to the ChangeOS volume to free up the Mac OS X volume for modification. When we trigger an automation run we specify the OS version and language. Each machine then reboots to the ChangeOS partition, caches the OS .dmg locally and uses the asr command line tool to restore the image. The tool that does this work is one I wrote (in AppleScript Studio no less!) called Lab Assistant. We have images of the Mac OS from 8.1 all the way up to 10.4.6 in all the languages our products support. It's a lot of data which brings me to the backbone of our automation system:

Our Xserve RAID and XSAN

1 TB

Right now we've just been testing out the XSAN stuff to see how we want to use it. That's why you see all the Xserves. Just one side of the top Xserve RAID is 1 TB of data. For a fun comparison this whole rack which is about 7 ft tall is full of old RAID arrays is also 1 TB of data storage. We call it the Big Mac Daddy.

Big Mac Daddy

Other groups at Microsoft have hardware retention policies that force hardware upgrades every so often, but instead of just "recycling" these server machines, our Lab Manager intercepts them on the way out, and we use them for various things, storage, SQL server etc. We actually have some of the old MSN servers in our Mac Lab!

Hallways

When you have so many machines to maintain, being able to get behind the machines is very important.

Lots o' cables!

Top View

We like to pack in those Mac minis and the cords get pretty dense when we do. The hanging Mac mini box moves if the HVAC is working. If it's not working, we've got to turn off the machines until it's fixed.

Our main automation Xserve has a habit of failing in some serious way once a year, always around Christmas time. :/ For the last 2 years I've been in charge of fixing it and getting it back to operational. Most of our server racks are generic white enclosures, but we do have 1 black Dell rack. As punishment for bad behavior, we put the Xserve in the Dell rack. That'll teach it. ;-) This is what it looks like from the inside of the rack looking out on the world. Poor caged servers...

From the server's perspective

Of course our iWork/iLife balance is just fine as you can see by the following:

Tornado Foosball Table

One of our team members bought this awesome Tornado foosball table which we use along with and XBox and XBox 360 to relax after a hard days work.

Published!

A while back the Seattle PI actually did a front page story on the Mac Business Unit and you can see from the picture in the Lab it was when we had only the G3s.

Gotta have the Mission Statement

As you enter the kitchen we have our MacBU mission statement to remind us what it's all about. :)

Free drinks of course!

Just like everywhere at Microsoft, we get all-you-can-drink beverages.

Fun Times!

Part of our team mantra is that we work hard, and play hard. So we do lots of fun morale events. We just take time off work and do stuff. We're good friends and enjoy "just hanging out" together.

The Mac Library

This is just a pretty picture to represent what is really a much bigger collection of 3rd Party software we use to test with Office. Most if it is stored on file servers, but this gives you an idea. (There's some old WWDC DVDs if you can find them!)

Printer Lab

More Printers

All connected for printer testing

They're beautiful

A big part of Office functionality is printing, and we do loads of print testing. We work really closely with the printer vendors and make sure the printed page looks great. WYSIWYG is fundamental to Mac ethos. All these printers are connected via USB hubs and Ethernet to a Mac OS X Server 10.4 which is the printer server.

I hope that gives you a better idea about what the Mac Lab is like and what it's like to work in the Macintosh Business Unit at Microsoft.

Mac OS X Debugging Magic

I'm sure there's lots of folks out there who know all about this, but I didn't, so I thought I'd share. When trying to debug a nasty issue sometimes you've got to get creative and even employ some "magic" to help get to the root of the problem and that is exactly what Tech Note 2124 is all about. As Apple puts it:

This technote describes a number of 'secret' debugging facilities in Mac OS X, including environment variables, preferences, routines callable from GDB, special files, and so on. If you're developing for Mac OS X, you should look through this list to see if you're missing out on something that will make your life easier.

Thanks to Jesse for sending me this gem.

Office 2004 Benchmarks in Rosetta

MacTech has a very interesting benchmarking article on how well Office 2004 performs in Rosetta. Check it out here. One of my jobs here at work is to build and maintain the automated performance test we run on Office. We worked with Apple to make sure Rosetta worked well with Office 2004 and Apple did a great job. I am continually amazing at what a high performance machine the Intel iMac has turned out to be. Even with the faster hard drive in the iMac, I'm amazed at how much better it performs then a MacBook Pro. Apple hasn't released the detailed specs on the MacBook Pro yet, so I'm still a little bit stumped by the difference.

Program Managers at MacBU

I think regular, non-tech people have a fairly good, if rudementary, understanding about what a software tester or software developer does at Microsoft. These positions kind of fit some generally well known stereo types. One position that is easily forgotten is the program manager position. Steven Sinofsky has writen about what it means to be a program manager at Microsoft before, but in the Mac group, I think it's different still. In the MacBU things act and feel a lot like a small business even though we are part of Microsoft. I don't know if this is unique to MacBU, but I like it. It's easy to get things going and change can happen rapidly and often does. This is a Good Thing. My disclaimer is that I'm not a program manager, so what follows are my observations from my view as I've watched things work in our business unit. So here goes: A large part of the program manager position is helping to design things. PM's design new features and make changes to how our products will work. It makes sense then, that Don Norman would have what I think is one of the best descriptions about what being a program manger in MacBU is all about.

Designing a product requires many skills, and it is the rare individual who has them all. Design is, therefore, an exercise in teamwork, where each team member brings in a different mix of skills, attitudes, and values. Alas, quite often, members think their own set of attributes is the most important. Thinking that one’s own discipline is the most important of all gets in the way of teamwork. It creates bigotry, which in our field of usability and interaction design means usability or interaction bigots. I have long worried that in preaching the merits of usability and interaction design, we have lost sight of the goal. For customers, it is to provide pleasure and accomplishment, letting them fulfill their needs both effortlessly and pleasantly. For purchasers, the product must be affordable and return value commensurate with the cost. For the company, the product must be profitable: people must buy it in sufficient numbers without requiring expensive service calls. And there must be a continuing revenue stream so that employees can remain paid and future profitability assured. Whose profession is this? Nobody’s, at least in the sense that it belongs to any single group. Everybody’s, at least in the sense that we all have to come together to ensure that products are successful from everyone’s point of view. This means that there may be usability flaws, technology glitches, appearance issues, and marketing fumbles. But so what? We must look at the larger picture and ask, does each flaw really matter? And so everyone must pitch in, everyone must make compromises and tradeoffs, and everyone must put their profession second and the interests of the company and customer first. In October 2004, Rashmi Sinha and Richard Anderson organized a symposium on this topic (“User Experience: Why do so many organizations believe they own it?”) for the San Francisco Bay Area Designing for User Experience Society (BayDUX). During the question period, an audience member asked me “Who should be in charge of the product,” clearly expecting me to say “the user experience team” (because it's all about UE, isn’t it?). My answer was disappointing to her and many others in the audience. I said that everyone was in charge – marketing, sales, manufacturing, engineering, industrial design, communication design, graphics design, and, yes, user experience design. Mainly, the person in charge is the product manager. If the product manager can’t resolve the issues, then it becomes a business decision. Business decisions are for managers and executives to decide. (Disclaimer: I was once one of those executives.) When there are conflicts, we need to step back and ask what the total impact is upon the customer and the company: How serious are the problems? Does the product give pleasure. Will people recommend it to others? If, for example, form gets in the way of function, does the enhanced appearance help sales more than the impact on function hurts? The decision needs to be based upon what is best for the company and the customer: hopefully, these two coincide. So, the person in charge is the product manager first, managers and executives second. “Product manager?” was the puzzled response? “But, then,” came the follow-up question, “what discipline should the product manager come from?” My answer: “Who cares?” I have seen excellent product managers who were trained in English history, or engineering, or psychology, or Chinese calligraphy. What matters is that this person can pull the team together, can balance the talents of the teams and the needs and requirements of the customers, the company, the sales and marketing teams, the manufacturing and packaging teams, and all those big, powerful egos (as well as the brilliant, but quiet and insecure). Talented product managers make this all work in harmony. I am always awed by their skills. They are – and must be -- generalists, people who can see the big picture. What discipline should they represent? None of them; All of them. Whose profession is this, anyway? Nobody’s and everybody’s. We are all in it together, we all need one another.

As I've observed it, this PM position is so often the unsung hero of a product that delights the customer. Our users really don't know all the constraints that go into making a piece of software, but I guess that's the beauty of it. They don't need to know the complexities. Good design is the essence of building Mac software and I love it.

MacWorld 2006

I’ve been at MacWorld for Microsoft on and off since I was 18, and this was the best booth we’ve ever had. The openness allowed for lots of customers to be there. The in-facing booths really protected the 1:1 conversations from noise contamination and made working the booth stations much easier on the voice. Not having the “dual screens” at each booth helped because folks walking through don’t think you're doing some kind of demo and you can really focus on individual questions. The color coordinated shirts and banners looked cool, but actually really helped when someone had a question you couldn’t answer, you would just point to the banner and say, “See that purple banner? Over there will be someone with a shirt like mine but colored purple, they will be able to answer your question.” You didn't need to leave the booth to escort them to the person or try to point to the person in a crowd. Just very functional. Having the MVPs at the booth was brilliant. They know so much about the software and are really great with the customers. Not having the theater projector “back project” saves so much space which means the booth can accommodate more customers. Not having fold up chairs that are hard to navigate and fall over. I could go on. It was just a really good booth. Looked sharp, but more importantly, very functional. One part of the booth that was special this year was that the pictures of people using Office and VPC were not just pretty stock art. In our market studies we came upon some great stories of people using our products and we asked if we could make a video of them talking about what they do and how they do it. We showed this video between demo sessions in the main theater, but if you weren't able to go to MacWorld this year, I got a copy that you can watch here. As a developer on a big project, you don't always get to interact first hand with customers. I’m so glad we send so many of the front line team to MacWorld to work at the booth. Developers, testers and program managers all get their turn to work on the show floor, and while it’s hard work, I always come away invigorated to help make the product better. It’s especially nice to talk to people for whom the product is just transparently part of their life. Yes! That’s how it’s supposed to be! Tuesday night we had a Inside MacBU Press Event. I think the press folks I talked to actually enjoyed hearing about how we build and test our Mac software. What's more, each of the customers who were in the video were there in person as well. I talked to each of them for a bit and for me it was cool to see that they were just totally genuine in their excitement for the software we build. There's nothing quite as motivating as an enthused customer!

ExCodeWarrior

When we first heard about the switch to Intel and the corresponding requirement of also switching to Xcode someone came up with the great idea of the shirt above. The idea being that once a team has their application working in Xcode they get the shirt. Since the internal tools I write are infinitely less complex and almost completely written in Cocoa, our team got the shirts first. :) I've mentioned this before, but for Office, this transition has got to have been the biggest we've ever done. 1. New compiler: CodeWarrior to GCC 4.0 2. New IDE: CodeWarrior to Xcode 3. New additional chipset: PowerPC and Intel 4. New executable file format: PEF binaries to Mach-O 5. New XML based file format for Word, Excel and PowerPoint All this AND all the super cool features of Office 12! The Office X product release was nothing compared to this product cycle. It just takes a special kind of developer to tackle all this change for a project as big as Office. Eric Lippert makes a very astute post on what it's like to work on a big project which I'll quote:

Q: What do rocket scientists say when they want to describe a portion of their work as easy? A: "This bit isn't exactly brain surgery." I think that pretty much everyone would agree that rocket science and brain surgery are both intellectually demanding pursuits. But it seems to me that there's a fundamental qualitative difference between them. Rockets are devices constructed by humans for specific purposes. Though there may be considerable systemic interactions between all the parts of a rocket which must work harmoniously together, those interactions are the result of careful design. The rocket as a whole can be decomposed into its original parts, and those parts can be independently tested to see if they meet their design criteria. Furthermore, the aim of rocket science is usually to deliver a specific payload to a specific place at a specific time. Though it is no mean feat to get to the moon, we can least for all practical purposes calculate the future position of the moon at any time you care to name to any degree of precision. And yes, it's hard, and yes, mistakes are made, sometimes with tragic consequences. But fundamentally, rocket science is about shaping raw matter into precise forms to achieve precise tasks. Brain surgery isn't nearly so much like that. We're presented with a lump of thinking, dreaming meat that we barely understand how it works and is presently being used to solve all manner of problems that evolution did not design it for. Our understanding of brains is strongest at the very low level – the neurochemical level – and at the very high level – the gross divisions of the brain into the centers that control particular muscles, responses, etc. But we have practically no understanding whatsoever of any level between those – we are no where close to understanding what algorithms the brain uses to recognize faces or write music. And a working, living brain has trillions of interacting parts which were not designed with orthogonality or functional decomposition in mind. I've been thinking about the difference between brain surgery and rocket science lately in the context of my coworker Peter Hallam's essay on the difference between writing new code and modifying old code. Naively, one would think that adding new features to code would be like rocket science. You understand all the parts, you figure out how to redesign the parts to admit the new desired behaviour, you implement it, test it, and you're done. It's an intellectual challenge, but it's fundamentally amenable to analysis because every part has a clear, well-designed function that can be tested independently. But as Peter points out, anyone who has actually tried to add major new functionality to existing code knows that most of the time its more like brain surgery. We know what the code does on a gross level. (Say, tokenize source, parse, create symbol tables, bind type annotations, check reachability, generate code.) We know what any part of it does on the microscopic level. (Say, move the contents of this register to that memory location.) The hard part is understanding what the algorithms are that make up the large-scale behaviour, and understanding how to tweak them to admit the new desired behaviour without breaking anything. (How does tweaking early nullable realization during binding affect rewriting lambdas into expression trees? Who knows? Not me, that's for sure!) Understanding all that stuff is the incredibly hard part; actually putting the code under the knife is comparatively trivial. A big part of good implementation of software-in-the-large is making sure that the program is more like a rocket than a brain. Coming up with tools to enable that admirable goal is the hard part.

I'm a bit of a 3rd party observer of all the work our developers are doing to get Office through this transition from my perspective I am very impressed. There's a lot of brain surgery and rocket science going on. It's amazing to watch.

Ariel Motor Car

What happens when you remove everything from a car that doesn't contribute to driving performance? You produce my new dream car. Thanks to Brammo Motorsports and Ariel Motor Company for reminding me what can be done with just 7 employees focused like a laser on a single goal: driving performance. What did they name it? The Atom. What a great name. Check it out. Link

Best Boot Camp Posts

Of all the blog posts on Boot Camp these two are must reads: 1. Cabel Sasser co-founder of Panic 2. John Gruber at Daring Fireball Together they pretty much sum it all up.

Boot Camp Partitioning

So Apple's Boot Camp Assistant beta software announced today allows any Intel based Mac dual boot with Windows XP SP2. Very cool. They've even announced that this capability will be a part of Mac OS X 10.5 Leopard. Some things to note: 1. If you already have multiple drive partitions, the Boot Camp Assistant will fail. It requires a single Mac OS X Extended (Journaled) partition. 2. You may have to wipe your drive. I have 15 GB free on my MacBook, but when the dynamic partitioner tried to clear 10 GB for use as the Windows boot volume I get this error: I guess I'll just have to wait until I can wipe my machine. I thought this might have been because my iDisk was mounted, but that wasn't it. I'm guessing the partitioner needs contiguous drive space and while I might have had 15 GB free, it wasn't free in the correct locations. Bummer.

Got Feedback for MacBU?

We've just released a new feedback tool on our web site that allows customers to provide direct feedback our team. You can select "Send Feedback" from the "Help" menu in any of our applications or directly visit the MacBU feedback form located at http://www.microsoft.com/mac/default.aspx?pid=feedback Everything is anonymous, just select your application, version and language and send it our way. It's immediately posted for all the team to see internally. I like the new design, more with less. Enjoy, and let us know what you think!

Job Interviews

Nadyne Mielke writes a good summary about what it's like to interview for a position at MacBU. It got me thinking about my first interview at Microsoft and I hope you'll forgive this nostalgic post, but I thought it might be interesting for those of you who can't connect the dots backwards just yet. Okay, that last sentence made me sound a lot older than I am... I had just graduated from Redmond High School and was working as a foreman for a small landscape company. I loved that job, lots of work outside, hard labor, visibly making the world better, but it just wasn't putting enough in the bank. My parents knew Mike Murray, who worked at Microsoft at the time, and suggested I contact him about getting an interview. I nervously worked up an email from my eWorld account on my Mac IIci and sent him the request. He very graciously recommended me for a position maintaining servers in the Microsoft Library group. The interview day came and I remember it vividly. The first interview was fine, then the next interview she asked about my experience with Windows NT and how I would feel working on that OS. I remember telling her that while I felt certain I could learn Windows NT, I didn't really want to spend my time working on such and inferior OS. I think I came off a bit too "Mac" because the interview abruptly concluded. ;-) In retrospect I look back on that day and see so much more going on. Very few people really "got it" when it came to the internet and the web. Remember, this was at the time leading up to the Windows 95 launch. Prevailing wisdom in my neck of the woods was that the MSN icon on the Windows desktop was going to "take over" the internet... Oh the perspective! As I look back on it, I believe Mike was trying to place me in a high growth area, and as far as I could tell at that time, the only place doing any serious sort of web development at Microsoft was the MS Library. Back to landscape work I went, but word got around that I had interviewed and when a the Office team was looking for a tester to write VB automation another good friend of mine, Fred Kesler (ex-WordPerfect employee, new Microsoft hire), asked if I was interested. I applied, but my knowledge of Apple's Human Interface Guidelines, HyperTalk and AppleScript just weren't the skills they were after. :) I remember when Grant George, the hiring manager called me into his office and said, "You didn't get the job, we were looking for better VB skills, but you did really good with the interviews. I'm going to send your resume on to a friend of mine, I think he might have just the spot for you." I thanked him. The next day I came home from work and my Dad said, "I got the most interesting call from Microsoft today. Here's his number. He wants to meet with you right away. He's seen your resume and wants to hire you, but wants to meet with you first, to make sure you're not weird!" I still don't know what he meant by that, but I guess I passed, because I got the job. My manager had just been hired from Apple's QuickTime team and now at Microsoft, he spent a considerable amount of time trying to convince folks that Microsoft needed a separate Mac only development team. Eventually the Macintosh Business Unit was created and my manager moved to the new MacBU and I moved with him. As I look back at this whole cascade of events that largely got me where I am today, I'm so thankful that my youthful fear and trepidation didn't get the best of me while I worked on that first email to Mike. Additionally, it's so very apparent all the good people whose position and influence could have easily pushed me outside of their priority queue, but they took the time and for me, it made all the difference. P.S. Mike Murray was the VP of HR at the time, though I don't really think I understood what that meant back then. He is now working in the micro-finance industry at Unitus something that I'll probably write about later on. He had worked at Apple prior to being hired at Microsoft. Mike had in his garage the actual sledge hammer used in the 1984 commercial! After Steve Jobs returned to Apple, Mike gave the sledge hammer back to Steve.