Month: June 2006

(my apologies in advance to the J. Geils Band)
Pierre Igot writes what I must politely describe as an impassioned discourse about my description of pseudo-localization, multi-lingual bundles in OS X, and MacBU testing. Pierre makes some good points, totally misses the idea of pseudo-loc in another, and generally castigates the MacBU for failing to fix a particular bug that is very important in French typography. He then invited me to comment.
Let me begin by saying what I am not. I am not the lead developer for Word, and I am not intimately familier with every bug that is entered against our products. I am also not a native French speaker, nor am I familiar with the rules of French typography. (In fact, my peers in high school often told me “Tu parles français comme une vache espagnole,” which, if my hazy memories of 1991 are correct, means “You speak French like a Spanish cow.”)
I do, however, know quite a lot about bundles in Carbon and Cocoa, how multi-lingual bundled apps should behave, and the benefits to users of software that takes advantage of them. Apple did indeed make them available to developers using Carbon in 2001 or so. Pierre is correct in saying that currently shipping Mac Office apps do not use them. (Well, Messenger does use them, and may have been the first major Microsoft app to do so.) I became a lead for Mac Office in June of 2002, well into the Office 2004 project and was not a part of the initial schedule planning that, for whatever reason, did not include moving Office to a bundled architecture. As the lead for localization, I understand and sympathize with users for whom this creates frustration. The reality is that for every user calling for a multi-lingual version of Office, there are at least two users who don’t care about that at all and want us to be working on something else. We can’t please everybody, unfortunately. As I said in the comments at the end of my localization post, I cannot comment on our plans for this aspect of the next version of Office, but please rest assured that I do understand and hear your request, Pierre.
Because I am not well-versed in French typography (or any real typography for that matter) I can only trust that Pierre’s assessment of the importance of the non-breaking space in French documents is indeed high. Assuming that is the case, then yes, this must be a very aggravating bug for anyone who uses Word 2004 to lay out text in French. I’m quite sorry, Pierre, that you have been so frustrated by this issue. I wish we had caught the bug and fixed it before shipping. Sadly, we did not.
Pierre then takes our non-use of bundles and conflates that with the existence of the non-breaking-space bug:

The fact that the language of the user interface in Office applications does not change depending on the user’s preferred language in Mac OS X is annoying enough. But that’s not the worst of it. The worst of it is that Microsoft’s process for fixing bugs is completely screwed. And there is no better example of this than the bug with non-breaking spaces and PostScript fonts in Word 2004.

He also implies that our use of pseudo-localization should have caught this ‘elementary’ bug:

The fact that Microsoft did not catch that bug in Word 2004 before they released the product is a clear illustration of how flawed their testing processes are. Whatever benefits this “œpseudo-localization” technique described by Erik Schwiebert provides, it is clearly not good enough to catch even such elementary bugs.

Here I must correct Pierre’s faulty assumption and say that the bug is not in any way connected to either of the other two items. Multi-lingual bundles are all about providing resources to the app, such as strings, dialogs, menus, windows, etc. Pseudo-localization is a method we use to test the localization of those resources and the code that uses them. It is intended to help find visual glitches, missed translations, improperly displayed dialogs, and similar items, and it does a pretty good job at optimizing our efforts for those issues. It is not designed nor intended to help with finding or fixing bugs related to the actual behavior of the application. Pseudo-localization in no way replaces good old-fashioned usage of the applications to uncover code defects.
In fact, the bug that Pierre is so frustrated with occurs in all languages that Word ships in — the faulty code is in no way connected to any localization. I can repro it in the English build. That doesn’t mean that our entire testing process is flawed, however. Every large software endeavor results in a product that has bugs. Microsoft is no better or worse than anyone else in this regard. Seen any OS X software updates lately? 🙂
Now, the fact that the bug is unrelated to our localized UI testing doesn’t address the issue that the bug is there, and is bad. Pierre blogged about the bug way back in September 2004. Unfortunately, the MacBU (and the rest of Microsoft, to my knowledge) has never had a good method for customers to report bugs to us. We’ve had the (now defunct) MSWish email address, and we do have the new direct feedback link on Mactopia, but we don’t have anything like Apple’s BugReporter tool. Interestingly enough Nathan Herring, another MacBU employee, just blogged about this specific issue and has some links you may want to read.
But let me continue with Pierre’s post. He finds it unjustifiable that we have not fixed this bug in the almost two years that have gone by:

