Leaving Microsoft

Starting today I no longer work at Microsoft. As many of you know, I started working at Microsoft after an illustrious post high school career as landscape architect. ;-) I loved the landscape work, but Microsoft paid better. I was just barely 18 and Microsoft was just realizing that the internet (lower case then) was amazingly NOT going to be replaced by the Windows 95 Microsoft Network. Much has changed since then. While I started my 4 year degree and continued working on it part time, it’s now time for me to go back to school full time and finish. After that, I hope to get an MBA.

I’ve had a remarkable time at Microsoft and in MacBU in particular. I’ve learned so much. I’ve been so thankful to interact with such a high concentration of good individuals. I feel very blessed. My last day was December 31st, 2007.

So that’s the news. I realize that many of you subscribe to this blog because of my connection with Microsoft and especially MacBU. Since I'm no longer working there, feel free to unsubscribe. During the Holiday's I've been mentally processing my MacBU experience and I'll be posting much of what I have learned and observed. If that interests you, hang on, there might still be some content here for you! As you may have noticed I've not really posted anything since September when I returned to work after paternity leave! These last 3 months finishing up Office 2008 were quite the grind, not a death march, but certainly not pretty. I'm glad for it to end. With a bit more time, I think you'll see some more frequent posts here.

If you'd like to contact me informally, as always, feel free to email me at my Gmail account referenced on my Blogger profile page. If you'd like to contact/track me more professionally, feel free to follow my LinkedIn profile.

Happy New Year to all and wish me luck!

Numbers

One of the great benefits of working at Microsoft is that when you add a new little one to your family, you get 1 month of paid paternity leave. Recently, we've had the opportunity to take advantage of this benefit. Since our little baby was born, I've been home working as Mr. Mom. I've been mostly offline, except for early mornings and late nights when the kids are sleeping. My boss isn't going to like it, but since I've been gone for paternity leave, I've logged on to my work email only once, and that was just to make sure my out of office emails were working. Needless to say, I've been happily busy with family.

I haven't been so busy that I didn't catch Apple's announcement regarding their new iWork application, Numbers. I haven't bought a copy, or logged into work to see what others are saying about this announcement, but I'm guessing it's much like when Apple announced Keynote for the first time. A combination of deep respect for Apple's software and design capabilities, coupled with sense of, "Let's get back to work and make something great!" kind of attitude.

What follows are some of my personal feelings that I've considered amidst making meals and playing at the park with my kids. I don't in any way attempt to speak for MacBU or Microsoft, these are just one person's opinions, specifically mine. And yes, I do work in MacBU, and yes I can't share everything I'd like to say for obvious reasons. So, here goes:

Once upon a time, it was decided that we needed to move to a more open file format. XML was the obvious choice. There were and are a lot of good reasons for opening up your file format. I'm not going to discuss these at length, but one of these in particular is that folks are not forced to use your application to both read and write files that others can use. This is a good thing.

Allowing anyone to read and write your file format is a bold move because it says in essence, "We don't need a locked down file format to compete. The format can be available for everyone, and we'll compete on the ease of use and efficiency of our applications. We have what we think is the best interface for reading, creating and managing Office documents, but if someone has what they think is a better way to build Office documents, wonderful, we welcome it!"

What Apple has done with Keynote, Pages and Numbers is exactly this. With each one of their applications, they've created a user interface that reflects how they think people want or should want to act when building a presentation, document or spreadsheet. I've been in this market for a long time, and obviously have opinions about how things should be done. If someone else has what they think is a good solution for building Office documents, I think that's great.

From another perspective, I think Apple's work on Numbers underscores that despite the large advances being made in web interfaces, there is still a place for rich client applications. Both iLife, iWork and even the Google Maps application on the iPhone reinforce that there's lots of opportunity left for innovation in the "rich client" arena. Numbers specifically proves there's opportunity left for innovation in the productivity applications space. I certainly think there is, and folks who think that the problem space that Office lives in is "essentially solved", should think again. There's plenty left to improve. Plenty. That's what makes it exciting.

Some have said, "I bet MacBU is envious of Apple being able to start from scratch." Now that's a loaded comment. Let me try to address the different parts. First the envious thing. Apple is a great software company and at Microsoft, software is pretty important too! ;-) At the very core of MacBU is the desire to produce great software for the Mac platform. When the business unit was created, the whole goal was to focus our energies on producing seamless and compatible, but very Mac, applications. There are a certain set of problems one must focus on when working on Mac Office. There's another set of problems one must focus on when working on iWork. You trade problems sets, but they are just different problems sets! The grass is not always greener on the other side of the fence. Most people with significant software experience will know that "starting from scratch" is one of the most risky and difficult things to do. I don't think anyone is excited about scrapping years worth of effort just to have a clean start at things. From a programming perspective, that just makes no sense.

