Thirty Million Lines and Counting: Is There No End to Software Bloat?
November 3rd, 2006The other day I read a short article at Microsoft’s Mac Mojo blog that revealed that the Mac version of Office contained some 30 million lines of code. And that’s now, while they are still creating the next version of the productivity suite. You can expect that awesome number to grow by leaps and bounds before all the work is done.
At the same time, they’re promising that they’ll deliver good performance in both the PowerPC and Intel versions. For the sake of argument, I’ll accept the fact that the crew at the Mac Business Unit are really trying to build good software. In fact, my impression is that they are quite dedicated to their jobs, and are really enthusiastic about Macs. They aren’t just there for window dressing, because Microsoft makes a nice profit from Mac software. Too bad there isn’t more of it.
But the sheer bulk of their code base only demonstrates a microcosm of the problem in the industry. Some years ago, I read an article in the late, lamented Byte magazine talking about how faster processors and speedier hard drives with greater and greater capacity combined to make programmers careless. In the old days, they had to make the code tight and fast, because storage devices and processors were slow. As things sped up, they didn’t have to optimize their software quite as much. That, and the need to add features to entice you to buy regular upgrades, created these sprawling programs that are monumental resource hogs.
So you shouldn’t be surprised that almost every new version of an application seems to perform slower than its predecessor on the same hardware, particularly if you have an older computer. So you are forced to consider buying a competitive product — if one is available of course — which may suffer from the same shortcomings, or rush out and upgrade your Mac to the latest and greatest.
Yes, it’s a vicious circle, and I suppose you might even attribute it all to a conspiracy on the part of hardware and software makers to force you to upgrade.
Of course, I suppose you might expect this of a computationally intensive rendering application, which must process audio and video. As more and more capabilities are added and enhanced, you can perhaps understand why an application’s resource requirements will also increase. But a word processor, a spreadsheet? A desktop publishing application?
Should it really require a supercomputer to move and display text on your screen? You could do that in the 1980s with reasonable speed on hardware that had only a fraction of the power of today’s dual- and quad-processor behemoths.
So are programmers just becoming lazier and lazier, letting the hardware substitute for good development practices?
Well, as most of you know, I am not a programmer and I don’t play one on TV. I don’t pretend to know all the intricacies of building a sprawling application with hundreds of powerful features and state-of-the-art sophistication. I am sure some will weigh in that I just don’t understand why things are the way they are, and perhaps building portable code that runs on many processors and operating systems has its tradeoffs. No doubt.
I’m also sure that lots and lots of those developers will tell us about the incredible tools they’ve created that do run well on older Macs, and about all the optimization work they’re doing to make them use as little memory as possible. True, there are lots of smart applications out there that do seem surprisingly adept without being resource hogs.
At the same time, whenever I launch certain applications on a computer with two or four processors, scads of memory, and the fastest hard drive available, I wonder why long seconds pass by before the lumbering beast gets up and running. I wonder why even the most basic tasks produce spinning beachballs and deliver dialogs that seem to be drowned in quicksand.
What have we lost over the years, and how many care about reclaiming it? In fact, does it really matter. All you have to do is buy a new Mac, and everything will be right with the world again, or will it?
Print This Post
Aint that right! Just look at this little app called Instant PDF. It a memory HOG even when you’re not using it! Incredible.
The issue resides at a higher level. If a company has the policy of selling on a laundry list of features, bloat is what you get. The alternative is a more limited and focused program that performs its appointed task well. I am a programmer but I do not play one on TV.
This is an issue with almost all commercial software. In order to keep sales high, there must be a compelling reason to buy or upgrade. On Mac, support for the latest version of OSX is a good one, with our more rapid upgrade cycle. But Windows software hasn’t had that option for over 5 years. So they have to “improve” the offering and under the hood enhancements don’t sell to beancounters.
Personally, I prefer to use apps designed for a specific, narrow purpose. If I want to write, I use TextEdit or vim, Firefox for Web, NetNewsWire Lite for RSS, VLC for movies, Cyberduck or Terminal for FTP. This traditional *nix approach means that each app is as small as possible, as it does only one job, but does that damn well. If I need to do layout, I’ll do it in InDesign, not Word.
The right tools for the jobs. I need a screwdriver, not a medium range torsional fixing implementation, optimised for ambidextrous, multi-material utilisation.
Instant PDF does only one thing: certifie a PDF.
Enfocus said Instant PDF is such a memory hog because they “wanted it to function the same on a mac and a PC”. What the heck is that suppose to mean? PC is crap so so should the mac?
I’m not a programmer either, but I read an article eight years ago by David K. Every where he said that the Cocoa API’s had all the basics of a word processor built in. He said that it took 200 lines of code to make a completely functional word processor. If this is so, then Microsoft Word’s code must not only be bloated, but old, old old.
I know that many Macintosh developers have complained about how much work Apple’s shifts in hardware and software have caused them. Apple went from the 68k chips to PowerPC and now to Intel x86 while the software went from System 7 to Mac OSX. Each shift gave the developers a chance to upgrade their methods. The Xcode compiler, so I am told, is quite up-to-date and the Carbon and Cocoa API’s are quite mature and predictable. Many developers are taking advantage of the move to Intel to migrate out of Carbon API’s into Cocoa, because they can’t trust where Apple will go next. The upshot of this is that Mac OS X application software is probably newer and less bloated than anything on Windows.
So, If you consider Mac applications bloated; how bad must the average Windows app be? Pretty bad.
Realize that 30 million lines of code include the applications Word, Excel, Powerpoint, Entourage, and any extra tools to go with them. It’s not just 30 million lines of code to type text on a screen. What’s a baseline for normal code vs. bloatware? Can any real commercial programmers out there care to comment?
I second this lament. Untold kilobytes (heh) of tight software are history along with with Classic, no longer available on any new Macs. Not that I don’t love OS X, but I wish Apple would offer a PPC card (like the old DOS card) for running OS 9 in a Mac Pro if they aren’t going to port the software.
I so agree…
I remember using Photoshop 3, Quark 3 and Illustrator 6 for years. They were stable beasts and of course you needed up to 96 megs of ram to run them simultaneously on Mac (OR PC, for that matter). I use graphic software profesionally, so a certain level of hardware is required. From what I have seen around me in businesses of all kind and size is that on a office level no real functionality has been added in these applications like Word, Excel,etc. What I totally fail to understand is how this IT world – with all its’ analists, specialists, system-managers and what have you- continues to support this and manages to justify the phenomena to their corporate peers. Has efficiency really improved? I don’t think so. Are there -after 20 years of GUI- any easy to use visualisation tools? I don’t think so. Clearly, we should have app-independant file formats by now, unless maybe for some networked cad monstrosity one needs to design the next Airbus or fighterjet. If we truly want the third world to develop, why must someone over there buy software to be able to open a .doc file? What are these people thinking, then, having a paperclip dancing around your desktop.
This is not a programmers’ issue; it is a design issue. It is about creating an accessible virtual workspace where stuff does what it is supposed to do and there it ends, thank you. The clouds, the dancing paperclips, the moving texts and all the other crap should be saved for websites. So you know right away; this is not for me…
IF the old programs did everything you wanted and did it as fast or faster, then WHY have you gone to new OS’s, new programs and new hardware???
A basic data base on a ][GS could keep track of all one’s books, CDs etc. Why should anyone want an Intel iMac with Mac OS 10.4 so they can run Delicious Library with fun graphics? Why is anyone “upgrading” from a Mac 7200 90 running 8.6?
And surely there must be a program that handles text just like a typewriter. None of that “fancy” word processor stuff!
Acknowledging the facetiousness of the above, Dan is correct. Figure out exactly what functionality you really need and buy specific applications for just that functionality.
Oh, you’re not sure what you might want or need? Guess the programmer better include “a couple” more things for those people who think they will need more features – even if they never really use them. Just read the reviews. X program does this and this, too. Y program doesn’t but is slightly faster. What program is purchased more?
Even OS’s! Just look at all the talk even on this site about all the new goodies that will make 10.5 “better”. At what “cost” in increased code. IF Apple could somehow write OS 10.4 so that it was, say, 10-20% faster with no other changes and could offer it for sale against 10.5, which do you think would sell?
What are the “economics” of even just taking the time to write perfectly optomized code? Not making a program available to the public until it was. People are already asking for a 10.5 “Beta”!
The upshot of this – in MY opinion – is that (except for some programs that are just exceedingly poorly written – NOT a knock on MS as, for what they offer and what the “public” wants, I think they do very good work.) it is not the software companies that we should point fingers at. And not the programmers. It is ourselves. If you don’t like “bloat” and its speed penalties, then buy limited programs. These can often be written by 1 programmer, not a committee that must coordinate their pieces.
Personally, I like all the flash. I’m looking forward to 10.5 for more “flash” and the things that that “flash” will allow other programs to do.
But are all these things “needed”? I don’t think so. (Even for professionals, though some things will surely make them slightly more “productive”.)
Do they make my life “better”? I would say subjectively “yes”. Esthetics and elegance matter. To me. It’s part of the reason I use Macs, not Windows.
In the grand scheme, all the arguments FOR tight code lose out to all the marketplace realities that argue for the programs we have.
Pogo wins again! “We have met the enemy – and they are us.”
As a former programmer, I can attest to why program bloat occurs. The majority of it, if the programming office is worth its
salt is documentation. You need proper documentation for others to build on your project and come back to it later when you retire or leave the office. Many enter in comments right within the code. A better documenter would find a way to link to pages of the code in house with an internal website and documenting each step of the way, and leave the program bloat out of the final product.
Similarly, documentation can be incorporated into huge help files, huge PDF files, or plain text files. It is all a matter of design. Microsoft’s biggest offense in Office 2004, is there insistance on maintaining an all your eggs in one basket approach to Entourage. Since the beginning of Entourage, it has been a huge problem when the database becomes corrupted to recover data. Had they separated the files for email, addressbook, and calendar, I might have stuck to using Entourage. I’d rather deal with less functionality a single file which can corrupt so easily.
I think it’s easy to sit back and be an armchair quarterback but harder to have the real knowledge to understand. We are talking about a codebase that has worked for 20 years on an evolving platform, arguably one of the oldest on the platform. Do you have a 20 year old commercial application with all the myriad components of Office with a sourcebase you are willing to put up for statistics? Cocoa does not provide the dearth of support necessary for Word, or any other parts… Cocoa isn’t magic, it’s simply another API. If you think it’s easy, grab a book on Cocoa and start rewriting Word. When you match the features of that 1 app, including full document compatibility, let me know. You’ll have 4 others to go, not including the little mini-apps.
On the Mac platform, you have a few separate applications that do most of what Word and Excel do, taking up a smaller memory footprint and working fast on slower processors. But it’s not a question of restarting from scratch in Cocoa. It’s now whether it’s possible to take the existing code base and trim it of unnecessary bloat, to better optimize performance and improve compatibility. I would hope that, in moving to Apple’s Xcode for the Universal version of Office, the programmers at the Mac Business Unit will be able to get rid of some of the dead wood along the way. But I’m not holding my breath.
Peace,
Gene
Office 2004 is a very large suite of feature-laden programs that takes up a good chunk of space on my hard drive. That said, it is very fast whether I use it on my fast 2.16GHz G5 iMac or slow 1.0GHz Power Mac G4 (ancient Sawtooth model). If all of those lines of code made it perform poorly on the old G4 I might complain, but then that G4 is 7-years-old, and while the processor is only 4-years-old, the rest of the system is a slug by modern standards. That slug runs Office 2004 and the latest update of 10.4.8 very quickly and nicely, without any undue hesitation or ever making me wait more than an extra second or two for the privilege of running modern bloatware on an ancient computer. I would call both 10.4.8 and Office 2004 incredibly good programming despite the bloat. Apple and Microsoft have done a terrific job of making their software perform well on older and less capable hardware.
Memory efficiency, speed, and especially source code length (what you seem to be calling bloat) ceased to be high priorities in consumer software years ago.
Nowadays, reliability, robustness, readability (make the code easy to understand so many people can work together on the code) , portability, and meeting the deadline, rank far higher in the priority list.
This is a good thing. Working code is better than fast code.
I agree, though, that feature expansion: when marketing is driving the product instead of use case, is a problem.
What seems to be missing in this discussion is how a company would attain a goal of “tighter” code–and who would pay for it.
Optimizing code is expensive, just as with composition. If you don’t believe this, write an article (even a comment here) and then go back and optimize it to take out every unnecessary word. Editing can take several times as long as the original effort. As Blaise Pascal [url=http://www.quotationspage.com/quote/26931.html]wrote[/url], “I have made this [letter] longer, because I have not had the time to make it shorter.”
Someone would have to pay for that time. Would you be willing to spend $800 for an “optimized” version of Office? Despite all the moaning and groaning about the cost of software, a lot of software today is cheaper in constant dollars. Going back and cleaning up old applications would waste resources, but that is exactly what you’d have to do, as most of today’s applications are incremental changes from earlier versions, not total re-writes. They build on what has already been written–why redo the code for a Gaussian blur, for example, even if you could save 20K in code? A company that wasted money like that would deserve to go under and/or the management should be thrown out by the stockholders.
It’s interesting that Dan chose Firefox as one of his “narrow” applications, even though it does RSS (not as well as NetNewsWire, I suspect). Firefox was the largest browser I tried, at 50 MB. (I’m not counting Sea Monkey and other “suite” applications.) Camino is 40 MB, Opera 30 MB, iCab less than 20 MB. I don’t know how large Safari 2 is, but 1.3.2 (OS 10.3.9) is also under 20 MB. This shouldn’t be surprising: open source applications are logically unlikely to be optimized. Why would anyone spend hours and hours to take out 50K of code that won’t improve the function of the application?
My Apple days may go back almost as far as Gene’s (1984, Apple //c). My first Mac, a PowerBook 100 bought in 1992, had only 8 MB RAM and ran at 16 mHz, so tight code was appreciated. (Anyone remember Write Now? It was a word processor written in assembly code to be as tight as possible. The only problem was that, whenever Apple made some small change to the OS, they had to redo the application. It’s no wonder that they disappeared.) Today, however, with 2 gHz+ Macs with 1 GB+ RAM, it isn’t as critical.
Then, too, except in those few instances where someone has to maintain compatibility with clients or suppliers who upgrade, no one is forced to upgrade computers, OSes, or applications. It’s shocking how many people act as if, when Apple comes out with a new Mac or OS version, theirs ceases to function at all. The worst, though, are the Luddite-like folks who use ancient software and computers and sneer at others who have chosen to use–or NEED to use–more modern sysems. (I wonder if they live in log or sod homes. If not, why not?) Their ’67 Chevy Nova will get them from place to place, but my 2004 Prius will do it more comfortably, on less gas and with less likelihood of injury in an accident. Their AppleWorks GS on a IIGS will be OK for keeping a list of CDs, as SteveP said, but will it support a business that needs to connect customers, inventory, product descriptions, invoices, etc. without a relational database like FileMaker Pro.
To turn Gslusher’s explanation into a simpler one-liner:
Do you you pick up the box and look for the bullet point – “Reduced codebase size by X lines” or some marketspeak reinterpretation when shopping for software?
I used WriteNow. I hate MS Word, at least the PC version. I do not have the Mac version of Office. I actually use Pages on my Mac.
I also used to be a programmer and i have used Word on the mac since the time of the Fat mac with its 512K memory.
The best programming was done on the older smaller systems when space was a problem. Several programmers that I knew felt that WordStar was teh best program ever writtenn – please note that I mean this from a artistic programming point of view, not from the actual functioning of the program.
The first big bloat came when we had the conjunction of the switch from Pascal to C++ and from floppy discs to CD’s. The switch from Pascal included a change to an objective language and further use of large generic frameworks on which to start your application development. The objective programs were easier to write but added a huge chunk of code that could not be cut as easily at final compilation as the program itself is never sure what scope of its object model will need to be utilized. In Pascal, all code not called by one of the program mdules would be stripped leaving much leaner programs. I wrote Pascal programs that played games or performed other options and some were less than 2K, whereas i never saw a C++ program near that size.
MS Word 6 was the worst program that MS ever wrote. This was due to their attempts to do too much. They needed to update the program to keep up with the Windows version and added in VBA. The program was large, clunky, and slow and they issued a major fix a few months later.
My problem with the new office is that they plan to remove much of the functonality that kept me using Word in the first place. I have over 200 pages of macros written for Word that will not work on the 2007 version, because VBA has been stripped. I may switch to another program if i can find the same functionality or just keep 2004 for as long aas I can, possibly getting older hardware to run it on.