General Tug

I recently listened to speech given by Lance B. Wickman which he titled Seasons. In this speech he recounts a remarkable story from his life.

---

When I graduated from college, I was commissioned an officer in the United States Army. I was an infantryman. After completing some training, in early 1965 I was assigned-with my bride of a few months-to an infantry battalion of the 25th U.S. Infantry Division at Schofield Barracks, Hawaii. My wife and I were thrilled with this assignment and looked forward to three years of life amidst the sun and the surf and the wonderful people of Hawaii. We rented a little duplex right on the beach on the North Shore of Oahu. You could step out of our back door onto the sand; it was literally like something out of a movie.

In October of that year, our battalion received a new commander, Lt. Col. Thomas U. Greer-“Tug” Greer, as his peers called him. Tug Greer was a graduate of the United States Military Academy at West Point, Class of 1951. In 1951, the Korean War was raging. Most of the West Point class that year was assigned immediately to the combat zone. Many of Tug Greer’s classmates died on the rugged slopes of that land. But Tug had survived and remained in the army. And now, 14 years later, he was assigned to command our battalion.

No sooner did he assume command, than Col. Greer took the battalion on a week-long training exercise in the rugged Kahuku Mountains of northern Oahu. For those of you who have not been to Hawaii, let me describe these mountains. They are steep slopes of volcanic rock with little topsoil and covered with thick, green vegetation. For five days, we struggled up and down those slopes in one infantry maneuver after another. Finally, it was Saturday morning, the last day of the exercise. All of us looked forward to returning early to our battalion headquarters, turning in our equipment and hitting the beach. After all, we were young, and what was the point of being stationed in Hawaii if you could not go to the beach! I remember gazing down early that morning from my perch on the side of one of those mountains at the shimmering sand and sparkling ocean. I could hardly wait!

About that time, Col. Greer came to our rifle company’s position. To our company commander, Capt. Jim Andrus, he said, “As the last exercise of this training, I would like Charlie Company (that was us-“C” Company) to establish defensive positions. Now, among other things establishing defensive positions meant digging foxholes. You know what a foxhole is. It is a hole in the ground where a soldier can seek shelter from enemy fire. But this was volcanic rock! And we were only equipped with those little folding shovels (which the army calls “entrenching tools”)! So, as Capt. Andrus gathered us platoon leaders around to give us the orders for establishing defensive positions, he said, “Since we want to get this over with quickly, we won’t actually dig foxholes. Instead, we will simply do “simulated foxholes”-we will just mark out on the ground where we would put the foxholes.”

So, that is what we did. A little while later, Col. Greer came around to inspect our “defensive positions”. I remember it like it was yesterday! As he came to the first of these “simulated foxholes”, he asked Capt. Andrus, “What are those?” Clearing his throat a little nervously, Capt. Andrus responded, “Well, sir, those are simulated foxholes.” “Simulated foxholes!” roared Col. Greer. “I ordered this company to prepare defensive positions, and that means digging foxholes! This company is going to stay out here and dig until it learns how to dig foxholes that look like the came out of the training manual!” And so, as the rest of the battalion packed up weapons and equipment and headed back to the base and an afternoon at the beach, Charlie Company remained out on that hillside. And we dug, and we dug, and we dug. Col. Greer’s name was on every one’s lips that afternoon, and I can tell you that he was not winning any popularity contests that day! But by evening, we had foxholes that really looked just like they came out of the training manual.

But, you see, there was something that we did not know that beautiful Hawaiian Saturday. When Col. Greer had been given his orders assigning him as our battalion commander, he had also received some other orders that he could not share with us-top secret orders-sending our battalion to Vietnam. We did not know it at the time, but this would be our last training exercise. And Col. Greer, with his vivid memories of his fallen classmates on the rugged hillsides of Korea was determined to do all that he could to save the lives of those men entrusted to his care. In a manner of speaking, Hawaii was the “season” for learning those skills that would save our lives. Vietnam would be too late.

What happened next I did not personally observe, arriving in Vietnam a few days after the rest of the battalion; but it was reported to me by my comrades-in-arms. They reached the spot in the division’s defensive perimeter assigned to our battalion late in an afternoon. Col. Greer’s order went out: Establish defensive positions. Our men dug in because that is what you did in Tug Greer’s battalion. Another battalion next to ours, arriving at the same time, only scooped out some shallow cavities in the ground-not unlike our Hawaiian “simulated foxholes”-planning to dig real foxholes the next day. But that night, the Viet Cong enemy launched a ferocious mortar barrage into the green troops. Our men were safe and secure in their foxholes; but the men of that neighboring battalion were not so fortunate. I am told that the next morning Tug Greer’s name was again on everyone’s lips-but this time with reverence and respect. I still regard him as one of the great men I have known. From him I learned one of life’s most powerful lessons: There is indeed a “time for every purpose under heaven”-even a time to learn to dig foxholes.