Also, Apple isn't starting from scratch. They are building methodically on the several foundations they've laid over the years in Keynote, then Pages and now they've added Numbers. One might even say that, Numbers is Keynote and Pages with better table and function support, and not be too far from the mark. This kind of progressive building together is what Microsoft did with Office originally. There's a pattern here. The bigger questions in my mind are really these: "Will Apple's software foundation allow them to add to and improve their software for the next 20 years? What will be the rate of their improvement?"

Lastly, in a very real way, we do "start from scratch" every product cycle. I wish you could all experience the high energy and exhilarating discussions we have when we are planning for the next version of Office. We "wipe the slate clean" and do our best to remove all inhibitions and constraints when we think about what we can do next with Mac software at Microsoft. And this doesn't just happen in MacBU. My favorite example of this, right now, has to be the new UI in Win Office. Maybe someday I'll write about that more in-depth, but the way that Ribbon interface elevates access to the many features of Office and makes Office easy to use is just wonderful. Anyone who's serious about interaction design in software should take a serious look at what this interface does and how it does it. There's a great deal to be learned, not the least of which is that sometimes you need to dramatically re-think the user interface of your application and not be afraid to do exactly that.

Finally, as in the past, the question will undoubtedly be asked, "What is the core value of Office on the Mac?" I'll answer that with one word: compatibility. Mac users are the kind of people that want things to "just work" and Microsoft Office for the Mac offers that exact value proposition. Mac users want to enjoy all the great things that make the Mac experience wonderful, but still be able to share documents and communicate in a Mac way in a Windows dominated world. MacBU is categorically in the best position to deliver on this promise of compatibility.

The GM of MacBU wants to talk to You!

The general manager of the Macintosh Business Unit at Microsoft is Craig Eisler. He's been here now for just over 4 weeks. It's been fun to watch him step into his new role and if nothing else watch as everyone adjusts to a new dynamic leader. Craig seems to be just that, a high energy, leader. His transparent nature and naturally positive perspective on things has just instantiated itself on our official MacMojo blog. He's asking for suggestions on what you'd like to see different, feature requests, even topics that you'd like to see him personally address on the blog. Right now there are only 39 comments. Please, if you've ever wanted MacBU to do "X" differently, now is your chance. Get in there and leave a comment.

Porting to the Mac...

One of my favorite bloggers, Scott Stevenson, recently wrote about a subject near and dear to my heart, namely, some Simple Truths About Cross-Platform Apps. Scott makes some great points:

Mac users bought the computer they did because they found the experience more appealing. Bringing an application across from Windows with minor tweaks simply won't resonate with this sort of user. ... Maybe the most important thing you will ever need to know about Mac development is this: Mac users will generally favor an app with a better experience over the one with more features.

The whole "write once, run anywhere" idea comes from and resonates with managers and engineers who are out of touch with their customers. Fundamentally, you need to decide who you are trying to help. If you are trying to help, say, Mac users be more productive and on their platform of choice, while still interoperate with the rest of the world, then that dictates certain realities. If you are expanding to the Mac platform simply to "increase your market coverage" then you might not have the right mindset needed to build something Mac users will like.

Not everyone gets this, and that's okay, the market has a way of helping folks that don't get it. I remember back when we were working on Office X, right as Apple was moving to Mac OS X. We spent some serious time and money to study and really tangibly understand who these "Mac users" were. The results were amazing and strongly pointed out how different the Mac customer was compared to the Windows customer. That has not changed. I don't think it's elitist or smug to say that Mac users value different things compared to Windows users. It's a fact. So, if you are going to try to sell software to both the Mac users and the Windows users, before you start, you better understand the differences.

MacBU MVPs

Have you ever wondered what a Microsoft MVP was? Have you considered the performance implications of getting a Wii for your work force? Have you sat at night wishing you could just find a newsgroup to monitor? Have you wished you could have some tangible impact on the next version of Mac Office? If you answered yes to any of these questions, this post is for you!

The Screenshots

As promised and thanks to a brave soul, here are the Easter Egg screenshots. Without the animation, it's hard to get a feeling for scrolling credits etc., but here goes. First Office 98, then 2 Office 2001 screenshots.

