30 June 2006

IT Collaboration

Christian Buckley is friend of mine, and not only was he recently hired on at Microsoft, but he works in the same building as I do! MacBU shares the same building with, of all groups, our Microsoft IT department! I love that when they walk into work each day or schedule meetings in the conference rooms on our floors, they get to see all our Think Different posters. ;-) Anyhow, for the IT folk in the audience, Christian just got a new shirt that you might appreciate:

29 June 2006

Curiosity and Exploration

From the beginning I've liked what's going on over at Make magazine. I love their video podcast and all the crazy projects they put on display. What they show are regular people, just like you and me, doing stuff, making things, being creative. I was just reading an article titled, Life is Not a Spectator Sport by Darla Isackson in which she makes a very interesting point:

Today’s children are following the example of many adults to become watchers instead of doers, consumers instead of creators, observers instead of active participants. ... Instead of singing, they watch others sing. Instead of making up stories, they watch or listen to stories someone else made up. Instead of figuring out how to do something and developing a new skill they watch someone else perform.

This is so true! There are many reasons for this, but one that stands out to me is the very focus on math and science, these left-brain, less active, and somewhat less creative activities. What's funny to me, is that while the whole schooling infrastructure is supposed to produce excellent employees, what the post industrial revolution market needs is "makers", people who creatively produce.

Paul Graham recently published an essay about the The Power of the Marginal. Near the end he makes this summary comment:

If I had to condense the power of the marginal into one sentence it would be: just try hacking something together. That phrase draws in most threads I've mentioned here. Hacking something together means deciding what to do as you're doing it, not a subordinate executing the vision of his boss. It implies the result won't be pretty, because it will be made quickly out of inadequate materials. It may work, but it won't be the sort of thing the eminent would want to put their name on. Something hacked together means something that barely solves the problem, or maybe doesn't solve the problem at all, but another you discovered en route. But that's ok, because the main value [of] that initial version is not the thing itself, but what it leads to. Insiders who daren't walk through the mud in their nice clothes will never make it to the solid ground on the other side.

The word "try" is an especially valuable component. I disagree here with Yoda, who said there is no try. There is try. It implies there's no punishment if you fail. You're driven by curiosity instead of duty. Which means the wind of procrastination will be in your favor: instead of avoiding this work, this will be what you do as a way of avoiding other work. And when you do it, you'll be in a better mood. The more the work depends on imagination, the more that matters, because most people have more ideas when they're happy.

If I could go back and redo my twenties, that would be one thing I'd do more of: just try hacking things together. Like many people that age, I spent a lot of time worrying about what I should do. I also spent some time trying to build stuff. I should have spent less time worrying and more time building. If you're not sure what to do, make something.

So what should you do? Don't just watch, do something! Don't be afraid to try. Fear kills creativity. Just do something, anything and you'll be surprised how much you'll learn and how well it will go. It's the doing that matters.

28 June 2006

WebKit's JavaScript debugger

Now WebKit includes a JavaScript debugger named Drosera. To use it you need to get the newest build of Safari and enter this in the Terminal:

defaults write com.apple.Safari WebKitScriptDebuggerEnabled -bool true

The best quote is this one:

One of the unique things about Drosera, like the Web Inspector, is that over 90% of it is written in HTML and JavaScript. This is a true testament of what you can do with web technologies today and the rapid development that WebKit allows.

This is cool.

Words Matter

When I wrote the title for this post, it seemed almost trite. I don't mean it to be. The words we have at our disposal define the thoughts we are able to think. If you've learned another language and become fluent enough to think in that language, you know what I mean. I spent two years in Brazil as a missionary and grew to love the Portuguese language. While I took my required 2 years of German in High School, there's nothing like living the language to teach you subtleties of the words. There are some ideas that simply can not be described in another language. The Portuguese word saudade, I think, falls into this category. Further, there are the synthetic languages, like Arabic, where I understand that one symbol can take a whole English paragraph to explain! Simply put, the words you use matter, and more than you might think.

My coworkers often chide me, because when I have a new idea, I'll spend hours trying to come up with the name for the thing. Why? Because it frames the way you think about the idea and code names simply don't switch well. You've got to get the name first. I've never really been able to explain this, but I just heard a speech given by Bruce Sterling that I think finally explains the idea really well and introduces several new ideas along the way. The Internet of Things, check it out.