Now what excuses does Erik Schwiebert have for this sorry state of affairs? I might find it acceptable (barely) that Microsoft is not able to catch such bugs in the hectic schedule that leads to the release of the initial versions of the product. But how can they justify not fixing the bugs in the next two years, even though the bugs are so obvious?

says it can be done on schedule:

it is perfectly possible to release multilingual software on schedule that automatically supports all of Mac OS X’s supported language without requiring the user to buy separate versions for each language and download separate updates for each language.

and casts shame on us:

And for all this, once more, all I can say is: Shame on Microsoft, and shame on the MacBU. They have absolutely no excuses here.

Ouch. That hurts. Me personally, as well as all of our hard-working employees. It’s a good thing I have a relatively thick skin.
I don’t think there is anything I can say that will appease Pierre. And I don’t mean that there’s something I know that I’m not allowed to post; I just don’t think that any insight I provide into MacBU’s bug process will soothe his wrath. However, I will try to shed some light on our processes because I think folks are interested in them anyway. I’m sure many people will individually disagree with many of of the decisions we make and the factors we weigh, but that’s part of the openness of blogging. Feel free to respond with your thoughts and comments — you may provide some insight that we’ve missed in all these years.
First of all, we do work darn hard to fix bugs in our products. Really darn hard. But, we’re not perfect. No developer team is. Not MacBU, not Microsoft, not Adobe, not Apple. Security defects? We’ve all got them. Software updates? Yep, them too. For OS X, we have 10.0.4, 10.1.5, 10.2.8, 10.3.9, 10.4.6 and counting. For Office we have 11.1.1, 11.2.4, etc. Updates are good, it means that we’re all working to make our products better, to fix the bugs and reduce the crashes.
However, not all bugs are fixed in dot-releases of products. Some bugs that we find are really obscure and don’t cause any real harm. For example, perhaps the File/Open menu item is grayed out when you hold down Cmd-Shift-Ctrl-Option and triple-click on the menu-bar. Not too many people will see that, and if they do, no real harm done. We can spend our engineering time and resources better elsewhere.
Some bugs are easier to hit, but fixing them may have a high risk of regression and may cause another bug that is even worse. One example might be a performance bug in Excel’s recalc engine. We could fix it and make things faster, but currently the code calculates correctly (albeit slowly) and any fix might totally break all function dependency analysis. It is sad but safer to leave things alone.
Other bugs are deemed worth fixing for a future release, but not worth back-porting to the current release. Every code change we make has to be tested around to make sure no regressions are caused, and that takes away from other work we could be doing. It may be more effective for us to take a bug that was reported against Office X and just fix it in Office 2004. And occasionally, some bugs are misclassified or accidentally forgotten. After all, we’re only human.
Here’s an example of an engineering decision. If you boot Mac RDC on a PowerBook and connect to a Windows server, try turning on Num Lock (the keyboard light should be on). Type something on the number pad in Excel. You get numbers, right? Good. Now, Cmd-tab back to the Finder and turn off num-lock. Cmd-Tab back to RDC. Type something on the number pad again. What, you still get numbers? Yes indeed you do. Geez, the MacBU really should have fixed that bug, right? We’d love to have fixed it, except that the bug is actually in the OS. The Carbon Event manager does not give you accurate information about the Num Lock state when you query for modifier key state after app activation and deactivation. I filed that bug with Apple in May 2002 against OS X 10.1.4, and they still haven’t fixed it. I wish they had, but I’m sure there is some reason (hardware? software complexity? who knows…) that the change is more expensive for them to make than to allow the bug to continue to exist. That decision is completely up to them, and I respect that.
In our move to Xcode, we’ve reported over 100 bugs to Apple. They’ve fixed the majority of them, and have postponed several to some later release. Some of the bugs they’ve postponed have been real bummers, but they’ve made the engineering justification to delay the fix and again, I respect that. After all, we have to do the same thing with regard to Office bugs too.
Second, the ability to meet a schedule or not has nothing to do with the ability to ship a bundled multi-lingual product. That is essentially a feature, and does not come for free with Carbon apps. (Yes, that is one aspect where Cocoa wins hands-down — it is impossible to create a monolithic Cocoa app. At the very least your app must be bundled, whether or not it has more than one locale for resources.) Perhaps Pierre would have preferred we have chosen a different schedule, moved Office to Mach and multi-lingual bundles, and shipped a product called Office 2005. We hit our internal schedule for Office 2004 with the features we planned for it.
Now, I’m not saying that any of this is an excuse. We’ve made lots of conscious decisions over the years about many many issues. Some of them, everybody likes. Some of them, everybody hates. Most of them are liked and hated simultaneously, and the overlap between the sets of people experiencing the two emotions is rarely the same from topic to topic.
The sad thing about this particular bug is that it falls into the category of ‘oops.’ The code was wrong in a very small way (an exception was made for the breaking-space character and accidentally forgotten for the non-breaking space character.) We actually found this bug in-house just a little while after Office 2004 shipped, and fixed it internally for the next major release of Office in August 2004. We even noted that it was important in the French market. Somehow, though, it was never flagged as a bug that should be migrated back to Office 2004. The tester for that area of Word (who found and opened the bug) left MacBU to go back to graduate school during that summer, and I think we probably just missed this one in the transition. A simple human mistake. Shameful? I personally don’t think so. Unfortunate and frustrating, I’ll certainly agree to that, but not shameful.
I’ve asked our Word team to take another look at this bug. I make no promises, but maybe we can get it fixed sooner than in the next major release of Mac Office. After all, the Windows team did that for a blogger recently.
So Pierre, we are listening. I think pseudo-localization has a greater value than you place on it, but for a different purpose. If you are ever in the Seattle area, please look us up. I’d be happy to take you out for coffee and a chat, and see if we can address some of your dissatisfaction with us. In the meantime, I’ll stand up proud and accept no shame, for I believe we work hard and produce a good product.