An Easter Egg

From Wikipedia:

A virtual Easter egg is a hidden message or feature in an object such as a movie, book, CD, DVD, computer program, or video game. The term draws a parallel with the custom of the Easter egg hunt observed in many western nations. In computer programming, the underlying motivation is probably to put an individual, almost artistic touch on an intellectual product which is by its nature standardized and functional.

[...]

Because of the increase in malware, many companies and government offices forbid the use of software containing Easter eggs for security reasons. With the rise of cybercrime and the prevalence of the Easter egg's cousin, the logic bomb, there is now concern that if the programmer could slip in undocumented code, then the software cannot be trusted. This is of particular concern in offices where personal or confidential information is stored, making it sensitive to theft and ransom. For this reason, many developers have stopped the practice of adding Easter eggs to their software. Microsoft, who has in the past created some of the largest and most elaborate Easter eggs such as the ones in Microsoft Office, no longer allows Easter eggs as part of their Trustworthy Computing initiative.

That pretty much sums it up. In a quieter time, there were Easter eggs. Alas, that time has left, never to return. However, digging through some old notes of mine, I found something fun, so today I'll to do my part to preserve some Mac history. The following are the instructions needed to trigger an Easter egg in Mac Office 98 that, as far as I know is Mac specific and no where recorded online. I'm not going to tell you what it does, but if someone has an old copy of Mac Office 98 around, does this and sends me a screenshot, I'll post it. :)

The steps are pretty involved:

1. Set System date to > Feb. 15
2. Boot any Office application
3. Make sure the Assistant is up
4. Grab the Standard toolbar by the drag handle and do the following without letting go:
   • grab to the center so it is floating
   • grab it back to the top dock area
   • grab to the center so it is floating
   • grab it to the left dock area
   • grab to the center so it is floating
   • grab it to the bottom dock area
   • grab to the center so it is floating
   • grab it to the right dock area
   • grab to the center so it is floating
   • grab it to the top dock area and drop it
5. Click the Assistant
6. Type “Think Different”? Think Grammar!
7. (including all punctuation and spaces, exactly as you see it above)
8. Click Search

Enjoy.

Post-It Pixel Art

As a birthday present to MacBU Joe LeBlanc, Jessica Lambert and Matt Elggren (aka Mel) arrived at our building at 6 AM yesterday morning and setup this surprise for us! I think it's super cool. More details at our Mac Mojo blog. Enjoy!

10 Years of MacBU

Today we are celebrating the 10th anniversary of the creation of the Macintosh Business Unit here at Microsoft. I was there when the Business Unit was created, so I thought I'd share some of my memories about that time, way back when.

When I was first hired as a contractor to help test, I was actually hired by an old QuickTime/Newton engineer that had left Apple to work at Microsoft in the Word team. Microsoft was just "getting" the Internet and one of the several efforts underway was to create an add-in for Word that would allow you to create, read and browse the internet, in Word no less! I know that sounds laughable today, but back then web pages were much simpler and it kind of made sense that Word would be a good place to create web pages. Well, the add-in was named "Internet Assistant of Word" and I was in-charge of testing the HTML input/output of with this plugin installed on the Mac. I had loads of Mac experience, but little experience with HTML apart from building my own pages in Adobe's PageMill (!), so I dove in, learned a bunch and tried to ferret out all the bugs.

While I was working on the Mac version of Internet Assistant for Word, my manager kept meeting with others around Microsoft evangelizing the need for a specially purposed Mac Unit that would just focus on the Mac software. He was by no means the only person pushing for this change, but when it did happen, he got to be a part of the new team as Test Manager and I joined the newly formed MacBU with him.