27 June 2006

Glue That Doesn't Set

Dave Thomas posts about how Perl and Ruby are like glue that connect things together on the internet. The problem with Perl, he conjectures, is that it "sets". When you read Perl, especially if you didn't write the code, it's difficult to discover what is going on and therefore difficult to modify. Now, you can write obfuscated code in any language, but I'd have to agree that Perl has a propensity toward poor readability. What's interesting to me is that Ruby is described as the "Glue That Doesn't Set" or the code that is always easy to read and understand the intent of the author and on top of all that easy to modify. That's pretty high praise if you ask me. I wonder if it's more the conventions and included libraries (Rails, in this case) that make this so, and less the language itself. It's an interesting metaphor anyway.

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. ;-)

23 June 2006

Net Neutrality

There is talk all over the internet and on capital hill about this "net neutrality" and what it is, and why it's important. I've heard several people try to define it, but Tim Berners-Lee, arguably the inventor of the Web, I think has said it best:

Net neutrality is this:

If I pay to connect to the Net with a certain quality of service, and you pay to connect with that or greater quality of service, then we can communicate at that level.

That's all. Its up to the ISPs to make sure they interoperate so that that happens.

Net Neutrality is NOT asking for the internet for free.

Net Neutrality is NOT saying that one shouldn't pay more money for high quality of service. We always have, and we always will.

When I pay my ISP for connecting to the Internet, I pay for the bandwidth for ALL traffic I choose to send an receive. If it is phone traffic (VOIP), web (HTTP) or video (RTSP), I want my bandwidth and quality of service to be the same across all protocols independent of the payload source or destination. The idea that my ISP (currently Verizon) could give priority to their VOIP services, their movie services and their web sites, while slowing or retarding the quality of other competing services seems repugnant to me and simply unfair. Net neutrality is important because it keeps the Internet a level playing field where competition can thrive.

20 June 2006

Adobe and Microsoft on PDF

Brian Jones has a follow up post about the whole no default PDF support in Office debacle. It's an interesting read that also points to the official statements of both Microsoft and Adobe regarding the issue.

It seems like Adobe isn't as concerned about financial implications of PDF creation loss as it is about losing the control over the openness of the PDF format. Does that last sentence strike as a bit of a strange oxymoron? Welcome to the ironies of success.


This has got to be the best one page guide to the details of switching from a Windows PC to a Mac I've seen so far. I've got a bunch of friends that have recently made the switch and this is what I'm going to have them read.

19 June 2006

Interface Guidelines

Here's a fun comparison:

Java Look and Feel Design Guidelines

Windows XP - Guidelines for Applications

Windows Vista User Experience Guidelines

Apple Human Interface Guidelines

Read them if you'd like, but for now, just consider the main page of each guide. Who do you think will be most successful at getting their developers to really follow the guidelines and make their applications "full citizens" on the platform?

Design matters.

On every page.

It's All About the Experience

