Microsoft Office Stats
Brad Post says that the Mac version of Office has 30 million lines of code (428,000 per developer), with an average age of about 12 years, and that the development team has had 50% turnover over the last two years. So they’re working hard, but it’s a lot of work.
3 Comments RSS · Twitter
Dear god they need to refactor! I wonder if it wouldn't have saved them time to just rewrite it from scratch in Obj-C and Cocoa.
Would they even be able to? They don't seem to think so:
"... very often if you want to do something cool, you almost always have to drop down to the C API and well, more often than not, you're using Carbon."
http://davidweiss.blogspot.com/2006/09/mixing-carbon-and-cocoa.html
Wil Shipley, making a recent plea to Apple, says:
"What's distressing to Cocoa programmers is that there are still critically important Apple APIs that are only available through the incredibly byzantine and ill-documented Carbon libraries."
http://wilshipley.com/blog/2006/10/pimp-my-code-part-12-frozen-in.html
He also comments there:
"There are a ton of neat applications I could make if NSSpeechRecognizer (and its friend, NSSpeechSynthesizer) were fully Cocoa. It's too bad."
In other words, there are things that he simply doesn't do, because Apple hasn't made it possible for him to do them in Cocoa (as yet), but Carbon is so outdated (i.e., inefficient and not object-orientated) that doing them in Carbon is not worth the pain to him. I can't see that Microsoft's Mac Business Unit has that option: the applications simply have to do whatever they have to do by whatever means it takes.
It's perfectly possible for them to mix Cocoa and Carbon while benefiting from the kind of RAD that Cocoa and Interface Builder allow. Apple managed to write Keynote with some pretty swanky effects and that's a Cocoa app. It's not like the MacBU don't already understand Carbon and can't get very low level support from Apple when they need it.