Back then, our automation system consisted of (don't laugh) XLM scripts that would drive Excel through test scenarios! Excel was really the only team that had lots of automation and they had a whopping 20 or so machines set aside to run these tests. Naturally I landed in the Excel team, but my task was to develop automated performance tests for Excel.

The day the MacBU was formed, we met in a large conference room near the old Microsoft Library. This building has since been replaced by bigger buildings, but I remember standing in the large auditorium in the back, standing room only, as folks explained the change and why it would be a "good thing."

Much has happened since that meeting and I dare say, that creating the MacBU at that time was a very aggressive decision. Back then we had a majority of Windows developers, writing code like crazy to build a Windows product, and then finally ship it, only then to work on the Mac product. This produced sub-optimal results.

After the MacBU was created, we moved to a place where our developers and testers were not required to do the Mac thing, but got to choose which product to work on. (Yeah, when the MacBU was created, lots of folks were forced to be on the Mac side and didn't want to, but over time that quickly filtered out.) The option to work on your platform of choice set us up to hire more Mac talent, and that was a very, VERY good thing. Soon after we would fork the code base, move to different ship cycles, eventually move to CodeWarrior, then Mac OS X 10.0, on which we were the first big company to get on the new platform! Yeah, our quality wasn't the greatest, but at least we didn't get called "laggards" by Jobs in his keynote! :-P My goodness, we were the default OS web browser and email client! We started the pin-striping with IE! Okay, so maybe we don't mention the pin-striping, I'm just saying...

Now, we've got a growing business, a super talented and focused Mac team that "gets it" when it comes to the Mac experience. From a industry level, when MacBU was created, everyone was saying, "Write once, deploy everywhere." and in a way, there's some of that still with the "web as a platform" being pushed today. The creation of the MacBU flew in the face of all that and said, if you want to be excellent on the platform, you've got to treat it seprately, not as an afterthought. All throughout the industry, I believe the MacBU has given other large companies permission to consider the question, "Should we have a dedicated Mac team just to focus on the Mac stuff?" I think that has had a more postitive effect on the overal state of Mac software from large companies than all the new Cocoa APIs, as much as I love them.

All these years later, it's hard to argue with the majority of users that see Mac Office as a must have set of tools for their work. The challenges of the Office 2008 product cycle continues to amaze and frankly, I don't think Apple could throw any more required changes at us! We are setting the stage for some fast action innovation and delivery that I think is going to make folks sing, not just for Office 2008, but beyond. The conspiracy theorist and MS haters will continue their diatribes, but the rational-rest of Mac users will continue to kick butt using our software. I love it, because in the end that's what it's all about.

$30,000 Apple Logo

A few months ago we got a bunch of Intel Mac minis (Intel Core Solo). We got 64 for automation and a some others for testers to use. When I saw the pile of boxes sitting in the hall to be recycled, I knew I had to save them. We piled them into my office knowing that there would be something I could do with them, but I just didn't know what or when. A few weeks later, it hit me. I opened up OmniGraffle and sketched out the plan:

The Plan For those of you not experienced with pixel art, what you see above is the Apple logo. I might add that it's very hard to come up with something that will look like the Apple logo with so few pixels. Seriously, try it. Once I got something that looked good, I got Joe to come and help me out. It took a bit of effort, but with Joe's help and some double sided tape, we got it finished: My Office Apple Logo I like to think I have the most expensive non-Apple-assembled Apple logo in my Office. This week we got our shipment of an additional 64 Intel Mac minis (Intel Core Duo) for automation. Hmmm, more boxes...

Woz at Microsoft

One of the cool things about working at Microsoft is the constant stream of interesting guest speakers. Recently it was Steve Wozniak. It was facinating to listen to him speak about his love for technology. I had my trusty MacBook Pro and took down some notes and fun quotes. On chip design: "I played a game: how can you design it better than before. I wanted to see if I could design something with half as many parts." On wanting a computer: I told my Dad, "I'm going to have a computer." Dad said, "It costs as much as a house." I was stunned and quickly replied, "Then I'm going to get an apartment." About his microprocessor, "I couldn't afford one, but I could build it. I could always build something for free." Woz was giving away his Basic schematics, then when Jobs found out, he said, "Let's sell it." On Human Computer Interaction: "It's a lot easier to design a computer than make it acceptable to people in their lives." On Apple's rank in early computer magazines: "Apple was always at the top of the list, you know, alphabetical order." On the small business owners in the 70s and 80s: "They didn't want a computer, they wanted a solution." On childlike learning: "What's fun for kids can be fun for adults and that's my philosophy." Someone asked what excites you? His response: "Products done really well from the people point of view." "Steve jobs never programmed in his life." Someone asked if he had any regrets to which Woz replied: "Regrets about Apple, no. Regrets about my own life? Yes, I wish I would have put floating point in Basic, but I wanted to get it done quick."

Using Scrum in MacBU

Today marks the official beginning of sprint number 2 for the Automation Team. Last month was our first attempt at a modified Scrum. I mention "modified Scrum" simply because of the cruel fact that I don't know everything there is to know about the Scrum Methodology. We just kind of picked out what made immediate sense and did it. It's a good change and we are learning. While our team is the first team in MacBU to be using this Agile process, hundreds of teams at Microsoft have had great success with it. We've had daily standup meetings for a long time, but this was the first time we actually did the product backlog and sprint backlog so I thought I'd record some of my personal reactions to the experience. There's a lot to like about what we've experienced so far, and as we figure out better how to apply this "Agile" stuff, I'm hopeful things will get even better. Here are some of my first impressions about the process: The backlog provides an awesome communication vehicle. Before the beginning of September the four of us on my team got together and generated a big long list of all the things we would like to do. We put all of this in OmniPlan, and then selected a subset that we would tackle in September. This did several very good things:

1. It got us all excited about the ways our team could contribute to the overall success of the software products we produce.
2. Helped us "get on the same page" with respect to the meaning of the individual items. You'd be surprised how different people can interpret even the shortest sentence!
3. Allowed everyone on the team to see exactly what everyone else had to do.
4. Allowed me, as a lead, to post the sprint backlog in the Lab for everyone to see. If folks wanted to see what we were working on, or how much progress we were making, it became very trivial. Perhaps low tech, but effective.

Developers are less randomized and more focused. Part of working on an internal team that builds software for folks sitting in the office next to you is that you get a lot of requests and lots of feedback. This is good, but the flip side is it can also lead to lots of interruptions and cause your efforts to be spread so thin that your effectiveness suffers. With our focus set in the Sprint backlog, new requests simply wait until the next sprint. All the devs get to remain heads down getting stuff done. Cross Team Collaboration Improves. With the sprint backlog in place, when someone or some team comes to us to ask us to "Do X" we can immediately respond, "That's a great idea, does it need to happen this sprint?" Almost always, it can wait, and this does two great things:

1. It allows time for the customer to really think about the request. By the time the next sprint rolls around what was life-and-death-urgent is now better thought out and prioritized more realistically.
2. It gets our "customers" in sync with our rhythm of delivery. The theme becomes, "Get your ideas in the next sprint's backlog, and you'll see some action on it in a month." All the lobbying for changes and design discussions about what goes in next will happen with the Product Backlog owner (me in this case) while the rest of the devs are uninterrupted.

High quality things get done! This seems maybe a bit silly, but at the end of the sprint, even if you way over estimated your production capability, (which we did) you have something to show for your efforts. Not just working software, but reasonable easy to understand metrics (like units of work per day) that everyone can understand when you need to explain why it will indeed take 3 weeks to deliver a high quality solution next sprint. Things get better now. One of the most interesting things about this whole process is how it elevates and exposes problems in the stuff you are doing. As you look at the backlog and compare your velocity of production to what you thought you could do, immediately you and everyone else begin to consider, "Why does this take so long?" On the last day of the sprint, (last Friday for us) we got together in the Cafeteria and took some time just to reflect on how things went, what slowed us down, and what can we do better. What's great about this is you remember what you were doing and then we add to the next Sprint items that will increase our velocity. As Henry Petroski has said in To Engineer Is Human: The Role of Failure in Successful Design, we learn more from our failures than our successes. But only if we pay attention to the failures and figure out what to do right the next time. This is so much better than waiting until we ship Office to have our "Post Mortem" to discuss how the release went. Problems are fresh, and fixing them right away have a good chance of paying off in the current product cycle. All in all, I'm very happy with how Scrum is working for our Team. For October, the Tools Team and Lab Team are joining us in testing out the Scrum process. I hope it works out for them, as well as it did for us. P.S. If this kind of software development stuff interests you, there's a great overview talk I recently found by Ken Schwaber which was produced as part of the Google Tech Talk series. I really enjoyed it. Lastly, if any of you have any sage advice for a Scrum Master in Training, I'd love to hear it.

MBUSWAT

Note: This is a re-post of my 1st post on our Official MacBU Blog, Mac Mojo. If you haven't added Mac Mojo to your blogs to read, I'd recommend it. I'll be posting over there along with about 10 or so other folk in MacBU. Check it out, I think you'll enjoy it. --- Hello! My name is David Weiss and I'm the Automation Test Lead in MacBU, which means that I build stuff to help us test our code better. It's a great job. I could give you a detailed introduction, but I've kinda already done that. I could talk about automation practices or our sweet beowulf cluster, uh, I mean automation setup, but today, I'm not going to talk about work, at least directly. Today, it's all about the food! Since the MacBU was organized in 1997, we've moved from building 17 to building 44 and then to building 115. Change is one of those constants here at Microsoft and physical location is not excluded. Building 17 was the long time abode of Office, Win and Mac. When we moved to 44 it was the first time we were physically separated from the Win Office team which allowed us to develop some of our own unique identity, but the best part of building 44 was the conference rooms, or the food associated with, the conference rooms. I don't know how it is at other corporations, but often there would be a morning or afternoon conference room meeting and catering would be provided. It didn't take us long to notice that after the attendees had finished eating and returned to their meeting, there was a small window of time where the food was available before catering would clean up the food and toss it out. Being the ecologically sound individuals we are, and dissatisfied with waste of any kind, we setup an email alert system. One of the team, we'll call him Matt, setup an email rule on his machine so that any email sent to him with a subject that contained the text "[Food]" was duplicated and forwarded to other super secret food recon agents. In this way, we remained successfully "below the radar" of counter intelligence units. Until, of course, Matt turned his computer off. When that happened, we were all downgraded to free-pop-only status. After about 2 days we realized that we had totally missed one of the key aspects to an Official Microsoft operation, and that is, of course, a whole bunch of letters stuck together in a crazy acronym and the FAQ explaining it. What did we name our operation?

MBUSWAT: The MacBU Sustenance Watch and Acquisition Team!

Our Mission Statement: To seek out and share information pertaining to free food available at work.

Generally the standard encryption technology used to prevent unauthorized eaters from viewing our confidential communiqués was white colored text. This worked until we found that conspiring developers had added a feature to expose our secret messages to prying eyes: Auto Preview. We increased our encryption standard to include about 3 lines of non-encrypted babble prior to the encrypted message. This method has been found effective to this day, even with modern email clients! Well, anyone familiar with food services and catering knows this one truth:

1. Food quality degrades as the time increases in which the food sits idle, sad and unconsumed.

To combat this reality and better meet the cross group communication needs we developed a clear rating system (with easy to understand color coordination): Code Red: Food is available, but guarded by food service personal. Be wary of a status change. Code Yellow: Food is being consumed by conference room attendees. Soon we'll be able to move in. Code Green: Food is all clear. Act quickly, or you'll regret it. Code Brown: Food is still available, but due to prolonged exposure, it may taste like, well, not so good. Code Puke Green: Food is still there, but eat at your own risk, it looks or tastes nasty. With this plan in place, communication improved significantly, but alas, we continued to be plagued with the dependency on Matt's computer being fully operational. Since Matt, being the good tester that he is, often found ways to crash his computer (in the days of Mac OS 9) and hang or crash his email client, we needed to permanently sever "the Matt dependency". We did this by creating a distribution list on the mail server. The end result is that anyone who sent email to "food" would have that email sent to all who participated in the super-secret-group-mission of free food recon, disclosure and consumption. However, this efficiency gain significantly increased our exposure to being "outed" by the catering overlords, so while we stealthily kept the short name of food, we changed the friendly name of the alias to, "Mac Crossteam Discussion" which has kept us safe ever since. All of this lead to a namespace collision with the .NET team here at Microsoft. It all started with this fairly benign email:

From: Snax.Net To: Mac Crossteam Discussion Subject: New snacks reported at Snack.NET! A new snack in the Candy category has been reported in your building. Here is a description: So much peanut brittle you'll be sick for days. Log on to Snack.NET for further details! This email has been generated automatically. Do not reply to this email. If you would like to be removed from this list, please visit the Snack.NET website and unsubscribe. This has been a recording.

Of course, this kind of tempting notification led to simultaneous surprise, fear and hunger. Our covert ops team immediately got to work. Soon we discovered that Matt Stoecker was the author of a "test application" named "Snax.NET" which allowed for companywide snack notification. As he was testing the mail notification system, he used our alias. After Mr. Stoecker clarified and apologized, Agent Snook followed up with the salient question, "Can we still get the peanut brittle?" Agent B expanding on that theme continued, "I think Agent Snook makes a good point here. One cannot simply suggest the presence of peanut brittle and then not provide some easy way to access said tasty treat. I, for one, feel heinously bamboozled. And, I fear, this feeling of bamboozlement will only abate with copious quantities of peanut brittle..." Not long after this email exchange two guys from the Snax.NET team showed up with 2 buckets of peanut brittle! Complete office delivery is way better than having to go out searching for leftover catering! Today, the Snax.NET server has gone to that great big bit bucket in the sky, but here at MacBU, we are still on constant alert for what goodies might befall us. And now you know, the rest of the story. ;-)

Work and Play

From David Heinemeier

You don’t have to work hard to work well. You don’t need sinister eyebrows or only 4-hour sleeps or a booked calendar to be serious. But somehow that image sticks so bad that we tend to view fun as the opposite of Serious Business Stuff(TM). It’s a false choice, not a real fight. And you accept its premise at your own peril. Fun is all about creativity, innovation, play, experimentation, progress, and seeing real things come to life. If you make fun an enemy of business, you’re judging all these desirable concepts by association.

I just had lunch today with one of our Excel testers and while we were discussing some testing ideas, she just blurted out, "I'm so in love with pivot tables! I just love them!" I laughed, but I loved to see the enthusiasm about of all things, pivot tables! Work can be play indeed!

But what is MacBU?

I just got the most cordial email asking the most simple question: "What is MacBU?" Anyone who has spent any time at Microsoft knows the penchant demand for acronyms and jargon, it's so prevalent that at one point someone created an internal glossary just so people could keep up with the alphabet soup. That project has since disappeared, I think simply because it couldn't keep up! The "MacBU" is the nick name we use to refer to our business unit at Microsoft. Our fully qualified name is the Macintosh Business Unit. We develop Office; Word, Excel, PowerPoint and Entourage, Remote Desktop Connection and Messenger. There are other Mac products at Microsoft, but they are not part of the MacBU. We say "MacBU" like "Mac boo" and often write "MBU" but say MacBU. For completeness, we also use XL for Excel, Erage for Entourage, PPT for PowerPoint, RDC for Remote Desktop Connection and Msgr for Messenger. Every character counts, you know. Word doesn't have an abbreviation, because it's, well, Word. Yo. Now you can be all hip to the local lingo!

Moving on to AppleScript

I've been super busy here at WWDC 2006, but it's that good kind of busy. Lots of new technology to learn and understand. It's been great! I did take some time yesterday to review some of the feedback online about our announcement to ship the next version of Mac Office without support for VB. This was a tough decision and one of those wicked problems that happen from time to time in software development. I think Erik's explanation of the challenges involved is one of his best posts yet. If you care at all that we are removing VB from Mac Office, read his post before you pass judgement. There's a lot of context to be had in there. Saying goodbye to Visual Basic Rich Schaut follows on with a post about what money can't buy and the challenges of software development in general. He then makes this comment:

But that does not mean we are unaware of the pain this will cause to a significant number of users. If you think we are not aware of that pain, consider this. David Weiss can give you a better number on this, but our testing methodology has always made extensive use of scripts for automated tests. Not just a couple of scripts, but thousands of scripts per Office application. At one point, all of those scripts were written in VB/VBA. In order to carry that testing effort forward into the era of Universal Binaries, every single one of those scripts had to be rewritten in AppleScript. I don't think it's even a remote exaggeration to say that our use of VB/VBA was at least a couple orders of magnitude greater than even our most automated customers. Do we know your pain? You bet we do.

This is absolutely true, we feel the pain. When we removed VB, immediately we lost more than half of our automated test bed. We've been carefully building back up our automation in ways that make sense, but it's a huge loss that those scripts no longer worked. That said, we know that AppleScript is capable and something we can depend upon long term not only for our testing efforts, but also for workflow customizations that our pro customers will use and build upon. Just last night I was at a WWDC party and I was introduced to a developer who had written a very cool script in VB to automate some of the work he and his team does on a regular basis. He was obviously concerned about what loosing VB would mean to him and his team with the next version of Mac Office. Everything he was doing with VB could be done in AppleScript and when we explained how AppleScript Studio provided a real IDE and UI workshop for developing custom solutions, he was very excited. If you have custom VB scripts, may I suggest looking into AppleScript as an alternative solution? There are great resources on building AppleScript automated workflows and it really is the Mac standard for inter-application communication. We are always looking for ways to make our AppleScript support better, so if in trying to make your VB solution work in AppleScript, you run up against a wall, let me know either in comments or via email. I think you'll be surprised at how much can be done with AppleScript today.

ExCodeWarrior Schwag

I've written before about our ExCodeWarrior dev shirts we got as reward for successfully moving our code from CodeWarrior to Xcode. Well, now you too, can pay your respects to CodeWarrior, in mournful black, as well as honor the great work the Xcode team has done, and all this in time for WWDC 2006! I'll have my ExCodeWarrior shirt on, will you? ;-)