So BillG is handing over some more of the reins. Good for him! The B&MGF does some really good work in this world.
There’s been lots of commentary today on what this change means for Bill and for Microsoft. My question for you is what does it mean for the MacBU?
My answer? Probably not much at all. Bill and Steve have both been very aware of our products and plans, and both have been very supportive of our group. I don’t anticipate that changing. As for the effect of the actual shuffling of which top exec does what, in my 10 years at Microsoft I’ve experienced exactly one re-org that had any real effect on my day-to-day work, and that was when the MacBU moved from the Desktop Applications Division to whatever the Home and Entertainment Division was called back in 200x. (And you can see what a large effect it had, given that I can’t even remember the year it occurred.)
The MacBU, like many smaller groups at Microsoft, runs pretty autonomously. That’s one of the things I love about our group — we’re really like a small company, just one that has a lot of support from a much larger organization.
Perhaps that’s a topic to blog on. Another day, however; I need sleep!

The other day, I mentioned my surprise at the lack of commentary on my Cocoa post. I was fully expecting to hear at least one person say that I totally didn’t get it, that Carbon was a dead technology, yadda yadda yadda. Well, one person preferred the analogy that my house was destined to be eaten by termites and thus it was better to rebuild it now than later.
I’m curious to know what the termites are in that analogy.
I saw a very interesting essay on Daring Fireball today. I particularly like this quote from John Gruber:

…in some cases, some people seem unwilling to concede that any criteria other than the ones they themselves deem important actually matter, or even exist.