---

There are probably several lessons one could learn from this story. The questions that come to my mind are these: Who are those people in the software industry that might be like General Tug? Who are the people that have "been there, done that"? Who are the folks that can point to what really matters? Where are the sages of the software industry? Where are the mentors who are renowned for having wisdom that comes with age and experience? Am I the only person that has been caught in the illusion that what we are doing today is new and special? Maybe what makes the software industry so dynamic is not the remarkable speed of new developments, but the remarkable speed at which we forget.

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.

How to Talk to People

Don Norman has published a wonderful excerpt from his next book "The Design of Future Things" set to publish in October 2007. The excerpt is purportedly a research missive from future machines to other machines on how to deal with people. Certainly some of us lowly humans can relate to the difficulties of communicating effectively with other human beings. (We could also probably say some things about what it's like to communicate with modern-day machines.) What follows are some choice quotes from the article.

---

It isn't easy to communicate with them; people take suggestions as criticism and get defensive, and sometimes angry. They misinterpret our utterances, ignore us, or overreact. Sometimes we just can't win.

Five Rules of Communication From Machines to People

1. Keep things simple.
2. Always give people a conceptual model.
3. Give reasons.
4. Continually Reassure.
5. Offer a feeling of control.

People have difficulty with anything complicated, and they don't like to listen. So make the message short. In fact, it's better not to use language at all--it takes too long and, besides, human languages is horribly ambiguous.

The best kind of communication is done subconsciously, so people don't have to interrupt their conscious thoughts to attend to them. Thus even for the most befuddled minds, we need to communicate so that the meaning is clear.

Give them something their simple minds can understand. A conceptual model is a fiction, but a useful one as it makes them think they understand.

In short, people like pictures and diagrams.

Our early 21st Century Cars had almost given up trying to explain to people that they should drive more slowly on wet roads. But then we discovered that if we made it seem as if they were in trouble by faking skids and sliding around on the road, people would beg us to slow down. Sliding and skidding fit their model of danger far better than any words could have done. So wherever possible, don't try to tell them--let them experience it.

But the bottom line is, if people haven't seen anything happening for a while, they get anxious, even jumpy. And no one wants to deal with an anxious person.

[Make] them feel as if they are in control, even when they aren't. Keep up that deception--it's very useful. People like to be in control, even if they are performing a task really poorly.

Any time you have to make recommendations, make people think the ideas are theirs. If you really have to do something fast, just don't let them know: What they don't know, doesn't bother them.

---

There's some wisdom hidden in these quotes. Check out the whole thing, it's a fun read.

Update: Originally, I had some snarky, toung-in-cheek comments about each of these suggestions, but it just didn't come off like I wanted it and obscured too much of the real value in Dr. Norman's suggestions, so I've removed them.

Full Radio Silence on the Mac

I was just listening to the most recent Security Now Podcast episode 83 wherein Steve Gibson goes to pains to describe what it takes on Windows to turn off your wireless hardware. Here's an excerpt from the transcript:

STEVE: Believe or not, yes. We’ve basically snuck in an entire show on maintaining full radio silence on Windows WiFi.

LEO: Well, it started when we were talking about this Free Public Wi-Fi that pops up on Windows from time to time, and what it was, and how now Microsoft has offered a fix but never told anybody about it, and you have to explicitly download it. That’s what we talked about last week. And if you didn’t hear last week’s episode, you should absolutely download that update.

STEVE: Right. So that was our second mention. Then the week before, Episode 81, we talked about – we actually showed the dialogues required to turn off the functionality, just sort of this promiscuous connect-to-anything-that-I-hear, and also this idea of broadcasting the names of any networks you had connected to before, which by default Windows tries to do. It turns out that it’s trying to do that still, even after you’ve got the update, because Microsoft added a checkbox to one of the configuration dialogues which is checked by default, and you have to go turn it off. So here in our fourth serialized How to Get Wi-Fi Just to Shut Up, we have additional instructions. People can, if they go to the show notes for this Episode 83, I’ve got a link back to the new and enhanced instructions that are over now on Episode 81’s notes. So Episode 81’s show notes are enhanced with this additional information, and this episode links back to those.

LEO: So this is if you installed the patch that Microsoft offered in November to fix wireless zero config, it’s still promiscuous unless you uncheck this box.

STEVE: Yes. There’s a box which enables it to connect to networks which are not broadcasting. And so if the networks are not broadcasting, then your computer does. And it’s just like, okay...

LEO: Is this ad hoc only? Or is it infrastructure networks, as well?

STEVE: It’s both. And so anyway, the idea is – in fact, I realized, okay, I started using the term “maintaining full radio silence.”

LEO: Yeah, that’s a good way to talk about it, yeah.

STEVE: As the famous jargon. And that’s what we want. We want to be able to carry a laptop around. If we forget to disable our Wi-Fi, we don’t want it sending out stuff of any sort. We want full radio silence. And so it turns out that following the instructions that are now on the show notes for 81, with the update which we talked about in 82, which we’re all pulling together now in 83, when we first opened the topic in 80, we basically snuck in a whole Security Now! episode on maintaining full radio silence."

Here's a link instructions to the instructions from Security Now:

For details on "Maintaining Full Radio Silence" from Windows WiFi systems, please see the updated show notes for episode #81. They assume (and require) that the system has been updated with the Wireless Client Update for XP as described in episode #82 and notes.

If it's not clear, the step by step instructions for how to turn off WiFi are located at http://www.grc.com/sn/notes-081.htm

Because Steve didn't mention how to do this on the Mac, I think I'll take the liberty of providing a comprehensive guide complete with pictures, so you can follow along. This guide applies to at least the last 3 versions of Mac OS X. Here goes:

Step 1: Click the Airport Menu

Step 2: Select Turn AirPort Off

Steve was talking mostly about WiFi radio emissions, but since most Macs have Bluetooth these days, I thought I'd go a step further and document how to turn off Bluetooth radio emissions as well.

Step 1: Click the Bluetooth Menu

Step 2: Select Turn Bluetooth Off

In conclusion, if you are ever responsible for designing the "turn it off" use case, please consider the above mentioned comparison before completing your design.

Update 1: As a companion article, Joel Spolsky talks about the trials of turning off Windows Vista.

Update 2: It looks like I misunderstood what Steve was talking about. He wasn't talking about how to turn off WiFi, but how to keep the Windows WiFi system from broadcasting data about which networks you've connected to in the past. Does the Mac OS do this? I don't know.

The Cool Kids

Everyone has their own favorite language. Steve Rowe just pointed me to this funny my-language-is-better-than-yours graph. I found it really funny. I think Objective-C is just above C++ but below C. Where are you? ;-)

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!

