By Example

Microsoft's recent introduction of Live Mesh is a perfect example of a core difference between Apple and Microsoft. Apple is, at heart, a product company. Microsoft is, at heart, a platform company. Both produce products and platforms, but the way they approach the problem and communicate with developers is decidedly different.

With Live Mesh Microsoft says, "Come, build on our platform and do amazing things!" What is the oft cited example for using Live Mesh? Multi-device synchronization of data. Now, to be sure, this is a big and very hard problem to solve. In fact, I really wish Apple's Sync Services were much, much better, but do you wake up in the morning thinking, "Man, I really have a Multi-device synchronization problem?" Most people don't. What they do think is, "Man it's great that when I put stuff on the web, I can get it wherever I am. All I need is a web browser." You see, syncing folders or sharing data across devices isn't top of mind in the way a developer thinks about it. Microsoft's challenge is mapping their platform to real problems in a persuasive way.

Contrast this with Apple's normal product focused pattern. First they release a product that solves a real, tangible problem people have. Say, "I hate it that I have to carry around my iPod and my Cell phone everywhere!" or "Man I wish I could buy that cool song I just heard, right now." or "I have so many digital photos, I wish there was an easy way to do something cool with them." or "Man I hate it when I loose files on my computer, I wish I could just go back in time." To solve these problems Apple, like Microsoft, has to build a platform, but this platform is built for a product first, which they use and improve. Then when they talk to developers they can say, "Did you see this cool thing we just did? You can do the same thing or even something better! Here's how we did it..." It's the difference between saying, "Here are the tools, let me show you how to use them." and "I used these tools to do this great thing. Let me show you how and maybe you can do the same thing." Ultimately, it's leadership by example.

Another great example is Apple's use of the Cocoa APIs in their own applications. Apple builds amazing products and then is able to say to developers, "We used the same APIs available to you today!" Contrast this again to Microsoft. Windows Vista was released with some remarkable new C# APIs. Many of them very cool and very interesting, but what is Microsoft Office written in? C and C++. What APIs does Office use? A multitude of Office only APIs and libraries shared among the applications. Does this hurt C# and the new "WinFX" platform "street cred"? I think so.

Ultimately, Apple and Microsoft are trying to solve many of the same problems, but the path you choose while logical to you, may not be so logical to those you most need to persuade and inspire. No one can argue with the results. For me Apple's "solution first, platform second" approach makes for easy understanding of new ideas as well as providing the activation energy needed to try something new.

Heuristically Thinking

You don't have to understand calculus to appreciate this entertaining story:

A teacher, trying to explain what a theory is, asked this question: “If you take a letter half the distance to a mailbox and stop, then start over going half the remaining distance and stop, then repeat the process over and over, theoretically will you ever really get to the mailbox?” One bright student said, “No, but you’ll get close enough to mail the letter.”

There are many definitions for what a heuristic is, but the one I like best is illustrated in this story. A heuristic is "close enough." I am beginning to believe that more and more what matters in software isn't so much building the perfect algorithms, that match and mimic real life in every way and hold up in every edge case. What matters most is getting a model that comes close enough. What matters are heuristics.

My favorite chemistry textbook, has this to say on the topic of "The Kinetic Molecular Theory of Gases" (KMT):

However, although laws summarize observed behavior, they do not tell us why nature behaves in the observed fashion. This is the central question for scientists. To try to answer this question, we construct theories (build models). The models in chemistry consist of speculation about what the individual atoms or molecules (microscopic particles) might be doing to cause the observed behavior of the macroscopic systems (collections of very large numbers of atoms and molecules).

A model is considered successful if it explains the observed behavior in question and predicts correctly the results of future experiments. It is important to understand that a model can never be proved absolutely true. In fact, any model is an approximation by its very nature and is bound to fail at some point. Models range from the simple to the extraordinarily complex. We use simple models to predict approximate behavior and more complicated models to account very precisely for observed quantitative behavior. In this text we will stress simple models that provide and approximate picture of what might be happening and that fit the most important experimental results.