The General Purpose Thing

Recently John Gruber wrote about the The Mac OS X Tipping Point and finished with this sumation:

You can’t appeal to all people all the time, but Mac OS X comes remarkably close. The old Mac OS, as insanely great as it was, did not.

I think what is so quickly forgotten about the transition to Mac OS X was Apple's against-the-grain assertion that they could build an OS the did appeal to beginner users and power users alike! This was NOT the prevailing wisdom of the day. I even remember seeing previews of the OS in which there were "modes" like standard user and advanced user. Simple Finder in Mac OS 9, ultimately was an outgrowth of this kind of thinking. Additionally, Microsoft was pursuing a dual code base strategy for desktop vs. server. Apple's insistence that you could actually build an OS that did scale from the grandma turning on a computer for the first time to a seasoned UNIX developer was courageous and spunky at the very least.

Recently, I have noticed a resurgence of the idea that the general purpose tool is by definition a less effective solution as compared to something more task specific. This hits home to me personally since I work on software that is used by a very broad spectrum of Mac users. There will always be tension when trying to design software to appeal to such a large and diverse audience, but simply factoring the problem into a "pro" and "beginner" products is the easy way out. You can make software that has general appeal and scales gracefully to a user's needs as they grow, it's just very hard to do! Difficulty aside, it is this kind of "scaling up" that defines what I love about great Mac software. All the core features are apparent and easily discoverable, but as you need more functionality, you effortlessly find them, almost as if the designers read your mind. Tools like these become transparent to your workflow and are a joy to use.