Losing the Idea

Frank Shaw (who incidentally has one of the coolest named blogs ever) has a great post about how our impatience can get in the way of seeing the value of things. This is one of the reasons I'm in favor of people and processes that allow for ideas to interact. It's such a great post, I'm going to quote the whole thing here:

Here’s the question: What is more important, the idea, or the instantiation of the idea? Based on what I’ve been seeing/reading over the past year, it feels like we’re all losing the idea.

For example. Second Life – not that interesting. Not very many people, not great UI, business model challenges. Tons of hype – TONS of hype. And when SL vanishes, people will sniff and say, told you so. BUT. The idea – the idea behind SL, of a real platform for a virtual world, for robust commerce, ease of interaction, that’s interesting. It’s an idea worth pushing for, a dream worth having. Maybe the dreamers at Linden Labs will pull it off and make it real for everyone, but right now, we’ve missed the idea because of the focus on the example.

Or look at Wikipedia. Again, people are focused totally on the example, and not on the idea (Jimbo, I think, has the idea well in hand). Warts and all, Wikipedia has captured attention and created controversy. But by becoming the de facto example for all things wiki, it makes it easy for people (self included) to scoff and poke and mock when things don’t go well. If Wikipedia fades into the oblivion, people will say, well the idea was flawed. NO. The idea – harnessing the real wisdom of the crowds – remains as a beacon. When we focus too much on the company in front of us, we lose the idea.

There are tons of other examples – Digg, YouTube, Google. Each of these represents an “it” company of the moment, but behind each of them is an idea worth considering, regardless of the success or failure of the companies currently playing the lead role of the idea.

Why is it so damaging to lose the idea in the face of its current incarnation? Because some ideas take multiple instantiations to succeed, and if we summarily disregard the idea because of a flawed example, we run the risk of missing a huge opportunity.