The textbook then goes on to explain postulates for this model of thinking, many of which by themselves are absolutely false, but taken together and used properly, they create a system of thinking that works for a wide range of situations. This collection of half-truths produce a half-truth baked solution, absolutely, but one that is indeed close enough.

For example, some "half-truths" or "simplifications" if you will, involve assuming things like: each molecule of gas is perfectly spherical in shape and any collision is perfectly elastic in result. Or worse, the volume of all these individual molecules is assumed to be zero! Individually, each of these 3 statements is categorically false, but they were the right bits to "design away" as they defined the problem space so that the model could be simplified, made useful and the problem of dealing with billions of particles be made into something tractable.

To me, this is more than simple object oriented encapsulation and abstraction. This is thinking about the whole problem differently. It's about looking at individual behaviors from a very small sample and knowing, by some spark of genius, which attributes are the important ones to the ultimate outcome of the system as a whole, and which are not. This is writing software that is able to predict things, for example, test software that is able to predict when "something good" has happened and also when "something bad" has occurred. This is about designing software by building software models that categorically do not reflect the real complexities of the system, but that taken together, get "close enough" to do real work in the real world. Ultimately your models will fail when pushed to the limits, but even just understanding those limits will help you better understand the problem you are tasked with solving! It even begs the question: What kind of programming language best allows for the definition and use of heuristic models?

I don't know where I first heard this, but someone once said something like, "Where Microsoft codes if statements, Google codes in Bayesian probabilities." There are more data and variation in that data than there ever was before. If you are going to write or use programs (very likely) that deal with large amounts of data (also very likely) it might be a good idea to get used to thinking about things in heuristic terms. It may not be exactly perfect in every case, but it will be close enough.

Finishers Wanted

When I was a little boy my Mom had me memorize this little poem:

Stick to your task ’til it sticks to you;
Beginners are many, but enders are few.
Honor, power, place and praise
Will always come to the one who stays.

Stick to your task ’til it sticks to you;
Bend at it, sweat at it, smile at it, too;
For out of the bend and the sweat and the smile
Will come life’s victories after a while.
—Author Unknown

I think my Mom had me memorize this poem because she knew I would need it. She understood better than I the old adage that "Life does not reward us for effort expended." Finishing is required.

For me, it is exciting to find a problem and imagine a way to solve it. The creative exhilaration in coming up with a solution that will work within all the constraints involved is almost intoxicating. I have a remarkable tolerance for ambiguity and when the major "problems" as I see them, have been solved, filling in all the details seems so much less important. The hard design work has been done. There's perhaps little glory in all the simple, small and detailed work needed to connect the dots and make the grand vision a reality. However, software is ultimately just simple 1s and 0s and if you don't fill in all the details, then all you are left with is a dream. You've got to have both the vision and the finishing of all those tiny details.

"This is all your app is: a collection of tiny details." - Wil Shipley

Missing a few details can drastically reduce the value of the whole idea. I guess that's why I love Mac software so much: There's the constant demand from both the users and my peers for my concerted effort across the entire spectrum of "pie in the sky" ideal to actual, practical details in implementation. To make it work in software, you need to consistently execute well across the whole spectrum of work. Let me underscore the words consistently execute again, they are very important.

Matt Ball recently wrote a nice post about some up and coming Mac developers that worked so hard on their first release, but since then have produced relatively little. They haven't created new apps, updated their 1.0 apps, even posted to their blogs. Some still have ideas in picture form posted in all their high fidelity glory, but with no application to show or sell to the customers that have been waiting to see the finished product. These developers seem to be struggling with consistently executing against their plans.

Matt goes on to explain that he thinks this is related to their young age. Most of these developers are young (19 years old) and he thinks suffer from some kind of "shiny ball syndrome" where they are easily distracted from one project to the next. I don't know the developers, and they could be easily distracted or they could have absolutely justifiable reasons for their delays, but the result is the same: Doubt builds as to their ability to consistently finish their ideas. Their credibility and reputation weakens.