Small (relatively speaking)

This has got to be my all time favorite comment from the press:

"The autonomy of this relatively small division allows Microsoft programmers to cut loose and design the best software they can imagine… Microsoft's Mac offerings are routinely credited as being more innovative, elegant and robust than its mainline PC products" – Terril Yue Jones, Los Angeles Times, September 2005

There's a lot of energy out there in defense of the small, the startup, the two or three in a garage, and I don't want to take anything away from that, I am a romantic at heart. There are wonderful times to be had by all and room for everyone, but to perhaps add some balance to the discussion, there are some very good reasons for "big". Consider Six Apart the makers of some very successful blogging software. Two founders with a company that has been on the blogging wave from the beginning, the perfect poster child for small and agile. And yet Mena Trott president and a co-founder of Six Apart, writes a post entitled: In Defense of Big (relatively speaking) She writes:

An underlying theme over at Signal vs. Noise is the concept that smaller is better -- smaller in terms of start-up capital, company size, development teams and even hardware. As part of a two-person team that created the initial versions of Movable Type and TypePad, I certainly understand the logic in encouraging small and nimble teams. The eighteen months that Ben and I spent in our spare bedroom coding was probably our most productive for bare-bones software development. Of course, during this same time, we were afforded the luxury of not having to do anything much more than coding and designing -- our project management was done via (what felt like) telepathy.