As my dad always said, patience is a virtue. We’d all do well to be a bit more patient, and a bit more perceptive in our ability to applaud an idea and laugh at the current example.

This is why from an external perspective (investors, business managers), you need patience and internally (the people actually doing the work) you must have a steadfast determination to persist. Point me to anything that you might call innovation, and I'll point you to a version 2.0+ of an originally underdeveloped even laughable idea.

What's also interesting is that this is coming from a public relations guy! When you introduce something new, you almost always need to define it in terms of the past, in terms people already understand. (This is what makes things intuitive: they are like things you've experienced before, that you already understand.) Since folks, from CEOs to customers, are normally impatient, you need to use short words, quick explanations, simple concepts to promote a clear message, even if what's going on is much more interesting and subtle and even complex. This then, often has the very effect Frank is chafing against: It obscures the core idea while amplifying the current instantiation.

When considering a new idea, most normal people will have a "failure of imagination" that doesn't allow them to distill past the current implementation and see hidden therein a foundation for a future master work. If you find someone that can discern the core value of things and has the patience and courage to persist, hang on, because there's more than likely an explosive future just around the corner.

On Infrastructure

The following quote is from a long article on Toyota in the New York Times:

Improving efficiency in the factory, though, doesn’t necessarily lead to greater profits. Savings on the assembly line can mean a nicer dashboard without making the customer pay more for it. “If you’re efficient in the things the customer doesn’t see, then you can put it into the things the customer does see,” Ron Harbour, a consultant whose company rates the efficiency of auto plants, told me. A result is a car more popular with customers. Success on the assembly line, in this way, begets success in the showroom.

For me, this best describes the business case for choosing Cocoa as your application framework for Mac applications. This is not to say that you can't write terrible Cocoa applications. You can, to be sure, but in general the APIs, the design patterns, even the style of the code subtly try to keep you from rebuilding things that have already been built. Many of the programming idioms try to get out of your way and "do the boring stuff" so that you can spend time adding value that the customer actually sees.

If you are always spending time working on the guts of your application, especially the parts that the user doesn't directly interact with, there's often little perceived value in the work you are doing. If you are all of the time "platform building", it's easy to loose sight for what the platform is being built to support. Don't get me wrong, I'm a big fan of infrastructure work, I've spent most of my professional career doing it. However, it's absolutely critical to see the connection from the work you do to the customer value. This is why a good user interface is so important. This is why a good application programming interface is so important.

On the other hand, if you are working with people that watch out for the schedule and bottom line and you propose an infrastructure improvement, immediately you will, or should be, accosted with pointed questions about cost, time and customer value. All of these are very good things to discuss, but when you do discuss them, you must not forget the long term impact of the work you do. If you're only going to be there for one version of the software, then maybe the near term results are all you care about. There are as many shortsighted programmers as clueless business men, but I think the real answer is that working on improving the guts, the engine, the non-visible, un-photoshopable parts of your application are the long term the "critical path features" that will allow for money and time to be spent on the high customer impact features of version n+1.

Toyota’s executives recognized early on that improving the process by which cars are designed and built is just as important as improving the vehicles themselves.

You've got to have both, but if you only ever focus on what the user sees (and this is easy to do!) eventually, your application will collapse under its own weight. What I'm trying to discribe might be the best business case for the model-view-controller design pattern. How does this apply to Cocoa? Sure, you can build an app using the model-view-controller design pattern without Cocoa, it's just that with Cocoa, you just fall into doing the right thing long term, even if you don't quite know why.

Welcome to 2013

Every once in a while me and some of my buddies will get together for lunch to prognosticate and pontificate. The "rules of engagement" are that you argue the future of technology with the assured confidence of Steve Jobs, while still being nice. ;-) Today, you won't get the laughs, the jeers, the oohs and aahs or even the subtle interplay of the multiple ideas and feelings as we sit around the table and guess about the future, but you will get part of my view of things and you'll just have to imagine the rest. So with that preamble, let me start with what the world looks like in 2013:

To begin with everyone has at least one, but most have two, 30" displays at work that support multi-touch and have embedded hi-res cameras. Screens haven't grown much taller, but they will have grown wider. People carry around their iPhone on which resides all their digital assets. They walk up to a workstation and "plug in" to run all their customized programs and data coming off their phone. Laptops still dominate, because, well, they have a keyboard and mouse that work, but they are the peripherals of the phone, the iPod, the communication device, not the other way around.