Many of life's failures are people who did not realize how close they were to success when they gave up. - Thomas Edison

I don't think it's age. I think that's far too simple an answer. I know developers in their 50s who struggle from this exact same problem. It's not size or lack of resources either. Look at Microsoft. Here's a company where a large part of their problems revolve around consistently producing, not a lack of money or great people or innovative ideas.

The idea is not the thing!

One part of the problem comes from patent law. There is a remarkable and universally held assumption that ideas are worth a great deal. I will not say ideas are worthless, but they are worth far less than most of us realize. Even the most simple idea takes remarkable effort, and follow through to get designed, built, packaged, and ultimately used by others. This is why I felt My Dream App was destined for difficulty. They had enthroned ideas as the product, when in reality it's all the grunt work after the idea that make the product. It's all those pesky little details and the consistent effort required to follow up and deal with each of them that matters.

Finishing is the thing!

When the iPhone was released, there was a collective groan world wide from designers who had years before envisioned the ideas that Apple had now so beautifully produced in a finished product. Kim Lenox, Senior Interaction Designer of Adaptive Path explains:

With the launch of the iPhone, I’ve been hearing many grumblings from interaction designers who’ve worked for various, well known consumer electronics companies. We can all see in the iPhone aspects of our concepts from years past that were brushed aside or died prematurely. Our concepts are suffocating under the pile of NDA verbiage, never to see the light of day. What sets our mere concepts apart from this final product however, is a company with leadership who has the fortitude to take the risk, find the budget, and push the technology for the single cause of designing compelling user experiences. Apple got it right.

Amazing isn't it? Once again, it's all about execution and finishing, not just the ideas. Leadership is important for sure, but finishing the job in a company is so much more than Steve Jobs simply saying, "We're going to build an iPhone and it will have a compelling user experience." It's thousands of decisions made by hundreds of employees at Apple and elsewhere. It's dealing with setback after setback and still pushing forward. It's taking the right calculated risk (EDGE and AT&T) and saying no to other things (10.5 on time, a Dev SDK) in order to finish. That is the task of finishing and at Apple, it seems to be part of their DNA.

Tranquil and Steady Dedication of a Lifetime

One of the most important attributes of a software company I would like to work for, comes from an idea the late Adlai Stevenson a U.S. Democratic politician explained when referring to patriotism:

What do we mean by patriotism in the context of our times? I venture to suggest that what we mean is a sense of national responsibility ... a patriotism which is not short, frenzied outbursts of emotion, but the tranquil and steady dedication of a lifetime.

In a great software company, there wouldn't be "short, frenzied outbursts of emotion" but a consistent focus on finishing in a steady and sustainable manner. My guess is that those prone to "putting on a big, glitzy show" and those that don't effectively resist the "constant bombardment of new and exciting things to try out" will have set themselves up as an unsustainable business, and ultimately end up disappointed.

Saying No: a feeling of strength in reserve.

One of the biggest challenges is just saying no to things. What's hard about this is often you need to judge between what is "good", what is "better" and what is "best". In order to do that which is "best", you will, you must say no to many, many things that are "good" and "better". This is heart wrenching work, but choosing what you do now to remain focused and finishing, this is your competitive advantage. When asked what work he was most proud of from among his work at Apple, Steve Jobs famously said, "All the products we didn't ship." Many people and businesses talk about focus and priorities, but very, very few actually finish the idea and follow through with the well executed decision making and focus required.

“You must always work not just within but below your means. If you can handle three elements, handle only two. If you can handle ten, then handle five. In that way the ones you do handle, you handle with more ease, more mastery and you create a feeling of strength in reserve.” - Pablo Picasso

Keep Moving Forward!

