On Context

There's been some talk recently about how MacBU might better develop software, and it reminded me of this story:

A long time ago in a faraway village lived a man who everyone did their very best to avoid. He was the type of person who believed that there was only one competent person in the world, and that one person was himself. Consequently he was never satisfied with anything. His shoes never fit right. His shirt never felt comfortable. When his food wasn't too cold, it was too salty, and when it wasn't too hot, it was too bland.

If a field wasn't sowed by himself, it was not sowed well. If he didn't close the door, the door was not closed properly.

In short, he made a career of frowning, lecturing, criticizing, and mumbling about the incompetencies of every other person in the rest of the world.

Unfortunately, the man was married, which made matters all the worse. No matter what his wife did, in his eyes it was wrong. No matter what the unfortunate woman cooked, sewed, or cleaned, or even when she milked the cow, it was never satisfactory, and he let her know it.

She tried very hard to be a good wife, but it seemed the harder she tried the less she pleased him. Finally, one evening she could take no more.

"I'll tell you what we'll do," she told him. "Tomorrow I will do your chores and you will do mine."

"But you can't do my chores," the man replied. "You don't know the first thing about sowing, hoeing, and irrigating."

But the woman was adamant. And on top of that, she was filled with a righteous anger that frankly astonished and frightened the man to the point where he didn't dare disagree.

So the next morning the wife went off to the fields and the man began the domestic chores. After thinking about it, he had actually convinced himself he was looking forward to it. Once and for all, he would demonstrate to his wife how things should be done.

Unfortunately, not everything went according to plan. In fact, nearly everything the man touched turned into disaster. He spilled the milk, let the pig get into the house, lost the cow, burned the dinner, and ultimately set the house on fire, narrowly escaping with his own life.

When his wife returned, she discovered her husband sitting on a pile of ashes, smoke still rising from his clothes. But the woman wasn't the type to rub things in. She helped him up, wiped the soot from his beard, fixed him a little something to eat, and then prepared a bed of straw for them to sleep on.

From that day forward, the man never complained about anyone or anything else for as long as he lived.

At different points in my life I've played the role of both people described in this story, so I can speak from experience when I say that there's no shortage of people who know the best way to develop software. The problem, however, is almost always one of context. What might work for one context, is absolutely the wrong solution in another. You can almost never judge correctly without knowing the context and you can not know the context without being a part of the process.

There are a lot of things that make developing software hard. I don't believe writing well designed, high quality software is easy for anyone, especially not for us who work on Mac software at Microsoft. But the challenge attracts some amazing people, for which I am personally grateful. It makes what otherwise might be impossible, doable. When I share with you what work is like for me, it's because not everyone can work on one of the oldest, most successful and most used Mac programs around. I figure you will find it interesting because, well, how do you go about testing 30 million lines of code? :-)

Today we had a nice visit from Sal Soghoian and Todd Fernandez from Apple. Among other things we talked about what's new with AppleScript and Automator and what requests we had for improvements to both. After the meeting I gave them a quick tour of the Mac Lab. We have now upgraded to where we have over 300 Mac minis and over 400 Macs total all dedicated to running AppleScript test automation. I recall Sal saying, "I'm on a serious AppleScript buzz!" I'm willing to bet it's the largest "AppleScript installment" he's ever seen!

Consider the implications of our automation test lab: There's all the hardware costs: the Macs, the KVMs, the switches, the power, the cooling, the Xserves, the SQL servers. Then there's a whole Operations team that keeps everything going. Then there's a whole Tools team that writes tools of all sorts to help our small team of testers and developers scale and manage the complexity involved. Then there's my team, the automation team, tasked with making our automation story successful. All this for what? So that we can ship to our customers a super reliable, safe, high quality product, specifically tailored and designed for the Mac. If this doesn't speak to the focused effort we are investing in making Office 12 insanely great, I don't know what does.

Others may balk at the effort required to design, build and test Office for the Mac, and I don't blame them. I'd probably do the same if I didn't understand the magnitude of what is involved first hand. We've got lots great new features in Office 12, only one of which is the support for the new file formats. It's hard to really express the scope and scale of things sometimes, but the Open XML based file format has been published and you can find the full spec online. It's a PDF 3975 pages long! Read that and you'll have all you need to understand the details of the new file format. It's a good example of what I like to call serious, professional software development at a massive scale.

You may never be a part of a software project as big as Office, but not too long from now, when you're using Office 12 on your Mac or a freely updated version of Office 2004, you won't care about all the details involved with getting every bit in those 3975 pages of Open XML spec correct, you'll expect things, like a Mac, to "just work". We want that too, which is why we do, what we do.