The user experience isn't just about being pretty and functional anymore, it's about making the work you do fun, in a very game-like almost surreal kind of way. Of course it's efficient, because it's fun to be successful at what you do! But it's not just about being efficient anymore, it's about being beautifully efficient and deeply effective.

In this world of 2013, all desktop applications, as we know them, continuously bounce back and forth between two states: fully online, and partially offline. While all the user's data is stored on their local device (read their iPhone), they know that when in range of any wireless signal, their data is being securely and automatically backed-up and kept in sync up with all their other peer devices. Normally this is the cloud for down-level, but always accessible access, their home and work computers, their entertainment center and car and of course their iPhones. Yes, most people will have one "work horse" iPhone and another smaller, lighter, "more invisible" if you will, model.

Documents are far from dead in this environment, but they are more dynamic, they are less the end, but the vehicle for the process of learning and discussion. The standard way to transmit rich but static read/only documents will continue to be PDF. Word processing will move to be more about design and layout than about text macros, spell checking and print out. PowerPoint presentations become less about bullet points and more about data visualization. Excel workbooks finally take on embedded SQL back-end for deep data-sets. This simultaneously thrills regular users who always knew Excel was a database, while frustrating DB admins worldwide. Excel "views" on to any data set auto syncs back up to and around with other people and servers. PowerPoint presentations include Bonjour enabled real time text chats on the presentation's "side screen" if enabled for the presentation. The typical method for connecting to a HD presentation display is simply connecting your phone to the projector and driving the phone with the button on your phone's headset over a secure wireless connection. Your headset will also record your presentation for later automatic transcriptions or playback.

Email and News isn't so much about "getting to done" and reading all the email and news coming your way. It's much more about training your "inbox aggregator" to sense the signal in the noise. Which people and sources consistently produce high signal work will be the basic factor. Your work will be to both broadcast so that people will want to subscribe to your data-out-stream, but also aggregate the common themes coming in. Spark-like, the software will identify the new, the novel and out of the ordinary. Analysis of your reading, response times, collaboration habits, phone calls, even tracking your focus on the screens will help the system to make connections and inferences and your projects and priorities will there by emerge. The complex patterns over time will create a data set that you can both tag with good and bad behaviors which the system can use to help you do more "good things" and fewer "bad things." When the system senses you are "in the zone" phone calls, IMs, even background applications fade from view allowing your to focus and really think and really produce. This kind of pattern analysis will be done both locally as well as in the cloud. The system learning will happen in both places.

Help systems will be much more user developed, driven and updated with a few mavens driving the core content. Person to person personalized help will emerge: This is where you can call someone and get a personal response in your own language, from the same support person you have grown to like, within 24 hours. The help system extends beyond just using an application, becoming more like a workflow analyst and personal coach. Help systems well done become a modest profit center for those few companies who figure out how to serve personally, not just quickly. This premium help service becomes something people love to pay for, because of the way it helps them directly improve their day to day work. Think of it as life hacks, evolved and distributed.

Software updates and personalization of software on the fly will mimic and then surpass the current web based model. Users will be able to log feature requests directly in the applications they use. Developers will be able to respond in aggregate or individually. Web apps will support roll forward upgrades, while desktop applications will support seamless roll forward upgrades and roll back downgrades. The roll back ease will allow for people to bravely try out new features in newer versions without the risks of all our nothing upgrade decisions. When a bug or feature they requested is fixed or something similar added to a new version of the application of which they don't have, they will be notified. Think of it like out of band email feedback and support, or like FogBugz stuffed into each application you own.

Video conferencing will be available most places and no one will use it except for one to many lecture style communication. What they will use is screen sharing, document sharing and white board sharing while high quality audio, text and data sharing collaboration will be the norm. Conversations will naturally move from audio, to audio and text chat, to screen sharing, to document editing to white board sketching and back to basic text all with the effort of adding a new party to a conference call on the iPhone. Even with all this communication technology, person to person visits will remain he most effective form of collaboration. As such, most systems will tend to lead you from lower communication models to higher communication models, given your particular context.

User interfaces will provide greater affordances for the human user. Not just skins and layout changes, but reading text summaries into audio files to be processed and listened to while moving from place to place. Reminders to get up and stretch, take a break. Zooming in and especially zooming out spatially will help people not only to read better as they age, but to step back and gather greater context, then focus in on the most important information or task. Audio will be used slightly more to provide feedback, but displays that can "thump" or provide force feedback when touched will also allow for better interactions. Where today we use "if statements" then we will use Bayesian probability in making our decisions.