There is a scene in Disney's animated movie Meet the Robinsons that I love. The story is of a young boy inventor who is learning. During this particular scene he is trying hard to fix a peanut butter and jelly gun, used to automate sandwich building. Everyone is watching him and it looks like he's going to succeed, finally the time comes to try his fix. The whole thing explodes sending peanut butter and jelly everywhere and onto everyone in the room. He is devastated, but immediately he hears cheers and people start to comment on what a great failure that was! "You Failed!" "And it was awesome!" "Exceptional!" "Outstanding!" "Uh, I've seen better." "From failing you learn, from success, not so much." They congratulate him like he succeeded. They ultimately propose a toast to his brilliant failure. He is stunned. The motto of this family is: Keep moving forward!

This is a good motto for anyone working with software. The challenges are so great and the problems so complicated and frequent, you simply must have the determination to keep moving forward, to and through the finish. Start small and build momentum and keep finishing small things, just to keep in the habit of it.

This is not always easy. Sometimes I would come home from work so frustrated with how slow things were going and how little progress was being made, I'd tell my wife I just needed some time alone to cool down. I'd go into my room, open my laptop and write a blog post. I'd post it and point to it while saying to my wife, "There, I did it. I produced something today! It may not be much, but at least I produced something tangible!" You've got to keep in the habit of producing or finishing. You can't let those muscles atrophy.

One of the best development techniques I've seen over the years is test driven development. The pattern is to build a small test that represents an improvement you want to make to your program. Once the test is built, run it and watch it fail. Then write just enough code to make the failing test pass, then run the code and watch the test pass. Repeat. This tends to lead to low coupling and good cohesion and a reasonable test bed. The real hidden value is regular focus on tangible completion in a consistent way, over time. Just keep moving forward step by step and then after some time you'll be impressed as you look back on the mountain of work you've accomplished by such simple means with constant effort.

There are bugs to be fixed, old code to re-examine and refactor, performance problems to analyze and improve, build automation, test automation and website improvements, help docs to write, blogs to read, posts to write, ideas to explore, customers to contact, emails to read and write. Your job is to choose which of all of these you will do now, and then keep moving forward. Those who master the art of consistently and sustainably producing value, are setup for success. Be one of them. Don't quit. Don't stop. Focus on consistently finishing something of value, no matter how small. That's what the world will pay you for, and since so few seem to stick to it, there's plenty money in play for those who pay the price to consistently finish the job.

Leaving Microsoft

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

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

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

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

Happy New Year to all and wish me luck!

Workspace Traditions

Every company, every team has their different traditions and specific culture and Microsoft is no exception. Christian Buckley of BlueBadgeMojo.com pokes some fun at what I think is a Microsoft specific tradition of "decorating" offices of people gone for an extended period of time. I remember carting in sand for a "beach house" office decoration way back. Where did it all start? I guess I'll never know.

What funny workspace traditions do you have? Have you seen the office decoration thing outside of Microsoft?

Numbers

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

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

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

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

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

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

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

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

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

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

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

Be Microsoft

I love working on the Mac. I enjoy working in MacBU. These days, however, I'm not so thrilled about the vibe hanging around here at Microsoft as a whole.

We seem to have lost our self-confidence. There is a general and constant focus on "the other guys" these days. It's like everyone is continually contemplating competitive response, rather than acting for our customers. First it's open source software, then it's Linux, then it's Google, now it's Apple. Tomorrow it will be something or someone else. Least someone misunderstand, I'm all for looking out for the competition, but if all your focus is on how to respond to some perceived or real competitive threat, how will you ever be able to innovate, come up with something original or surprise and delight your customers? It's just paralyzing.

I wish folks would just realize that we are not going to be all things to all people. That's okay. We've got a job to do, and we have a very reasonable opportunity to do some very wonderful things. Let's stop worrying about the competition, or about what we can't do just yet. Can't we just focus on making our customers amazingly happy? Perhaps I'm too simplistic, but if we do just that, I really think everything else will work out.

I feel like we've lost our identity looking at and comparing ourselves with others. The insecurity and lack of confidence seems to be everywhere. You can see it in the way employees "defend their Microsoft position" rather than "just tell the story" because it's a good one.