A long time ago (well, maybe not that long ago -- it just feels like it), Ben and I were at a fork in the road where we had to decide whether we wanted a small, niche company that would serve as a nice lifestyle business or try to be something bigger and take a gamble that Six Apart could make a serious impact on blogging. (A "lifestyle business" is one of those terms that money/funding people use to describe someone who can make a nice lifestyle for themselves with their company, but doesn't really make jobs or opportunities for a lot of other people.)

So here we are -- a big, small company or a small, big company. I've been on both sides of the table and have to say that it's pretty nice where we are. And since the "small is better" argument is very often offered in both elegant (Signal vs. Noise) and ignorant (Generic "Being Corporate Sux!!") ways, I thought I might contribute my reasons to why bigger can be better.

She then lists her reasons:

1. More people, different view points.

2. Accountability.

3a. Creating jobs for many people.

3b. It's nice not to always have to bootstrap.

4. The ability to shift roles.

5. Sticking to what we're good at.

6. It isn't just an American thing.

7. Creating products that really make an impact.

I'm a bit biased in talking about this whole thing, but I can say that the small startup resonates with me, like with others. That said, there are great things you can do for others as more people use your product and with the scale comes the blessings and challenges of software in the large. Check out her full post. It's a great read.

Enterprise Feedback for MacBU

A while back I posted about our new release of the Office Resource Kit for enterprise admins. We have setup two methods for you to give feedback on what you'd like to see in the next version:

1. An online survey - It will be active until the end of July 2006

2. An email address - Mac IT Pro Feedback - macitfb@microsoft.com

Note: We had the online survey setup earlier, but inadvertently set it up so after one response, the survey closed. It took us a while to figure out there was a reason only one person responded. ;-)