The most important aspect of software design will be the answer to this question: How can we optimize this experience such that the things humans are good at are made easy, fun and amplified, while the things humans are generally poor at are made automatic, simple, out of the way, multi-tasked, yet controllable, abstractly knowable and understandable.

In this world, technology will not be the enabler or even the competitive advantage. In 2013, technology will be the raw material upon which and out of, much of life's daily work and play will be built. In 2013, people will have gotten over technology, less will be the worship of technology as some magic cure all, more the understanding of technology like a bicycle for the mind, the heart, and even the soul. And so here's to a softer time. A time when the real world, not these virtual intellectual properties, but the actual world around us takes preeminence once more.

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.

In demand

Ever laconic Seth Godin posts on what he sees in demand these days:

We don't need pilots. We need instigators and navigators, rabble rousers and innovators. People who can't follow a checklist to save their life, but invent the future every day.

I don't think Seth really understands what it means to be a great airplane pilot, but what he's trying to say is right. There was a time when folks who could do the "cog work" (e.g. follow this procedure, the same way, every time. etc.) were valued, but not any more. Moving away from the front line, I might say, what we need are leaders, not managers.

On the hive mind and the wisdom of crowds (or the lack thereof) Steven Johnson of the New York Times summarizes:

A swarm of connected human minds is a fantastic resource for tracking down software bugs or discovering obscure gems on the Web. But if you want to come up with a good idea, or a sophisticated argument, or a work of art, you’re still better off going solo.

There will always be a premium on creativity. You just can't engineer that. It's a human thing. There are problems you can solve with money, but being creative isn't one of them.

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.

The Cost of Focus

I just read this by Michael Bolton on testing, but I think it has more general application:

It occurs to me this evening that when test plans, test scripts, and testers look for particular problems with excessive focus, they do so at the expense of peripheral vision.

Contrast that with what Adam Richardson says about the importance of peripheral vision:

Bill Bradley is today known primarily as a politician in the US, but in his youth he was an outstanding basketball player. Among several notable abilities, he had a natural gift: his eyesight. Specifically, he had abnormally good peripheral vision. Whereas normal peripheral vision covers a horizontal field of 180 degrees, his covered 192 degrees - he could literally see behind himself. Vertically, most people can see 47 degrees upward while looking straight ahead. Bradley could see 72 degrees, meaning he could see the basket even when looking at the ground. These factors gave him an ability to see things on the court that others could not, and detect threats and opportunities earlier than others players. (For a nice essay about Bill Bradley, see this book by John McPhee.)

Peripheral vision is an interesting thing: it provides much less detail but much more sensitivity to movement than our central cone of vision (which is only about 7 degrees in diameter). Peripheral vision is essential when you’re in the jungle or on the savannah, spotting movement at the edges that indicate danger. But our medical tests for eyesight pretty much ignore peripheral vision, focusing instead on how much small detail you can resolve in your central cone.

Business analysis is often the same way. Movements at the edges that are ill-defined are ignored, and all tools and attention are focused on what we can see clearly with great detail that's right in front of us. But it’s the movements at the edges that can both be the most threatening, but also represent the new opportunities. This is where the disruptive innovations that Clayton Christensen talks about come from. By the time you can prove their existence in detail, it’s too late.

Wicked problems are very difficult to understand by staring straight into them and looking for clear detail, however. They need to be approached from the edges, sort of like doing a jigsaw puzzle where you find the edge pieces first. Having peripheral vision that is trained to be sensitive to the edges is a key capability (this applies both to product teams and to business units - wherever wicked problems occur).

So encourage staff and managers to pay attention to and nurture their peripheral vision - meeting with their “whacky” customers who push your products to the limit, talk to people who aren’t your customers any more and find out why, and pay close attention to disruptive innovators making cheap and “poor” products that your traditional customers wouldn’t touch. And if you think you're facing a wicked problem, don't expect hard numbers on it; by the time you've got solid data, it's probably too late.

Balance and timing once again seem to be the issue here. Focus, but not excessively otherwise you'll loose valuable peripheral vision which you'll need to find the next great ideas to focus on. It's often the free radical ideas that lead to the innovative idea. And if you are too focused, you'll miss them.

Something Great

Consider this summary of the story of a horse named Snowman by Joseph B. Wirthlin:

Harry de Leyer was late to the auction on that snowy day in 1956, and all of the good horses had already been sold. The few that remained were old and spent and had been bought by a company that would salvage them.