For Father's Day we decided to take a road trip down to visit my folks in Vancouver, WA. It was a great weekend and spur of the moment we decided to let the kids and Mom stay with the family for a few more days while I took the train back to Seattle. I've never taken the train anywhere. Purchasing the ticket online was a breeze and the Vancouver depot is old and just darling. Right after I got on the train and we started pulling away, I looked back to see the bridge the train just came over rotating on its center to allow boats through, and that was just the beginning of the picturesque trip I am now experiencing. I'm in Business Class which means I paid the extra $13 for an electric outlet I can use to power my laptop during the 3 hour trip. It's quiet, and pretty smooth once you get used to the rocking from side to side. There's a sign, in the front of each car that says, "Using a cell phone? Please be considerate of others." And if someone has a long, loud conversation they take it to the enclosed vestibule in-between each cabin car. It's quiet and comfortable. There are wide isles! I'd have to really reach in order to touch my neighbor across the isle. Also, I didn't have to be at the station 2 hours early like for an airplane trip, and there are no lines! (Incidentally, there was no security check of my bags at all! I guess trains are not as big a security risk as airplanes? I don't know...)

I'm half way through the ride as I type this and all I can say is if AmTrack is not growing, it's simply because they haven't figured out how to improve and sell the experience of classic train travel. I could easily envision luxurious lunch appointments, private booths, full Wi-Fi internet access and large windows. They could have family cars for longer trips, where children don't have to be strapped to a car seat, or confined to coach class seats on an airplane. No more road trip bathroom stops. There would be constant access to excellent food, time and access to movies, board games and always a dynamic and beautiful view. This is to say nothing of having your young child gently rocked to sleep. (As I look around right now, there are already 5 adults asleep.) If I were in-charge of AmTrack I'd remake it into a posh, elite experience that people could look forward to and remember as the calm, peaceful way to travel, a level above cars and planes. It's not the destination, it's the journey when you are on a train. When you are paying for a commodity, you are destination driven, but when you are paying for an experience, then you can charge a premium, and this is exactly what Apple sells, but Amtrack hasn't figured out yet. It's all about the experience. On top of all that, who wouldn't pay more to have every kid, in every car, at every intersection or passing park wave at you?

Webcast on Entourage and Exchange

I've followed the Mac enterprise space for years now and I have always enjoyed watching the webcasts at MacEnterprise.org (formerly macosxlabs.org) The next webcast scheduled for tomorrow, June 20th 2006, will be "an overview of cross-platform collaboration with Entourage's Exchange connectivity" One of the MacBU bloggers, Andy Ruff will help out with the presentation and answer questions. Check it out.

15 June 2006

Will Microsoft be Microsoft without Bill Gates?

Today Bill announced that 2 years from today, July 2008, he will reorder personal priorities and work part time at Microsoft and full-time at the Bill and Melinda Gates Foundation. Ray Ozzie will become the new Chief Software Architect. Craig Mundie will become Chief Research and Strategy Officer. I must admit that I'm impressed by Bill's realization that, "with great wealth, comes great responsibility" and I think that he's trying to do things that really help others worldwide. This is a good thing.

The question that comes to my mind is simply this: "Will Microsoft be Microsoft without Bill Gates?" Before you try to answer this question, consider this one, "Would Apple be Apple without Steve Jobs?" I think there's a good deal of sentiment out there that Apple is Steve Jobs, and if you remove Steve from Apple, you don't have that visionary leadership that has been core to Apple in the beginning and especially in it's more recent comeback. Bill Gates is a bright individual, but his "reign" at Microsoft has not been that of a dictatorship. Maybe that's just an consequence of scale, but from my humble view of all this, Bill's greatest genius has been in surrounding himself will other brilliant people, which is not a trivial task by the way. The collection of bright people at Microsoft isn't going to leave in when Bill moves from full time to part time employment in two years. I think what's less clear is how you calculate the influence of an individual at Bill's level and account for that loss.

$100 Office

If you buy the Student and Teacher Edition of Mac Office any time between June 13 and September 12, 2006 you get $50 off via a rebate coupon located here. This is the lowest price I've ever seen for Mac Office! Just thought you ought to know.

14 June 2006

Shipping is a Habit

A while ago some friends and I took advantage of a spring day and went off road exploring. I took some pictures of some of the terrain. This picture above of the Jeep axle deep in mud reminded me a bit how things feel these days at work. It's just part of the cycle. I've been here before, but it's still slow and muddy.

In an attempt to optimize things, today we got together with two other small teams we work with and invested the day working out our backlog. We're all pretty new to this agile method, but our daily standup meeting has been so successful that we thought it might be a good idea to get all the projects we are working on out on the table. Boy was this an eye opener. Every member of our team was juggling a lot of projects!

For me at least, this concurrency was taking its toll. It's easy to think, "I'll just spend 10% of my time on project A, then 15% of my time on project B, 25% on project C, 10% on D, E and F and lastly 20% on project G." The reality is that even just trying to split your time up between 7 projects is unrealistic. You can't even measure that well, without some very disciplined time tracking. But when the reality is that you need to be making forward progress on even more than 7 projects, well, things don't just get slower, they get worse. The more I multitask, the more mediocre stuff I produce. That's in addition to the fact that everything takes forever to deliver. Sure, my "scope of influence" might be broad, but when so thinly spread, I wonder if my influence is worth anything at all.

Well, after the meeting we had all 60+ projects arranged in the sequence that we'll attack them. What's great about this backlog is that not only can I see clearly the 3 projects that that are most important (not that that was a revelation), but those who work with me, depend on my work, or ask for new stuff can easily see:

1. Our priorities

2. What would have to shuffle for something new

3. Where I'm spending my time,

4. and at what cost to other things I could be doing.

I'm hopeful that this transparency makes discussing projects and timelines more real. We'll see. Another less tangible advantage of this whole backlog is that it serves as kind of a group memory. I can mentally forget about other projects knowing that they are recorded on the backlog and we'll get to them when we have time, but until then, focus on the core tasks and the other parts will take care of themselves in due time.

After all this, I was thinking about how I've allowed myself to get defused by multitasking rather than focused on the most important projects that require my focused attention. I've come to the conclusion that for me, shipping or "getting to done", is a habit, and I need to make it something that happens in some way or another, large or small, in a repeatable, regular fashion. It just makes for healthy closure to things and provides a chance to end, so that you can begin again.

08 June 2006

Our Greatest Advantage

Recently Schwieb wrote about what we are doing with Messenger on the Mac. In his post he makes this significant comparison:

The MacBU is a medium-sized group at Microsoft (at least from my perspective) but compared to either the Win Office team or the various incarnations of the Messenger app on the Windows platform, we’re actually pretty small. The MacBU has a grand total of 52 developers (including leads and managers). A quick query across Win Office shows roughly 550 developers, meaning they are over 10x larger than we are. Yet they own only Office; we own and produce Office, Messenger, RDC and Virtual PC. Because these products are mostly in active development simultaneously, we spread our 50+ developers across these products and thus have relatively small teams. To make our numbers feel even smaller, we’re often doing maintenance work (or even feature work!) on older releases of our software.

This size differential does make things more difficult, but I see our small size as our biggest advantage. The small team size also self selects the kind of people that work in MacBU. If you can't "own" lots of code, deal with massive scale and quickly focus on what is critical, you probably will not last long on the team. There are other great advantages of a small teams of course, Personally I love the challenge and how it drives one to be both tactically deep, and yet very much a generalist, as someone else has said, "specialization is for insects." ;-)

02 June 2006

Adobe Obstructs PDF Growth

According to CNet Adobe will file an antitrust suit against Microsoft. The reason? Adobe doesn't want the next version of Win Office to be able to save as PDF. Apparently they don't mind if Microsoft charges extra for the feature, but if it's included for free as part of the Office 2007 suite, that's not okay. Mac Office, and indeed every application on the Mac OS X that prints, can save to PDF. Can someone explain to me why Adobe would want to make it more difficult for Windows users to produce PDF documents? Print to PDF is one of my favorite features of Mac OS X. If Adobe goes after Microsoft why wouldn't they also go after Apple for including this kind of functionality in the Mac OS? This seems like a very strange move on Adobe's part.

On team politics...

I think from time to time, everyone has to deal with politics. Depending on your organization or team your milage may vary, but where there are people interacting, trying to get results, chances are you'll encounter some team politics.

I recently finished reading The Five Dysfunctions of a Team by Patrick Lencioni. It was a wonderful read, I highly recommend it. The book is setup as a fable, so the story is fake, but the ideas are very real and practical. One part I really enjoyed was when Kathryn (the CEO in the story) defines politics:

Politics is when people choose their words and actions based on how they want others to react rather than based on what they really think.

Think about that for a while. There's some great wisdom in this definition.

01 June 2006

Fixing Millions of Errors and Warnings

Erik Schwiebert, one of our Dev leads here at MacBU has begun to blog. We sometimes develop nick names for folks, often because of duplication of first names, and I believe Erik fell in to this category sometime ago. He's pseudonym became Schwieb and as you can see by his blog URL, the name stuck. Erik is a quintessential geek and he and his team have done an amazing job as they have worked on getting Office to work in Xcode.

In his most recent post he writes about our work to transition our massive Office code base to Xcode. How would you feel if in your first pass at getting your project moved to Xcode the compiler reported back "almost a million errors and several million warnings!"? In the end, I agree with Erik, this transition is helping us to clean up our code in a million different ways, and that is a Good Thing.

Update: Erik has posted a followup here.