Now, I’m not pointing any fingers at any specific people. I do believe that the choice to use Cocoa or Carbon is, loosely adapting from John, not a binary choice. It isn’t either-or, and neither option is always better than the other. I firmly believe that there are very valid reasons to use each ‘package’. Saying that ‘your house is going to collapse; you can’t avoid it, so go rebuild it now’ does two things.

1. It denigrates all the work Apple has put into Carbon and continues to put into it.
2. It ignores all the reasons I listed in my post for why we have heretofore continued to use Carbon.

Now, I don’t want to get too dogmatic in defense of Carbon, myself. After all, as I said in my first post and in the preceding paragraph, I believe there are good reasons to choose either platform. That’s why I’m curious to know why some folks are so dead-set on the idea that Cocoa is a magic bullet that can fix anything wrong with an app written in Carbon.
Let me know; we’ll chat about it.

I went back to work for the first time today in over 5 weeks. I updated my G5 and my Intel iMac to the latest Office source code and did a full developer debug build. Well, actually, my iMac did a full build; the G5 was about 60% done when I left. It’s amazing how much faster the iMac is.
Anyway, I was very surprised to see how little commentary my Cocoa post generated. I’ve been playing with some simple stats plugins, and it looks like lots of people have subscribed to my RSS feed (114 feed hits in the last 90 minutes) but I received almost three times as much feedback on my Messenger post. Interesting. (Oh, and jhawk28, I spent lots of time in Middlebury!)
Rick Schaut showed me his entry on bad code today before he posted it. I saw the ambiguity in about 5 seconds, but that’s because it was very carefully contrived. The best part of his particular example is that neither CodeWarrior nor Xcode give any sort of warning that you’ve written Dumb Code. While this example may have been easy to spot, it gets very tricky for devs to hold a mental map of more than a few dozen lines of code in their head. Spotting similar errors when one function is perhaps inlined in a header and another function that interacts with it is at the bottom of a 3000 line source file somewhere else is nigh impossible without actually running the code under the debugger.
Now that I’m back at work, I expect to be blogging less frequently. Please do keep the comments coming; I like to hear from you.