Harry, the riding master at a girls' school in New York, was about to leave when one of these horses—an uncared-for, gray gelding with ugly-looking wounds on its legs—caught his eye. The animal still bore the marks that had been made by a heavy work harness, evidence to the hard life he had led. But something about him captured Harry's attention, so he offered $80 for him.

It was snowing when Harry's children saw the horse for the first time, and because of the coat of snow on the horse's back, the children named him "Snowman."

Harry took good care of the horse, which turned out to be a gentle and reliable friend—a horse the girls liked to ride because he was steady and didn't startle like some of the others. In fact, Snowman made such rapid improvement that a neighbor purchased him for twice what Harry had originally paid.

But Snowman kept disappearing from the neighbor's pasture—sometimes ending up in adjoining potato fields, other times back at Harry's. It appeared that the horse must have jumped over the fences between the properties, but that seemed impossible—Harry had never seen Snowman jump over anything much higher than a fallen log.

But eventually, the neighbor's patience came to an end, and he insisted Harry take back the horse.

For years, Harry's great dream had been to produce a champion jumping horse. He'd had moderate success in the past, but in order to compete at the highest levels, he knew he would have to buy a pedigreed horse that had been specifically bred to jump. And that kind of pedigree would cost far more than he could afford.

Snowman was already getting old—he was eight when Harry had purchased him—and he had been badly treated. But, apparently, Snowman wanted to jump, so Harry decided to see what the horse could do.

What Harry saw made him think that maybe his horse had a chance to compete.

In 1958, Harry entered Snowman in his first competition. Snowman stood among the beautifully bred, champion horses, looking very much out of place. Other horse breeders called Snowman a "flea-bitten gray."

But a wonderful, unbelievable thing happened that day.

Snowman won!

Harry continued to enter Snowman in other competitions, and Snowman continued to win.

Audiences cheered every time Snowman won an event. He became a symbol of how extraordinary an ordinary horse could be. He appeared on television. Stories and books were written about him.

As Snowman continued to win, one buyer offered $100,000 for the old plow horse, but Harry would not sell. In 1958 and 1959, Snowman was named "Horse of the Year." Eventually, the gray gelding—who had once been marked for sale to a low bidder—was inducted into the show jumping Hall of Fame.

For many, Snowman was much more than a horse. He became an example of the hidden, untapped potential that lies within each of us.

For me this story is both inspiring and challenging. Inspiring, because it makes me think I can do something really great. Challenging, because I don't know what that is exactly. Of course, everyone has their different ideas about what constitutes "something great", but more and more I'm starting get an idea. I've always loved this quote by Jenkins Lloyd Jones:

“Anyone who imagines that bliss is normal is going to waste a lot of time running around shouting that he has been robbed.

“[The fact is] most putts don’t drop. Most beef is tough. Most children grow up to be just people. Most successful marriages require a high degree of mutual toleration. Most jobs are more often dull than otherwise. …

“Life is like an old-time rail journey—delays, sidetracks, smoke, dust, cinders and jolts, interspersed only occasionally by beautiful vistas and thrilling bursts of speed.

“The trick is to thank the Lord for letting you have the ride"

And then M. Scott Peck in The Road Less Traveled:

Life is difficult.

This is a great truth, one of the greatest truths. It is a great truth because once we truly see this truth, we transcend it. Once we truly know that life is difficult – once we truly understand and accept it – then life is no longer difficult. Because once it is accepted, the fact that life is difficult no longer matters.

Most do not fully see this truth that life is difficult. Instead they moan more or less incessantly, noisily or subtly, about the enormity of their problems, their burdens, and their difficulties as if life were generally easy, as if life should be easy. They voice their belief, noisily or subtly, that their difficulties represent a unique kind of affliction that should not be and that has somehow been especially visited upon them, or else upon their families, their tribe, their class, their nation, their race or even their species, and not upon others. I know about this moaning because I have done my share.

Life is a series of problems. Do we want to moan about them or solve them?

I suppose I'll finish this way: I've been feeling very thankful these last few days. Thankful for my job and the people I've been able to work with over the years. Thankful for the enormous challenges we get to tackle and the support I've been given from so many people, not the least of which has been my family. So many times, things could have really turned out bad, and they didn't. And then some times they did, and we worked through that too. So, maybe that is something great, sustained effort toward worthy goals. Either way, I sure am learning a lot.

Coding Blogs

This is part 3 in my "Blogs I Read" series. I hope you find it useful.

ADC Headlines - Apple - Feed

