It’s all in the numbers …


A friend of mine and I were shooting the … breeze (freaking ‘G’ ratings for blogs) and he was asking me when the next version of Office was coming out.  Now being the wise Microsoft spin doctor that I am, and having spent numerous hours being brainwashed by marketing, p.r. and some guys in black who look like Jessie Ventura and Alex Trebek (anyone get that reference?) I looked him square in the eye and asked, “How many lines of code are there in Mac Office?”


Not to be caught off guard, he stared right back and asked, “You’re going to kill me after you tell me, right?”  I smiled that Cheshire cat smile I have and said, slowly, “Maybe ….”  I let the pause go on for a bit longer than normal and then laughed.


So I changed the subject to movies and after a bit he asked me, “How many lines of code are there in Mac Office?”  I looked him and asked, “Do you really want to go there? ” He nodded as he moved his lawn chair a little out of arm’s reach.


About 30,000,000 lines of code make up the current version of Office that we are developing.  That’s no typo; in fact, I had to figure that out because of a research project I was working on … if I told you what it was, I would definitely have to  … oh, yeah, ‘G’ ratings … anyway back to the train of thought.


It’s really mind blowing when you think about it.  Each developer is responsible for, on average, about 428,000 lines of code.  Some people have more areas, some have less, but if you just think of that number, that’s a tremendous amount of responsibility per developer.  Consider for a moment also that there are probably 10x (yes ten times) or more developers on Windows Office, although I don’t know the exact count. 


Just to throw another mind-numbing number out at you, there are about 40 lines of text on the page of an average paperback book.   That means one developer is responsible for about a 10,700-page book.  Or if you break it down smaller, if the average paperback is 300 pages, that means each developer is responsible for  about 35 or more paperbacks on his desk.  Imagine trying to find a single typo in all those books  — that’s what most bugs are, don’t ya know!


Rick might have a better guess, but from what I have seen the average life of the code (before this version), was about 12 years, meaning most of the code was written back when 68k and 386 processors ruled the world.  A5 bring back any memories for people?  What about segmented memory? Why is this important?  Read on.


The final killer number that I think is important in answering my question is 50%.  What does that number mean?  It represents the amount of turnover we have had in our developer organization in the past two years.  Let that sink in for a bit: during these past two years we started the move to XCode, then started the move to Intel, brought on about a bunch of new people and asked each of them to learn somewhere on the order of 400,000 lines of code.  Most of which was written before some of these new hires started high school!  Either that, or they started work on a brand new feature and we pushed all the responsibilities of that code onto people who never saw it before or were already working on other things.


I guess the short answer to my friend’s question is that the next version is coming out as fast as we can develop it.  Everyone in the MacBU, developers, testers, UA, PM, Loc, and managers are trying to make this the best version of office for both PowerPC and Intel based Macs.  But as we have said before on this blog and will continue to say, we’re making progress, staying on track and hoping to get this puppy wrapped up and shipped off to you as soon as possible.  But for now we’re all trying to get through our 35 books trying to find those blasted typos.


Oh, and for the record, I think I have about 50 or so books on my desk … some are written in OLE …