It wasn't always like this.

What's totally ironic about this present situation is that this is exactly where Apple was, only a few years ago. In an interview at the "All Things Digital" Conference this year, Steve Jobs said this about that time at Apple:

[There was this belief that] for Apple to win, Microsoft has to lose, and it was clear that you didn’t have to play that game because Apple wasn’t going to beat Microsoft. Apple didn’t have to beat Microsoft. Apple had to remember who Apple was because it had forgotten who Apple was. So for me it was pretty essential to break that paradigm.

There is space in this big old world for everyone, Apple, Google, free software and yes, even Microsoft. We don't have to be Apple to be successful. We don't have to be Google either. We just need to be Microsoft.

The GM of MacBU wants to talk to You!

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

Forward Looking Font Display

Yesterday, Apple released their own Safari 3.0 web browser for Windows XP and Windows Vista. Amid the security and performance comparisons, folks are also noticing that Apple has also ported their own sub-pixel display technology to Windows. Joel Spolsky summarizes the differences sucintly:

Apple generally believes that the goal of the algorithm should be to preserve the design of the typeface as much as possible, even at the cost of a little bit of blurriness.

Microsoft generally believes that the shape of each letter should be hammered into pixel boundaries to prevent blur and improve readability, even at the cost of not being true to the typeface.

I think Apple's method will turn out better when we all have resolution independence along with hi-resolution displays. The real question is will the current font display fuzziness in Safari turn off the current unwashed masses, so that even when hi-res displays become standard, it's too late. If that happens, Safari will follow a great Apple tradition: high technology ahead of its time.

Silverlight

The best thing about Silverlight is its icon. For regular users it's a web-browser plugin that allows you to view and use Silverlight content. What Silverlight content is there? Media and stuff. Have you ever seen a website done completely in Flash? Well, now you can do that but with Silverlight. From my perspective this is fundamentally about competing with Flash. There are some cool things going on under the covers to make this happen and as a developer, I understand the geek factor there. By the same token, as a developer, my ability to develop amazing software is directly related to the toolset available to me. So I ask myself, "Which toolset gives me the greatest ability to develop amazing software?" Flash or Silverlight? PHP or Ruby on Rails? Cocoa and Core Animation or XAML and .NET? I don't think I can compare any of these with much authority, but I have a hard time believing that the next killer app, web or otherwise is going to show up as a Silverlight application. Still, I love the icon.

MSNBC Video Supporting the Mac

Starting today, all video on MSNBC will now be available on the Mac without the need for Windows Media Player or Flip4Mac installed. Here's how it works:

If you hit the site with Win Internet Explorer 6 or 7 you get Windows Media video

If you hit the site with Mac FireFox you get flash based video It doesn't look like it supports Flash in Safari, but that could be just because I haven't got the newest version of the Flash player. Slowly but surely other groups at Microsoft are "getting it" when it comes to supporting the Mac.

Joel on His MacBook

Joel Spolsky talks about his Mac at home experience:

I have a few complaints though: OS X antialiasing, especially, it seems, with the monospaced fonts, just isn't as good as Windows ClearType. Apple has some room to improve in this area; the fonts were blurry on the edges. Also, I don't understand all these people who say that Macs never crash. I probably had to reboot the MacBook Pro (hard reboot -- hold down the power button for five seconds) about every two hours. It was always the same problem: the Wifi network would go down for a second, something which happens to everyone, but on Windows, it just comes back, while on the Mac, I get a spinning colored ball and everything is frozen. Everything. Forever. If I try to wait it out the beachball will still be spinning the next morning. If anybody is aware of this problem and knows of a specific fix I'd love to hear of it. It was like a Windows 3.1 deja vu all over again thing.