I find it really useful to keep on top of the new documentation that is added to Apple's Developer Connection website. I'll often find something new I didn't know, but mostly just seeing a "how to" or bit of sample code is enough to jog my memory when I come up against a similar problem.

Big Nerd Ranch Weblog - Big Nerd Ranch Folk - Feed

The Big Nerd Ranch started as a week long immersive training experience in Atlanta, Georgia. You focus on code intensely and remotely. The one fee covers food, lodging, transportation to and from the airport. It looks like they now have a "ranch" setup in Rome, Italy. I subscribe mostly because, well, I'd like to attend there the Cocoa training some day. Also, I think it's a great idea for helping people focus. I've heard that out on The Ranch, there's no internet connection and poor cell phone reception. It's amazing what cutting out distractions can do for a learner's capacity to gain understanding. I've been to a lot of training, but nothing like this, so I guess it really appeals to me. To top it all off, Aaron Hillegass author of arguably two of the best Mac OS X programming books, is one of the Cocoa instructors there.

Cocoa Dev Central - Scott Stevenson - Feed

This is my favorite learn-about-Cocoa site. Scott Stevenson has a clean, clear style and knows how to remove the unnecessary details making his Cocoa tutorials content-dense and easy to read. The site is well designed and just looks great and I admit, for me, that counts. It is really a one stop shop for learning about Cocoa for the beginner and advanced developer alike.

Mac OS Forge - Apple - Feed

What can I say here? I'm interested to see if Apple can make their second try at open source community work. I hope they can figure it out.

Mac OS X Internals - Amit Singh - Feed

Amit has been publishing extremely interesting and low level details about Mac OS X since at least 2003. I've always enjoyed his writing and recently he published a book named Mac OS X Internals. He doesn't post very often, but when he does, it's always worth the read. One of the main reasons I value Amit's writing is the way he contrasts and compares the Mac OS with other operating systems. If OS level stuff interests you, you'll love this blog.

Martin Fowler - Martin Fowler - Feed

Martin Fowler has been around for a long time, so his seasoned opinion holds a lot of weight for me. Seems like I am continually discovering "new" ideas and programming or computer science concepts that were discovered 20 years ago! He talks about software architecture, object-oriented analysis and design, refactoring, Unified Modeling Language, software patterns, and agile software development methodologies.

TextMate Blog - Allan Odgaard - Feed

And speaking of old ideas revisited, Allan has taken ideas from the venerable emacs command line editor and put and UI on them and then added some great new ideas of his own. Just when it seemed like BBEdit had the whole text editor market tied up, along comes TextMate and really ups the innovation ante. I'm a fan because: 1) I'm learning about the editor and the blog often shows me how to do stuff I didn't understand before and 2) I love rooting for the underdog. :-) If you spend a lot of time editing text on a Mac, you've absolutely got to check out TextMate.

World Usability Day

I just found out that today is World Usability Day, and I couldn't help from laughing at the poster. Yeah, usability really matters. Enjoy. :-)

The Anatomy of Peace

I recently listened to a BYU Devotional in which LDS Church President Gordon B. Hinckley simply related from his life "Experiences Worth Remembering." One of the last experiences he shared was this:

I had a long remembered experience with Mr. Shimon Peres of Israel. He was a former Prime Minister. He had seen much of conflict and trouble in his days. I asked him if whether there was any solution to the great problems that constantly seem to divide the people of Israel and the Palestinians. He replied, "Of course there is!" As I recall he said, "When we were Adam and Eve we were all one. Is there any need for us now to be divided into segments with hatred for one another?"

He then told an very interesting story that he said he had heard from a Muslim. The Muslim told of a Jewish Rabbi who was conversing with two of his friends, the Rabbi asked one of the men, "How do you know when the night is over and a new day has begun?"

His friend replied, "When you look into the East and can distinguish a sheep from a goat, then you know the night is over and the day has begun."

The second was asked the same question. He replied, "When you look into the distance and can distinguish an olive tree from a fig tree, then you know morning has come."

They then asked the Rabbi how he could tell when the night is over and the day begins. He thought for a time and then said, "When you look into the East and see the face of a woman and you can say, 'She is my sister.' and when you can look into the East and see the face of a man and can say, 'He is my brother.' then you know the light of a new day has come.

I'm currently reading a book named The Anatomy of Peace from which I chose the title for this post. One of the ideas presented is that when we treat people as objects, we are at war with them and bad things happen. When we start to see others as real people, not objects, the whole world changes before us.

Like so many things, it's simple, but very hard to do.