(Re)building a house

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.