Comments (52)

  1. anon says:

    50% turnover? Isn’t that alarmingly high? What’s causing it?

  2. Colin says:

    Jose Chung is most definitely from outter space 😉

  3. Rho Chow says:

    30MLOC sound like a huge number. What is the MLOC breakdown by application?

  4. dzot says:

    No other object has been misidentified as a flying saucer more often than the planet Venus.

  5. alinton says:

    X-Files?

  6. Corentin says:

    Brad, best of luck with your 50 books :-

  7. So I'm doing the math... says:

    So there was a 29% turnover rate for the 50-60 developers on the team mid-way through a major release that includes a port to a new platform? That’s about 3x or 4x higher than the industry average rate. I wonder what that says about how exciting the product will be, or how good (or not so good) the organizational dynamics in MacBU…

  8. Fubar says:

    Gotta like a guy willing to drop an obscure X-Files reference….

  9. Tony Brown says:

    Alex Trebek??!?! The game show host?!

  10. Drew Thaler says:

    30 million? Wow. Although thinking about it, I guess there’s certainly a fearsome amount of code in there when you take all the products together. An Office install is just a seriously large number of apps and libraries. 🙂

    But out of sheer curiosity … does that number include any of the following?

    * non-shipping targets? Perhaps something that just does a transform needed for the build: a 68K-asm-to-C transcoder, a custom language compiler, a custom build system, etc.

    * scripts for interpreted higher-level languages? VB, databases, etc.

    * data stored as text? Rez files, binaries converted to C structures, etc.

  11. opensourcefan says:

    Are you’re saying Office is bloatware?

    No joke. How much of that code is spaghetti? Do you ever just chuck some of it out and start over to get it slim and stable?

    The Office 2004 folder is almost 400 MB on my Mac. In comparison, my first computer had a HUUUUUUGE 500MB hard disk. Word, Excel, and Powerpoint are all less than 20MB each. (No Entourage or MSN Messenger on my Mac.) Where does the rest of that 400MB come from and why?

    What do all those millions of lines of code do (or not) for stability?

    Office 2004 is less stable than Office 2001 in Classic. How many more million lines of code are there in 2004 than 2001? and no you can’t kill me if you answer that.

  12. opensourcefan says:

    Forgot something.

    In the next version, please make the installer strip out the code for the chip architecture our Macs don’t need. Or, make sure that apps like "Trim the Fat" which will strip out intel code for PPC Macs or PPC for Intel Macs will not render the Office apps unusable. Thanks.

  13. Chris Howard says:

    Nice numbers.

    Be curious to know the character count though. Code has lots of very short lines, unlike a novel. 428,000 lines of code probably has similar character count to longer novel

    Of course, a spello or typo in a novel doesn’t make it crash and unreadable ("Damn! A typo, I can’t turn the page.")

    🙂

  14. Schwieb says:

    One thing to realize is that those 30 million lines of code includes things like whitespace, brackets, #includes/#defines, comments, Rez definitions, Perl and Python scripts, etc.  The code isn’t 100% dense text.

    To answer ‘opensourcefan’, much of that space is taken up by things like clip art (8 M), templates (40 M), fonts (80 M), Help files (58 M) etc.  The proofing tools folder on my home machine is 110M in size — I personally really don’t need Dutch, Brazilian Portugese, Finnish, Spanish, etc spell/grammar checkers installed because I can’t read or write in those languages, but I never bothered to delete them because I’ve got oodles of free space. If you remove all that, your install would be more somewhere under 200M in size, although you would obviously lose the use of that content.  YMMV depending on your individual needs…

  15. David Hupp says:

    To respond to ‘opensourcefan’ as well…

    For comparison, Apple iWork (ahem) is just shy of 200 Mb without templates or themes. With the templates and themes, it is just shy of 2 _Gb_.

    Microsoft Office for Mac has twice as many major components (spreadsheet and PIM, in addition to the word processor and presentation software), and is about 400 Mb _including_ templates and themes.

    After you consider how much of iWork’s functionality is really just part of Mac OS X, and is therefore not included in the 2 Gb, Microsoft Office for Mac doesn’t look so big anymore.

  16. David Zatz says:

    No question but that there’s a lot of code there, but I have to wonder… along with the other questions…

    1) How much is used for Windows only features (like Microsoft Access support)?

    2) How does the absurd code-to-programmer ratio affect the qualtiy of the Mac version? I’d think it would end up being sluggish and oversized because there’s no time to optimize appropriately.

    3) Doesn’t this tell us how valued Office for Mac is? I mean, even in the middle of a MAJOR transition, you can’t get enough people, even temporarily…

    4) Are you just moving the code over and patching as needed, or actually trying to rewrite as much as you can to get around the old 68000 and Classic technologies?

  17. SuperMatt says:

    It seems like Microsoft should at least double the size of the Mac Office team.  I know Windows Office makes them more money, but it seems like you don’t have enough programmers for an application of that size.  Or perhaps having fewer programmers means that there’s better communication and more consistency?

  18. ExCntx says:

    Turnover isn’t just people leaving the group.  We have had a lot of long time people move up the chain from straight developers to management.  Also as in any large corporation people move jobs.  We had some other long timers move on to other jobs within the company.  Having worked in a number of places it’s a good thing that there are opportunities to move and try new things as well as grow your career.

  19. opensourcefan says:

    Scweib, I did a custom install for Office, and only put in the support for languages I do speak. 🙂

    David Hupp, I can’t begin to criticize iWorks for large footprint because I don’t use it. It’s a sorry replacement for Appleworks. OTOH, I do still use Clarisworks in Classic. It takes up a grand total of 14.6 mb with the actual app taking only 2.6mb. It’s got great functionality and stability.

    Even if there’s a lot of short lines, I still wonder if Office needs to be so big. It seems like the bigger it gets, the less stable it will be.

  20. Well, keep up the good work, looking forward to final product.

    Have you guys started looking at system requirements? Will this run on Mac OS Jaguar and Panther?

    What about dot releases, which release of Tiger will be the minimum requirement, 10.4.5 or 10.4.8?

  21. "I guess the short answer to my friend’s question is that the next version is coming out as fast as we can develop it."

    I’m reading between the lines here — lines of code, developer turnover — and it seems what you’re saying is: "It ain’t gonna happen."

    Well, it’s good to know…

  22. ExCntx says:

    When I did the count I used only source files like .c, .asm and .cpp.  We don’t have as much assembly in Office 12 as we do in Office 11.

    There has been a great deal of new code added to Office 12.  We have also moved the applications completely to Mach-O.  This also required a lot of work considering that some of the code in Office is at least 10 years old.

    Cleaning up legacy code, which we have a lot of, takes a great deal of time and effort.  Backwards compatibilty with older versions of Mac Office and Windows Office is always a top priority for us.  We have modules that just deal with this backwards compatibility.

  23. Asam Bashir says:

    So, a lot of code, a high turnover, that’s a perfect situation to write in malicous code then walk away, and no one would know about it, till an exploit happened….

    Serious dudes, why don’t you just go back to Word 5.1a and rewrite the code bottom up, you’d make a far more efficient application then the bastardized monstrosity that you’re going to call Office 12, or wotever name you give it….

    I was at a talk given by the WOZ and he was telling this tale of how back in the day of the great desktop wars, 97 era, he was convinced that the only thing making his Mac OS 9 crash was IE, not even while running, just by installing, you’d have a machine that started crashing, and it was just his machine, everyone he talked to who had installed IE had an unstable machine, and the only person who didn’t have problems turned out to be a Netscape user…

    You’re an evil company for a reason, based on empirial evidence and damned by courts of law, and I’m not saying that as a Mac head, I’m saying that as a logical thinking scientist….

  24. Asam Bashir says:

    As a former Jedi ExCntx, is the force still with you, or you turned to the DARK SIDE….

  25. Office user and a developer says:

    Lines of code has always been a misleading indicator whether it was uses to assess how much of the app a developer is responsible for or how many bugs created per lines of code written.

    I’m not sure if this post is just a "poor us" post or a "Top 10 reasons we’re late".

    High turnover is usually a sign of bad management. The fact that you’re still making reference to 68k and A5 says that some key decisions weren’t made in the last 6 years. Office v.X never ran on 68k and stripping out all older references didn’t require waiting until Xcode came along.

    What’s interesting is that Microsoft doesn’t go "yeah, most of this code is really old stuff, so we won’t charge as much for it". Quite the contrary, even with upgrade pricing.

    All I can say is stop counting the code. You’ve got other things to do. You want Kudos? Then figure out how to make Word Processing, Spreadsheeting into something new that works for newbies as well as hardcore folks.

    Sorry — I wish I could have more sympathy. I’ve worked on large legacy projects as well, with code dating back to the mid-80s. That’s why we get paid the bucks.

    As a side note, as for the size of iWork, much of that bloat is due to the fact that the frameworks they share are duplicated within each app (allowing each to run independently without having to go to an installation process when moved). Not that binary size is really THAT important.

  26. ExCntx says:

    You guys can read into this post however you want.  I am just trying to keep my posts honest.  You want to know what’s going on in the MacBU and what we’re doing.  That’s why they asked me to write posts.

    If you have every worked with a large legacy code base then you know moving forward and keeping the product working as your OS and hardware constantly changes.  When working on Virtual PC we had to constantly fight against Apple’s OS and Hardware changes and we were closer to the metal than any other application out there (besides MacOS).

    The office applications have been around since I started college.  It went from being a shared code base to p-code and then back to splitting things back up again.  Fine lines of code might be the most accurate way to talking about the size of the code.  If you want to read into this post, read this:  I used to work on Virtual PC, I used to work on the CPU emulation and dynamic recompiler.  Office is a completely different beast and is just as complicated.  It’s been a tremendous learning curve and if you can’t appreciate that, then you just don’t know software development.

  27. Are you by any chance including the PPC Virtual PC for PPC Macs running PPC OS X with Office 12 or is it a goner?

  28. I know others have already called it, but that is one of the coolest X Files references evar. Hilarious.

  29. KDT says:

    Someone quoted WOZ’s comments about IE causing Mac OS 9 to crash.  Did they actually read his whole interview?

    First, I admire Woz’s technical skill in engineering the Apple II series.  I actually programmed in assembly language on the Apple IIe and I knew the architecture in an out.

    But Woz said a lot of idiotic things in the interview.

    He said that Apple didn’t need a new operating system.  Does he know anything about modern OS’s?

    Mac OS prior to OS X did not have memory protection, multitasked horribly (pulling down a menu caused everything to stop) and memory management was abysmal where you had to set a block of memory manually for each app. Netscape routinely caused crashes under MacOS.  A badly written user level app should not cause a modern OS to crash.

  30. Rosyna says:

    Asam, I remember that happening to me too! Either having Ie 2.0 or 2.1 (one of those) existing on the machine would cause massive problems. IIRC, the resource fork was hosed out of oblivion So hosed it was corrupting memory when even glanced at. I never could understand how such a massive error got released.

    Anywho, 30 MLOC doesn’t sound like a good thing. Sounds a lot like something presented in the mythical man month. If Office is modular (code wise) I would have spent the last 3 years or so trimming down the modules and replacing them with modern APIs.

    I wonder if the Mac Office source base has a lot of #defines that are NOPs for legacy code that wouldn’t otherwise compile. Like LMGetROM85() or LMSetApplZone().

  31. Sheamus says:

    Loved this interesting, informative and fun post!

    Also, LOVE Office 2004 for Mac and looking forward to purchasing new Microssoft Office version for Mac as soon as it is released.

    Best wishes to your MBU colleagues.

  32. Joe says:

    I know right when you’re trying to ship is not the time to change everything, but have you guys considered using a higher-level language for part/all of it?

    I would have guessed that it’s mostly C and C++, but I’m surprised there’s any assembly in Office at all.

  33. Terence says:

    Somewhere in that code, please find a way for Entourage users to sort the address book by first name or last name and can also drag the fields columns around in any order they wish, the way MS Outlook operates.

    (Sorry, I’m sure this blog isn’t the proper forum for feature requests.)

  34. Frederico says:

    Man.

    WANTED: Intelligent, qualified individuals to stand on a stage occasionally with the best of intentions towards providing valuable, informative information and subsequent productive discourse, delivered with clear and genuine respect for their intended audience, who will allow said audience to throw garbage, rocks and barbs at them and smile while doing it. Position requires minimum BS/CS/EE or equivalent and 50-60+ hours per week times not less than three years of background prep. Human Beings — those requiring basic respect and dignity — need not apply.

    One always wonders when reading such if the same parties, meeting face to face, would behave in the same manner.

    Lord knows I have a list of feature and behavior-based complaints about MSO, and one can even find room to complain about performance, launch times, etc.; but, IMO, if it takes 60 MLOC and 40GB to build an app that makes my day easier, so be it. At least someone, ~70+ someones, get out of bed every morning with my needs in mind.

    I even used to complain about the high-end cost, until I amortized it out over its life, and compared that to the price of gas, milk and coffee. Argue all you want; if you find that your daily cost to use MSO is of less value than what you spend at Starbucks or CITGO, then, please, by all means, use OO or such.

    Too bad this blogset seems to be more of a vent space from haters than what, I would wish, it could be, and that is a direct pipe from and back to the people writing the code to make a better product (though I’m not even sure that is the intent of the MBU at all; it seems at times to just be a marketing tool). Complaining with personal vitriol from what is almost certainly a complete position of ignorance about the total amount, or perceived amount of useless/outdated LOC would, IMO, not do much to inspire or encourage the author; it would, IMO, instead encourage him or her, like the offended chef, to spit in your food; to add a few thousand extra lines of needless code.

    For me, I’ve never written anything more than a few paperback’s worth in totality, and I know I could go back and strip out a third of its volume by merely cleaning up comments and needlessly repeated strings and sub-functions. I also know that, besides the good feeling I would get for having a clean house, it would net me nothing beyond a bit of extremely cheap disk space and some bandwidth cost to deliver. The time it would take to do so is far better spent adding new features, or moving on to something new.

    This is not, of course, to be confused with fixing broken code, or improving existing features and usability. This is one place that I do seem to part with all mainstream, large developers, including MBU. I know it’s about the bottom line, and the coders rarely get to make this call, but the integrity in me would force me, especially now that it is approaching a 12th(!) release, to spend one entire development cycle doing nothing but fixing bugs and "fixing" broken features and behaviors; i.e., add no major new features, and simply improve the ones you have. And, yes, I’ll be the idealist, I would want to do it for free. After all, I got paid to do it right the first (eleven) time(s); at some point, I owe my customers something as close to right as possible without charging them again. With the arguable (yet dubious) exception of Windows itself, MS and Adobe are the worst offenders to my sense of right and wrong in this regard. The number of times I’ve "paid twice" for a bug fix is frustrating, but if I didn’t get something new in terms of features at the same time, I would then call it criminal. It is this now accepted cop-out cycle that we all accept as consumers that is now to blame.

    "Waiter, this hamburger has bits of bone in it that hurts my teeth! If you can take out the bone chips, fine, but otherwise, I want you to make it again!"

    "I don’t have time to take out the bone chips, sir, because we are too busy making new hamburgers from the same meat; and since you have already taken a large bite, and are that much less hungry, I will not refund your money. I advise you to just chew slowly, get as much nutrition as you can from the bun and fries, deal with the bone chips, and, if they actually draw blood, I will give you a bandaid for free. However, if you will wait a few more hours, I will sell you another hamburger, but this time, it will have pickles and cheese!"

    "Mmmmm… pickles and cheese. [sigh] Well, I do like the taste of the burger itself, and, hopefully, by paying again, the chef will be more careful about the bones… and what could be wrong with the pickles or the cheese? Hard to screw up pickles an cheese… OK! Let me know when they’re ready! My wallet is open and ready…"

    Wow. what am I blathering on about here? I think there’s a point, and hopefully someone bothering to read it will find it. Clarity, let alone brevity, are not in my grasp this evening, it seems.

    Cheerio, carry on, etc.

  35. re: David Hupp’s comment

    I sure hope when you do those Office for Mac numbers that you actually include the same number of translations as you do when you total up Pages….

  36. Tim Boyden says:

    …not to mention standard e-mail features like Out of Office messages, come on now MacBU guys, how’d you miss that in Entourage 2004?

    I have a bunch of Mac users that now have to use Entourage to get there e-mail from our new Exchange 2003 server. All I’ve heard over the last 3 months since the migration is “how come Entourage doesn’t have this feature of Outlook 2001”. Pretty sad that a 6+ year old program has more features than the latest version – with less bloat.

    Maybe the MacBU needs to drop the MS Office code base and just pretty up the OpenOffice.org office suite and the Novell Evolution e-mail client. Evolution currently works better with Exchange 2003 that Entourage 2004 does and eventually everyone is going to be using ODF file formats anyways which solve the OpenOffice .doc vs MS Office .doc formatting issues. If there were only OS X native versions of OpenOffice.org and Evolution…

  37. vgolf says:

    Frederico, your post should be all around the internet. I have rarely seen such an acurate description of the feelings of most (reasonable) users. Thanks.

    One vote from me.

  38. Scott F says:

    Most bugs are not typos. A typo in code will result in an error in compliation. The compiler will return the error, the location of the line that caused the error and, if’s a well designed compiler (so NOT a Microsoft one), the actual string that caused the error.

    Most bugs are mistakes in programming, either calling the wrong subroutine, using a variable in more than one location, of poor snchnoization between programmers working on similar, but differnt, sections of a program.

    Still, 3 million lines, and the Windows version is even worse. No wonder Office is so crummy.

  39. kristan Slack says:

    Hi David, ExCntx and other MacBU devs…

    Please know that some of us out here understand why things take so long, why you guys haven’t just magically waved a wand and produced the next version, and why some other mac users are idiots.

    On behalf of all of us Mac users who aren’t bigots and who like what you guys do, I’d like to say a big thanks!

    And thanks for giving us an insight into what you do and how things are going over there. And just ignore the silly advocacy/slashdot-type posts.

  40. vgolf says:

    kristan Slack, do not confuse aggravated users with (only) mac users. I think there is a growing trend against most software companies, including apple, microsoft, adobe and others, based on the fact that competition has led them to ignore code quality or interface correctness in favor of more features. I do not know how this is going to turn out.

    And of course no one in one’s sane mind would turn against the developers, it is just that we get a voice here. After all, we are all office:mac users here aren’t we?

  41. eponymous coward says:

    <I> know it’s about the bottom line, and the coders rarely get to make this call, but the integrity in me would force me, especially now that it is approaching a 12th(!) release, to spend one entire development cycle doing nothing but fixing bugs and “fixing” broken features and behaviors; i.e., add no major new features, and simply improve the ones you have. And, yes, I’ll be the idealist, I would want to do it for free. After all, I got paid to do it right the first (eleven) time(s); at some point, I owe my customers something as close to right as possible without charging them again. With the arguable (yet dubious) exception of Windows itself, MS and Adobe are the worst offenders to my sense of right and wrong in this regard. The number of times I’ve “paid twice” for a bug fix is frustrating, but if I didn’t get something new in terms of features at the same time, I would then call it criminal. It is this now accepted cop-out cycle that we all accept as consumers that is now to blame.</I>

    (checks the version number of Office 2004 on his machine)

    Hey, what do you know, it’s 11.2.5. That means two service packs and 5 different bug fixes on top of that. How about that?

  42. NonMSProgrammer says:

    @opensourcefan: “No joke. How much of that code is spaghetti? Do you ever just chuck some of it out and start over to get it slim and stable?”

    Seeing as how you are such a great lover of open source, and open source has the virtue of being freely and readily curled down to your homedir, why don’t you open up OO.org or what have you and see much of that codebase is both ‘slim’ and ‘stable’.  ‘Slimness’ and ‘Stableness’ in large scale user-facing desktop applications are mutually exclusive qualities.  When applications are ‘slim’, they are new, untested, and not battle-hardened.  All those nasty lines of code that make it look like spaghetti are the lines that keep word from crashing when your shitty shareware plugin pees all over Excel’s memory.  Special-case-ridden never looks pretty, it looks all GOTOy and nasty, and its verbose, but it actually works, with real computers and real applications.  that’s where the ‘stable’ comes in.  In something like Office, you can choose one of ‘slim’ or ‘stable’.  You could probably knock off 85% of Office’s features with a crack team in a couple of months, and the code would be crazy slim, but it would crash when a bidirectional language is associated with the user’s locale.  It would crash without the right-to-the-third-decimal-place version of some bizarro library you are calling into installed.  It would crash when the temp directory hits 100% disk utilization.  It would crash when the user installed ‘Top10EssentialExcelAddins’.  Etc. etc.

  43. Will Bateman says:

    We can give you some well written functions (in C/C++) to link into Excel and replace your existing set, but without the bug (think dates) and a tad faster: e.g. http://www.codecogs.com/d-ox/units/date/workday.php”>http://www.codecogs.com/d-ox/units/date/workday.php

    Only a small portion of all the code you need to review, but a start 😉

    Good luck

    Will

    http://www.codecogs.com

  44. “Office 2004 is less stable than Office 2001 in Classic. How many more million lines of code are there in 2004 than 2001? and no you can’t kill me if you answer that.”

    That’s simply ridiculous. Entourage is far more stable in 2004 than it ever was in 2001, the same for Word and PowerPoint. My “monthly DB compact” that I had to have in 2001 is a thing of the past and good riddance.

    “I was at a talk given by the WOZ and he was telling this tale of how back in the day of the great desktop wars, 97 era, he was convinced that the only thing making his Mac OS 9 crash was IE, not even while running, just by installing, you’d have a machine that started crashing, and it was just his machine, everyone he talked to who had installed IE had an unstable machine, and the only person who didn’t have problems turned out to be a Netscape user…”

    That’s funny, since MS didn’t write that installer. InstallerVISE. As well, Netscape was always more unstable, and *bloated* than IE Mac ever was. Woz is a smart guy, but I’d want debug logs on that claim.

    “In the next version, please make the installer strip out the code for the chip architecture our Macs don’t need. Or, make sure that apps like “Trim the Fat” which will strip out intel code for PPC Macs or PPC for Intel Macs will not render the Office apps unusable. Thanks.”

    so wait, you complain about too much bloat, then you want them to add code? Oh wait, this is a feature YOU want, so that’s not bloat.

    And can someone tell me why OO is almost as big as Office 2004 if it isn’t all bloated?

  45. "Hey, what do you know, it’s 11.2.5. That means two service packs and 5 different bug fixes on top of that. How about that?"

    Oh now you’re just using facts. Pfft, like THOSE matter.

  46. Matt Evans says:

    Can’t you get some of the many extra coders from the Windows Office version to give you guys a hand. Surely they are not all needed now that Office 2007 is good to go.

  47. "Can’t you get some of the many extra coders from the Windows Office version to give you guys a hand. Surely they are not all needed now that Office 2007 is good to go."

    Because they’d be useless until they learned how to code on a Mac? Different IDE, different build process, different OS rules, and mostly different code.

    throwing more people at a job doesn’t make it go faster. Took 4 years for Office 2007, and what, 6-7 years for Vista all well and told. If headcount made a diff, then Office 2007 would have taken about a day.

  48. Brooks Bell says:

    We have similar issues with QuickBooks Mac – 2M lines of code, 7 developers.  Users don’t understand how hard it is to refactor old applicatons.  Some say, hey – just fix bugs and do nothing new -but that isn’t feasible.  You HAVE to have a Universal Binary version, you HAVE to read the latest Windows formats, you HAVE to maintain backward compatibility, you HAVE to support the latest OS versions.  These things touch ALL the code and introduce lots of new bugs that you have to fix or else your quality goes down.

    Anytime you do anything major to refactor you introduce a bazilion bugs.  People look at QA to developer ratio when what really matters in most old code is the QA to LOC ratio.  How quickly can you do a full regression?  Automation can help a lot here and I’m sure you have some but that takes tremendous resources to maintain.

    We moved to Mach-O, we moved to XCode, we moved to a Cocoa app, we replaced the underlying DB with open source SQLite.  Every one of these changes was extremely painful, added nothing to the back of the box, and entailed considerable risk.  It was very difficult to get buy in for these things in an organizational structure, where only the engineers really understand the problems that the old code is causing because it is all too complicated to explain.  

    Its much more common for marketing, management, and QA to want to avoid touching the old stuff.  They just want to add new functionality, which typically means yet more layers and wrapping, and a deeper technological code debt.  

    At the same time, you have to sell new boxes, or else you can’t maintain the profit margins and pay the salaries of all those engineers who are doing the work.  The organism dies if it doesn’t have this cash infusion.  It makes now sense to a corporation to maintain something unprofitable.

    At least MS has given you a relatively long cycle to deal with this.  Sounds like you are making some correct steps: mach-o, getting rid of the asm (at the cost of features – it is very difficult to balance it!).   If you make enough of these steps you’ll end up with a tough short term but eventually it will get better.  Though there is no guarentee that you’ll be around that long.

    Meanwhile the Windows version has 10x the resources, at least, and you are expected to not just keep pace but actually close the gap.  Or exceed it.  And to do this the Windows side has to be willing to play along, which means some hit to them, and they are 95% of the revenue.

    The turn over rate is troubling.  I think that can be improved by updating your technology as well.  How many people really want to struggle with such an ancient monstrosity using antiquitated languages and development methods?  There has to be real management buy in to embrace newer techniques and compensation to attract the best.

  49. Shufti says:

    Thank you so much! I just wanted to get an idea of how long it will be for the new WORD. Getting the gist of your interesting story…it will take some time. But now at least I know there’s a lot of work going on. More than I can imagine. My only constructive comment is the use of the word "turnover" when you were talking about 50%. Based on the meaning of the whole paragraph I was understanding that you had 50% new blood joining your development team. Is that right? Because if it’s 50% turnover, meaning half the team has quit and been replaced, whooo nelly! What’s going there? I’m assuming it’s new raw talent you’ve just hired 🙂 Keep up the great work. Looking forward to the new WORD.

  50. Geoff Price says:

    The 50% "turnover" figure has gotten a lot of attention, here are a few quick comments on that for those who are interested (apparently many.)

    If you frame it in terms of releases and ask how many developers are new to the product since we last shipped (two and a half years ago), you get pretty close to 50%. In Mountain View I think you need to count the Connectix people as new to get there – which is true in the sense of Brad’s article, i.e. new to Office, though they were here working on VirtualPC for Office 2004 Pro.

    Some breakdowns to put things in perspective:

    * A significant number of the new devs are growth hires, i.e. the team is larger than that which shipped 2004.

    * In Redmond, turnover sort of caught up with us after 2004 shipped, as we had experienced strangely low turnover after shipping Office v.X (just one developer, the team manager, left for a position in the Indigo group.) By the time we completed 2004, a fair number of veterans were ready to move on to something new.

    * Quite a few of those who left retired, or anyway quit with no near term plan to work. Traveling the world some of them. Btw we could use more postcards, you know who you are.

    * As Brad mentioned, many more of those who left did so for other opportunities inside Microsoft. The reality is that MS is an expanding company with many interesting jobs in everything from internet services to games to mobile devices to developer platforms, and the wealth of options for career experiences is a big plus for many. (You can read about one ex-MacBU dev’s new job via this link on the sidebar: http://technosloth.blogspot.com/, and of course it works the other way as well, e.g. http://garyritchie.blogspot.com/)

    The influx of new people has definitely been part of the challenge of this cycle, both for the old people to do a ton of scrutinizing interviews to find the right people to bring in, and for the new people to ramp up on our code base. Many of the great ‘new’ people hired up to two+ years ago are carrying pretty heavy loads at this point. Right now we’re glad to be over the big hiring hump and focusing on getting it done (though, still have a couple of newly added dev positions open for the moment, per jobs link.)