I've only recently been getting the same behavior. I agree with Joel that it has something to do with the wireless, but I see this happen most often when I VPN into work. This didn't happen before 10.4.7, so I think this is a new bug introduced recently. Also, while Apple's sub-pixel text rendering has improved markedly, ClearType on Windows still is just a bit better, but some fonts seem to work much better than others. My basic understanding of how sub-pixel smoothing works leads me to think there are only so many ways to do it, so it's amazing to me that you can notice a difference.

Microsoft Cafeteria Tour 2006

You may not know it, but the Microsoft Redmond campus has like 100 different buildings. Okay, maybe not exactly 100, but there are a bunch, and for every 3 or so buildings, there is a different Microsoft cafeteria. Some buddies and I decided we'd try to visit each and every one, in Redmond at least, and document the journey. Everyone's always talking about Google's swanky eats, so consider this your Microsoft guided tour of our swanky eats. ;-) You'll notice us following in great MS tradition by naming our project something as approachable and easy to remember and understand as "MSCT2k6". Of course, we couldn't do this without some kind of memorabilia, so you guessed it, shirts, mugs, bags and yes, the MSCT Rectangle Magnet. As our tour leader says, "Consume! It'll make you feel better, honest."

But what is MacBU?

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

Software Factories

Now this is interesting. Jack Greenfield and Keith Short take on the future of software development:

Total global demand for software will grow by an order of magnitude over the next decade, driven by new forces in the global economy like the growing role of software in social infrastructure, by new application types like business integration and medical informatics, and by new platform technologies like web services, mobile devices and smart appliances. Without comparable increases in productivity, total software development capacity seems destined to fall far short of total demand by the end of the decade. What will change to provide the massive increase in capacity required to meet demand? It is not likely to come from adding developers. Instead, software development methods and practices will have to change dramatically to make developers much more productive.

Read the whole article here.

Martin Fowler has a whole essay on this topic: Language Workbenches: The Killer-App for Domain Specific Languages?

Most new ideas in software developments are really new variations on old ideas. This article describes one of these, the growing idea of a class of tools that I call Language Workbenches - examples of which include Intentional Software, JetBrains's Meta Programming System, and Microsoft's Software Factories. These tools take an old style of development - which I call language oriented programming and use IDE tooling in a bid to make language oriented programming a viable approach. Although I'm not enough of a prognosticator to say whether they will succeed in their ambition, I do think that these tools are some of the most interesting things on the horizon of software development. Interesting enough to write this essay to try to explain, at least in outline, how they work and the main issues around their future usefulness.

And to round out the discussion Neil Davidson responds to Steve Cook with this insightful comment:

As much as I find the technical side interesting, the thing which really fascinates me is how the way people write software will change in the future. ... I've been thinking about it a bit, and I think that although the analogy with the changes in industrial manufacturing (from craftsman to mass production to mass customization) is interesting, I'm not sure it really holds true.

I think one of the key things you mentioned was the analogy to the supply chain, and how this chain will lengthen. The way I see it, software will always need a craftsman at one end. Software is intrinsically hard to do, and requires people, or teams of people, to think very carefully and deeply about what they're doing. The tools, processes and components they use will have to change though - it is at this point in the supply chain that I can see mass production happening. I think the analogy is that you're always going to need craftsmen like carpenters and bricklayers to build a house, but the tools, techniques and materials they use will be mass produced. At the moment we're at the stage where the bricklayer makes his own bricks, and the carpenter cuts his own trees down. I don't think the craftsman will be replaced, but the tools he uses will be provided by companies who provide (or are) software factories. That's the point I was trying to make about a few companies dominating the market - somebody will discover that they can produce an e-commerce software factory and sell hundreds of thousands of the things at $1,000 a piece rather than two or three a year at $100,000 a go (because it's no longer a problem constrained by people's time). Presumably Microsoft believes it will be them and that's possibly part of the reason why they're entering the CRM, accounting and business markets.

Does Apple see any of this? Do they think it all too distant to consider currently? Either way, what an interesting time to be developing software!

ExCodeWarrior Schwag

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

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.

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.

Switching

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.

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.