I grew up in a big old farmhouse in the middle of Vermont. You know the kind, with the knotty wide pine flooring that creaks everywhere, huge drafty hallways, shutters that rattle in the wind, old furnace in the basement that sounds like an airplane taking off… My parents bought it in the mid-1970s and promptly had to replace the well that went dry and add insulation to the walls because the winter wind blew straight through it.
The house itself was built in the 1870s and was originally just a summer home, so the kitchen that had been added on in the 1960s was always a little small and never had enough cupboard space for all of my mom’s pots and pans. Last year, my parents announced that they were going to do a massive kitchen remodel and replace the kitchen with a real ‘farmhouse’ kitchen with lots of space for cooking, playing with grandchildren, hanging up wet snow-clothes after sledding, etc. Their plans are pretty impressive — practically doubling the size of the kitchen and adding a mudroom, putting in a fireplace and space for large comfy chairs, a full basement underneath, new fancy refrigerator, and other cool stuff. I just hope it is as warm and friendly a place as the old kitchen where we used to sit around the woodstove with a cup of hot cocoa after an afternoon of sledding down the hill onto the pond across the road.
Ahh, hot cocoa. What, you didn’t guess where I was going with this? Yep, Cocoa. That Cocoa, the one that everybody keeps saying that if only the MacBU would rewrite Office in Cocoa, that it would be magically bugfree, run at warp speed, and somehow still maintain compatibility with legacy fileformats and code ported from Win Office. Well, let’s see, shall we? I’m going to touch that third rail of Mac Development. Let’s see if I live…
If you will pardon me for a little bit, I’m going to draw an analogy to my parent’s house here. I grant you up front that this will not be a perfect analogy, and I fully expect to see comments explaining how badly I miss someone’s point, but you know, no analogy is ever perfect and I’m not a very experienced Cocoa developer (whereas I’ve been writing CarbonLib and InterfaceLib code since 1992).
I see the idea of ditching the Office source code and starting over in Cocoa as similar to the idea of taking an existing house and tearing it down with the intent of rebuilding it precisely as it was before, just with modern tools, components, and technologies. You want to replicate all the character of the house — the creaky boards you love, the rattly shutters, the custom-sized windowpanes, etc. You can do it, but it will cost you a lot of time and money, and you’ll probably exasperate both yourself and your contractor trying to duplicate something that was hand-built long ago.
Or, you can keep your house generally the way it is, and you can take that time and money to add on a neat new addition (perhaps that indoor Olympic swimming pool you always wanted) or rebuild just one part of it in a new style with more capabilities than it had before. You live with the existing creaky floors (you never wanted to change them anyway), maybe you rip out the old furnace and put in a new one with new efficient radiators, but you concentrate your efforts on the new part of the house. You make it extend the old house, yet, because you had a great architect, make it fit in flawlessly so that you don’t feel a sense of shock or dissonance when you walk into that new space.
Moving Office to Cocoa would be kind of like that first scenerio. I’m not saying it can’t be done, or that we’ll never do it; we just haven’t done it yet (as of Office 2004) because the time and effort required are huge, and we can get a lot more out of extending the current source code. If we spent 2+ years rewriting Office in Cocoa, and came out of it with exactly the same feature set as before, how many people would buy it? Be honest now, would you really spend $239 to upgrade Office Standard to a version that was no different than before, from a feature and useability perspective? Oh, you say we could add features at the same time? Yep, we could, but that would take us even longer, and the computer industry moves faster than that!
Rewriting in Cocoa is also no guarantee of achieving bug-free software. There is no such thing. Your contractor will always make a mistake, or your architect will, or the electrician. (When my parents added on a room to the house in 1991, the architect miscalculated the height of the roof by 3 inches, and the builders only figured it out when they went to start putting up the trusses! They had to take the wall frames down and redo them.) Your really smart developer will also always have bugs. We all try really hard to ship clean code, but any system that grows beyond a few thousand lines of code will have flaws. Even Apple has been constantly updating Cocoa in every system release.
Another thing for the MacBU to consider is code compatibility with its own older software and with Win Office. We can’t literally ditch all of our code because we have to be able to read and write legacy files. Moving to Cocoa doesn’t help with that. And, Windows doesn’t have Objective-C, so any code we write in Obj-C cannot be ported to them, and all the code they write in C/C++ is harder to port to us. Plus, our apps still share a lot of common code, so any gratuitous differences in the code make it harder to port features from Win Office to Mac Office (like the new XML file formats.) It’s already hard enough when they write code in C#!
Beyond that, there is always some code you just don’t want to touch (the creaky floorboards and rattly shutters). That might be things like Excel’s recalc engine or Word’s text layout engine. Both are incredibly complex and it is easy to introduce subtle flaws that make the apps almost worthless. Consider the ramifications if Excel miscalculates some spreadsheet for a large Swiss bank. Think they won’t blame Microsoft? Or if Word suddenly doesn’t lay text out the same on OS X 10.5.2 as it does on 10.4.6 because of a change to the Cocoa text engine?
Now, having said all that, don’t get me wrong — Cocoa is a great thing. Our internal infrastructure team has written tons of tools in Cocoa. Just ask David Weiss. Cocoa is really good for setting up a UI and hooking controls and behavior together, and then letting you write the backend. It’s also cool because you can easily subclass all sorts of OS objects and behavior. That’s a pain to do in Carbon where everything is a C interface and you have to write all the glue yourself.
We have lots of plans for Cocoa for upcoming work (no, I won’t tell you when, where, or how — yet) and lots of areas where it makes total sense for us to use Cocoa. In fact, some areas it would be downright stupid of us to do some new features in Carbon. The point of this post is to hopefully help you see why moving to Cocoa is not a slam dunk simple decision. We’re well aware of both the great advantages and great disadvantages of Cocoa and of Carbon, and are making educated engineering decisions on which to use where.