Bloadtware: I think Joel missed the point : LUSENET : Joel on Software : One Thread

Ok, I already sent this (in slightly different form)to Joel, but seeing that this forum here actually has traffic, I'd like to give my view:

I can't disagree with the content of Joels column (it is pretty hard to release bloatware nowadays when keeping in mind how large our harddrives have become), but I think he missed the point. You know, I'd really like to know what Microsoft actually put into those 146MB. That is an insane amount! Not as insane as how large our harddrives have become, but that's a sorry excuse ! It is nearly 10 times as large as the original version. Now does Excel 2000 have 10 times the features as V 5.0? Or are the new features 10 times as complex? I guess they did what they always do: Try to find even smarter algorithms for already solved problems. Let's say a given problem was solved once and it took (this is getting a bit abstract) 1 hour for the machine to solve. Now someone comes up, writes another program that can solve it in 1 minute but takes up 30 percent more space on the disk. That's ok with me, no problem. But now these rocket scientists come in and write a program that can solve the problem in 55 seconds, but takes up thrice as much space! Is it worth those 5 extra gained seconds? No! They do handstands to achieve that, and I surely don't have to tell you about the amount of errors they will have in their bloated code. These extra clever algorithms tend to outsmart even the author. They are more complex and larger and hence it is harder to overview them completely anymore. You can't think of all cases and you won't see if you missed something. Which one of the mentioned releases would you choose? I'd go for the second one any given day! So I like to find the best compromise between speed and bloat. Just think of the MIR. OK, they had to use chewing gum in some places to keep it running, but it ran 15 years where they predicted 5! It was the way a lot of russian built devices are: Simple, but extremely robust and reliable. I doubt that the new station they are building up there won't outdo that, but just think of the insane effort they are putting into it! They will spend (I'm just guessing now) 10 times the money but will only outlive it 2 or 3 times! Now wouldn't it have been smarter to build another 2 or 3 MIRs instead?!? To come back to the original subject (and to some Microsoft bashing as well (hard to resist these days...)): In the first place we had Netscape. It became bigger and fatter with every release, and in my eyes, it surely is bloatware (though defrag won't even give a whole pixel for it when visualizing it on the harddrive). Now Microsoft came in with their shiny IE and tried to compete. (On a funny note, I don't have data at hand, but I bet they took market leadership exactly at the moment their code size outgrew Netscape's...) So now you have two fat browsers competing (well, not really, but that's another story), where the _real_ evolution goes into the direction of something like Opera or konqueror. Microsoft is still growing at the size of all of their products, while others are already shrinking, and I wonder when they will get the point. Bloatware is not about the size on the harddrive, it's about the unnecessarily complex stuff that bloats it! People prefer robust and reliable solutions over the rocket scientists' one. And that doesn't contradict to including rarely used features...

-- Anonymous, March 27, 2001


I think you are simply changing the subject here. If you want to discuss the quality of code as measured by bugs or lack thereof, that's a whole different issue and one that Joel did not attempt to address. You're making a giant leap of faith in equating bigger executable with buggier code. I don't think the correlation is as strong as you are implying. What's your evidence? Where's the data? Examples even?


-- Anonymous, March 29, 2001

Well, to my understanding, Joel tried to show that there is no such thing as 'bloatware' in the context of sheer size. But I think that most people, when refering to bloatware, are not as much concerend about the size the program takes up on the harddrive, as they are about why the programs exploded in size anyway. Most people don't care whether Excel takes 15MB, 146MB or even 1460MB on the disk. But they do care about why exactly these programs are increasing in size so much. Like somebody in the 'In defense of Bloatware' thread pointed out: If a small application (can't remember which one it was) takes 10 seconds to start, then something went obviously wrong. And it doesn't matter how large that application is, but as a matter of fact, especially these slow, fat applications also tend to take up a huge amount of diskspace. I think that discspace is only a sympthom, but the real evil is behind the let's-optimize-the-hell-out-of-it-to-get-a-0.1-percent-speed-increase attitude. As for an example, let's compare the linux kernel (which is as transparent as it can get) with the NT kernel (of which not much is know except that it has appr. 30 million lines of code): In the linux development, as you can see on the kernel traffic mailing list, Linus tries to keep things simple and is in great favour of patches that actually remove code instead of adding code. The advantage is that mechanisms are easier to overview and optimizations on a high level with all their consequences are pretty transparent. On the other hand, did you ever wonder why NT takes half a minute (with the system being unusable throughout) to maximize a WinWord that has been minimized on a machine with 512MB ram a few hours ago where otherwise not much is going on? Somebody had a 'clever' improvement for the pageout algorithm... I can't claim to be a 'real' veteran, but I have been long around and seen enough stuff to have a pretty clear understanding of at least one reason why projects fail: Add all these shiny improvements to get even the last bit out for performance. Then someone leaves the team, the next one hasn't written the code and therefore only understands 80 percent of it, and he surely won't touch the optimizations. Instead, he will add new parts instead of fixing the old stuff up. And this goes on and on and on. And you end up with Word 2000 or XP or whatever. Joel gave some pretty interesting insights into Word, and as long as they try to integrate speech recognition instead of fixing the various footnote bugs (I guess they are too afraid to touch anymore...), Word surely won't shrink. And all because some people always have to add that last bit...

-- Anonymous, March 29, 2001

Robert Anderson writes: > You're making a giant leap of faith in equating bigger > executable with buggier code. I don't think the correlation is > as strong as you are implying. What's your evidence? Where's > the data? Examples even?

From _Code Complete_, a book from Microsoft Press:

"You would naturally expect a project that's twice as large as another to have twice as many errors. But the density of defects, the number of defects per line of code, increases."

From a study by software metrics guru Capers Jones:

Project Size (thousand lines of code, or KLOC) vs. error density: < 2KLOC: 0-25 errors per KLOC 2-16KLOC: 0-40 errors per KLOC 16-64KLOC: 0.5-50 errors per KLOC 64-512KLOC: 2-70 errors per KLOC 512KLOC+: 4-100 errors per KLOC

If I raid my software engineering books, I'll wager I can find more.

-- Anonymous, March 29, 2001

My gripe with bloatware is that it wastes bandwidth for users who want to download it.

Take the supposedly insignificant regclean utility. Most people who want to use this program will have to download it from Microsoft's website. But they'll be downloading a file that is more than 10 times larger than it needs to be.

If you were designing a website, you wouldn't force every visitor to download a "splash screen" a couple of hundred KB in size, just for arriving at the site. So why should one be included in a software download?

-- Anonymous, March 30, 2001

While Joel's take on bloat is interesting to read (it's always good to hear a dissenting voice), I think he's taking too limited a view of why it's bad. OK, so Excel is ten times as big but only requires 1/36 the hard drive money. And agreed, my hard drive is something like 1000 times as big as it was in 1993!

But it's not anything like 1000 times as fast. My bus is only about five times as fast as it was in 1993. I didn't have a CD-ROM drive in 1993, but if I did, it would have been exactly the same size as the one I have now. Joel is picking and choosing his specs too carefully for the "bloat is OK" argument to be very convincing.

The rest of the article reads rather too much like an apologium. Yes, _if_ the programmers don't have to worry about program size, maybe they can spend their time on features and release earlier. But he doesn't provide any evidence that this is actually happening. I suppose there are more "features", in the sense of check marks (than the competitor's product!) on the marketing department's feature list, but more features that are really _useful_? Joel as good as says that all of the "80% features" are present in version 1.0 of any software. For his apologium to be convincing, he'd have to show that newer software gets released earlier (in _as_good_condition_ as software that took longer) and has more features, _and_ that this is truly incompatible with small executable size, and not just the result of programmers being sloppy.

Oh, and one last thing: Joel says, "I haven't run out of memory in more than a decade, ever since virtual memory appeared in Windows 386." Well, if he would care to come over to my house, I'll show him my laptop with Windows NT4 on it (64 MB of memory), and I'll run it out of memory with ease for him.

-- Anonymous, April 02, 2001

I take it for granted that there is a decreasing rate of return for usefulness (functionality or whatever you like to call it) as size increases. I.e. improving a program by 10% will require progressively more that 10% in size the larger you get. You can write a nice text editor in a few k for msdos or unix, or in a few megabytes for Windows (or Gnome/Motif/KDE whatever).
So the real questions are: 1) Are Microsoft on the curve, below it or what? 2) What is the real cost? I think Joel's point here about cost of storage is right on the money (pun?) Why even try keeping the size in kb down, when that is already costing seemingly exponentially less every day. Mere size is too simplistic to be interesting.

-- Anonymous, April 03, 2001

language technology, compilers, static run-time libraries, OS APIs are some of many factors that affect the size of your binary.

we're talking about code here, so can someone give an insight into the data/code ratio of the entire Excel program? i tend to think that an average application has alot more data than code. just how much of that 146MB is code?

in anycase, i think 146MB for a program like that is ridiculous. someone mentioned that optimizing adds code size. half-true! adding code tends to make it slower. why? CPU architecture. the code cache is really quite small. and adding code almost always add more branches as well, and modern CPUs hate branches. the more modern, the more they hate branches.

i started my programming life in the underground demo scene. not so underground anymore though. every now and then, there comes a 4KB (4096 bytes) real-time graphics demo that shocks me. i remember one that rendered Descent (the 3D game) levels and had MIDI sound, all in 4KB. another famous, called Giantshow, ran >10 effects, for 5 minutes. there're raytracers in 4KB. fractal zooms, procedural textures, wavelet decompressors, 3D engines, keyframers, sound synthesizers, MP3 decoders etc., u name it. visit and to find out more.

yes, these are highly optimized unmaintainable unreadable assembler code. it represents an extreme. but if application programmers have some of such mentality, we wouldn't have 146MB Excel, 500MB Windows 2000, 1GB Mac OS X and 20 nested function calls to start a Java applet.

-- Anonymous, April 19, 2001

Here is my admittedly paltry Office 97 directory contents (Word and Excel Only). Sizes are in Kilobytes. Note that the Office directory is where most of the "bloat" is. The EXEs and DLLs of Excel and Word are only 19MB of the 46MB total. A good amount of that is shared between the two apps. Of course, a proper accounting of MS Office should also include the contents of the MS Shared components directory, but I have not included that here. It would be interesting to compare the code/support file ratio in Office 2000. (Sorry in advance for the size of the post). 0 ./Office/MSCREATE.DIR 0 ./Office/Setup/MSCREATE.DIR 100 ./Office/Setup/WRD97INV.DLL 80 ./Office/Setup/ACMEWORD.EXE 3 ./Office/Setup/ACMEWORD.LST 249 ./Office/Setup/Word97.stf 100 ./Office/Setup/XL97INV.DLL 80 ./Office/Setup/ACMEXL.EXE 3 ./Office/Setup/ACMEXL.LST 203 ./Office/Setup/Excel97.stf 818 ./Office/Setup 36 ./Office/PSS8.HLP 1 ./Office/PSS8.CNT 39 ./Office/EULA8.HLP 1 ./Office/EULA8.CNT 313 ./Office/VBAOFF8.HLP 165 ./Office/VBAOFF8.AW 10 ./Office/VBAOFF8.CNT 581 ./Office/OFTIP8.HLP 10 ./Office/OFNEW8.HLP 1 ./Office/OFNEW8.CNT 1941 ./Office/WDMAIN8.HLP 80 ./Office/WDMAIN8.CNT 396 ./Office/WDTIP8.HLP 676 ./Office/WDMAIN8.AW 80 ./Office/WDNEW8.HLP 2 ./Office/WDNEW8.CNT 1561 ./Office/GRAPH8.EXE 109 ./Office/GRAPH8.OLB 5 ./Office/GR8409.DLL 158 ./Office/GRINTL32.DLL 6 ./Office/GRAPH8.SRG 183 ./Office/GR8GALRY.GRA 18 ./Office/VBAGRP8.HLP 1 ./Office/VBAGRP8.CNT 509 ./Office/GRAPH8.HLP 290 ./Office/GRAPH8.AW 17 ./Office/GRAPH8.CNT 5200 ./Office/WINWORD.EXE 1 ./Office/SBE97.JFD 449 ./Office/MSWORD8.OLB 27 ./Office/WINWORD8.SRG 0 ./Office/Borders/MSCREATE.DIR 51 ./Office/Borders/MSART14.BDR 27 ./Office/Borders/MSART15.BDR 57 ./Office/Borders/MSART3.BDR 15 ./Office/Borders/MSART4.BDR 47 ./Office/Borders/MSART2.BDR 16 ./Office/Borders/MSART5.BDR 54 ./Office/Borders/MSART6.BDR 4 ./Office/Borders/MSART7.BDR 48 ./Office/Borders/MSART8.BDR 50 ./Office/Borders/MSART9.BDR 10 ./Office/Borders/MSART10.BDR 32 ./Office/Borders/MSART1.BDR 31 ./Office/Borders/MSART11.BDR 58 ./Office/Borders/MSART12.BDR 28 ./Office/Borders/MSART13.BDR 528 ./Office/Borders 1132 ./Office/WWINTL32.DLL 39 ./Office/WDREAD8.TXT 48 ./Office/EMAIL.DOT 48 ./Office/HIGHTECH.DOT 49 ./Office/FLAME.DOT 47 ./Office/URGENT.DOT 47 ./Office/OCEAN.DOT 53 ./Office/RAIN.DOT 50 ./Office/MIDNIGHT.DOT 2461 ./Office/VBAWRD8.HLP 93 ./Office/VBAWRD8.CNT 497 ./Office/VBAWRD8.AW 51 ./Office/OSA.EXE 3694 ./Office/MSO97.DLL 476 ./Office/MSO7ENU.DLL 9 ./Office/MSO97FX.DLL 6 ./Office/OSAINTL.DLL 1 ./Office/HLINK.SRG 2 ./Office/MSOFFICE.SRG 6 ./Office/MISC.SRG 3 ./Office/MSO7FTPS.EXE 3 ./Office/MSO7FTP.EXE 3 ./Office/MSO7FTPA.EXE 1 ./Office/CUSTOM.DIC 68 ./Office/BSH32.WLL 0 ./Office/STARTUP/MSCREATE.DIR 60 ./Office/STARTUP/ 152 ./Office/STARTUP/PALMAPP.DOT 212 ./Office/STARTUP 0 ./Office/WordMail/MSCREATE.DIR 0 ./Office/WordMail/Favorites/MSCREATE.DIR 1 ./Office/WordMail/Favorites/Email.lnk 1 ./Office/WordMail/Favorites/Hightech.lnk 1 ./Office/WordMail/Favorites/Flame.lnk 1 ./Office/WordMail/Favorites/Urgent.lnk 1 ./Office/WordMail/Favorites/Ocean.lnk 1 ./Office/WordMail/Favorites/Rain.lnk 1 ./Office/WordMail/Favorites/Midnight.lnk 7 ./Office/WordMail/Favorites 7 ./Office/WordMail 5474 ./Office/EXCEL.EXE 24 ./Office/XL8409.DLL 18 ./Office/SCANLOAD.DLL 37 ./Office/EXCEL8.SRG 542 ./Office/XLINTL32.DLL 33 ./Office/XLREAD8.TXT 571 ./Office/EXCEL8.OLB 224 ./Office/XL5EN32.OLB 5 ./Office/XLCALL32.DLL 175 ./Office/XL8GALRY.XLS 1 ./Office/XL97SPEC.INI 20 ./Office/XLMACR8.HLP 2599 ./Office/XLMAIN8.HLP 1003 ./Office/XLMAIN8.AW 113 ./Office/XLMAIN8.CNT 393 ./Office/XLTIP8.HLP 308 ./Office/WORKFUNC.AW 78 ./Office/XLNEW8.HLP 2 ./Office/XLNEW8.CNT 615 ./Office/VBAXL8.AW 81 ./Office/VBAXL8.CNT 1939 ./Office/VBAXL8.HLP 0 ./Office/Examples/MSCREATE.DIR 133 ./Office/Examples/SAMPLES.XLS 0 ./Office/Examples/Solver/MSCREATE.DIR 128 ./Office/Examples/Solver/SOLVSAMP.XLS 128 ./Office/Examples/Solver 261 ./Office/Examples 0 ./Office/Library/MSCREATE.DIR 0 ./Office/Library/MSQuery/MSCREATE.DIR 66 ./Office/Library/MSQuery/XLODBC32.DLL 49 ./Office/Library/MSQuery/XLODBC.XLA 115 ./Office/Library/MSQuery 28 ./Office/Library/EXPDB.XLS 28 ./Office/Library/INVDB.XLS 28 ./Office/Library/PODB.XLS 47 ./Office/Library/TMPLTNUM.XLA 14 ./Office/Library/COMMON.XLS 0 ./Office/Library/Analysis/MSCREATE.DIR 301 ./Office/Library/Analysis/ANALYS32.XLL 437 ./Office/Library/Analysis/ATPVBAEN.XLA 73 ./Office/Library/Analysis/FUNCRES.XLA 99 ./Office/Library/Analysis/PROCDB.XLA 910 ./Office/Library/Analysis 67 ./Office/Library/AUTOSAVE.XLA 349 ./Office/Library/LOOKUP.XLA 315 ./Office/Library/FILECONV.XLA 328 ./Office/Library/SUMIF.XLA 150 ./Office/Library/REPORTS.XLA 0 ./Office/Library/Solver/MSCREATE.DIR 604 ./Office/Library/Solver/SOLVER.XLA 110 ./Office/Library/Solver/SOLVER32.DLL 714 ./Office/Library/Solver 25 ./Office/Library/UPDTLINK.XLA 95 ./Office/Library/BSHXL.XLA 3213 ./Office/Library 18 ./Office/XLTMPL8.HLP 78 ./Office/XLQPW.DLL 84 ./Office/MSOC.DLL 69 ./Office/MSROUTE.DLL 0 ./Office/XLStart/MSCREATE.DIR 103 ./Office/XLStart/PDFWriter.xla 17 ./Office/XLStart/PALMAPP.XLT 120 ./Office/XLStart 34 ./Office/Distmon.dll 450 ./Office/XLMain8.GID 41900 ./Office 0 ./Templates/MSCREATE.DIR 0 ./Templates/Letters & Faxes/MSCREATE.DIR 61 ./Templates/Letters & Faxes/Contemporary 48 ./Templates/Letters & Faxes/Elegant 48 ./Templates/Letters & Faxes/Professional 463 ./Templates/Letters & Faxes/Fax Wizard.wiz 52 ./Templates/Letters & Faxes/Contemporary 46 ./Templates/Letters & Faxes/Elegant 46 ./Templates/Letters & Faxes/Professional 62 ./Templates/Letters & Faxes/Letter Wizard.wiz 54 ./Templates/Letters & Faxes/Mailing Label Wizard.wiz 48 ./Templates/Letters & Faxes/Envelope Wizard.wiz 928 ./Templates/Letters & Faxes 0 ./Templates/Memos/MSCREATE.DIR 47 ./Templates/Memos/Contemporary 41 ./Templates/Memos/Elegant 41 ./Templates/Memos/Professional 406 ./Templates/Memos/Memo Wizard.wiz 535 ./Templates/Memos 0 ./Templates/Other Documents/MSCREATE.DIR 92 ./Templates/Other Documents/More Templates and 52 ./Templates/Other Documents/Contemporary 54 ./Templates/Other Documents/Elegant 44 ./Templates/Other Documents/Professional 419 ./Templates/Other Documents/Resume Wizard.wiz 661 ./Templates/Other Documents 0 ./Templates/Outlook/MSCREATE.DIR 12 ./Templates/Outlook/EMAIL.OFT 12 ./Templates/Outlook/HIGHTECH.OFT 12 ./Templates/Outlook/FLAME.OFT 12 ./Templates/Outlook/URGENT.OFT 15 ./Templates/Outlook/OCEAN.OFT 12 ./Templates/Outlook/RAIN.OFT 12 ./Templates/Outlook/MIDNIGHT.OFT 87 ./Templates/Outlook 0 ./Templates/Spreadsheet Solutions/MSCREATE.DIR 330 ./Templates/Spreadsheet Solutions/Expense Statement.xlt 297 ./Templates/Spreadsheet Solutions/INVOICE.XLT 308 ./Templates/Spreadsheet Solutions/Purchase Order.xlt 56 ./Templates/Spreadsheet Solutions/Village Software.xlt 991 ./Templates/Spreadsheet Solutions 27 ./Templates/ 3229 ./Templates 0 ./Clipart/MSCREATE.DIR 0 ./Clipart/Popular/MSCREATE.DIR 26 ./Clipart/Popular/AGREE.WMF 2 ./Clipart/Popular/AMCONFUS.WMF 4 ./Clipart/Popular/AMDISAST.WMF 2 ./Clipart/Popular/AMHAPPY.WMF 2 ./Clipart/Popular/AMIDEA.WMF 5 ./Clipart/Popular/AMORGANI.WMF 3 ./Clipart/Popular/AMPROBLE.WMF 2 ./Clipart/Popular/AMVICTOR.WMF 4 ./Clipart/Popular/AMWIN.WMF 5 ./Clipart/Popular/ARROWS1.WMF 3 ./Clipart/Popular/ARROWS2.WMF 3 ./Clipart/Popular/ARROWS3.WMF 4 ./Clipart/Popular/ARROWS4.WMF 1 ./Clipart/Popular/ARROWS5.WMF 3 ./Clipart/Popular/ARROWS6.WMF 2 ./Clipart/Popular/ARROWS7.WMF 1 ./Clipart/Popular/ARROWS8.WMF 2 ./Clipart/Popular/ARROWSGN.WMF 10 ./Clipart/Popular/BANDAID.WMF 4 ./Clipart/Popular/BEARTRAP.WMF 10 ./Clipart/Popular/BOMB.WMF 10 ./Clipart/Popular/BRICK.WMF 11 ./Clipart/Popular/BUILDING.WMF 8 ./Clipart/Popular/CAR.WMF 34 ./Clipart/Popular/CHAMPGNE.WMF 1 ./Clipart/Popular/CHECKMRK.WMF 6 ./Clipart/Popular/CLAP.WMF 11 ./Clipart/Popular/CLOCK.WMF 26 ./Clipart/Popular/COINS.WMF 7 ./Clipart/Popular/DARTS.WMF 3 ./Clipart/Popular/DESTRYER.WMF 3 ./Clipart/Popular/DICE.WMF 4 ./Clipart/Popular/DIPLOMA.WMF 7 ./Clipart/Popular/DOMINOES.WMF 5 ./Clipart/Popular/DONKEY.WMF 3 ./Clipart/Popular/DOOR.WMF 4 ./Clipart/Popular/DOVE.WMF 15 ./Clipart/Popular/DYNAMITE.WMF 8 ./Clipart/Popular/EXAMINE.WMF 9 ./Clipart/Popular/FISTSLAM.WMF 8 ./Clipart/Popular/FLOWER.WMF 2 ./Clipart/Popular/HAMMER.WMF 22 ./Clipart/Popular/HATECOMP.WMF 4 ./Clipart/Popular/HNDSHAK1.WMF 6 ./Clipart/Popular/HNDSHAK2.WMF 11 ./Clipart/Popular/HNDSHAK3.WMF 8 ./Clipart/Popular/JETPLANE.WMF 4 ./Clipart/Popular/JIGSAW.WMF 4 ./Clipart/Popular/KEY.WMF 6 ./Clipart/Popular/LIGHT.WMF 4 ./Clipart/Popular/LION.WMF 9 ./Clipart/Popular/LOCK.WMF 9 ./Clipart/Popular/MAGICHAT.WMF 7 ./Clipart/Popular/MAGNIFY.WMF 5 ./Clipart/Popular/MEETING.WMF 12 ./Clipart/Popular/MEETING2.WMF 11 ./Clipart/Popular/MONEY.WMF 3 ./Clipart/Popular/MONEYBAG.WMF 15 ./Clipart/Popular/OILDRILL.WMF 6 ./Clipart/Popular/OPENHAND.WMF 4 ./Clipart/Popular/PTRUP.WMF 8 ./Clipart/Popular/RABBIT.WMF 3 ./Clipart/Popular/RIBBON.WMF 14 ./Clipart/Popular/RUNNER.WMF 11 ./Clipart/Popular/SAILBOAT.WMF 3 ./Clipart/Popular/SCALES.WMF 5 ./Clipart/Popular/SHARK.WMF 13 ./Clipart/Popular/SOCCER.WMF 2 ./Clipart/Popular/STAR.WMF 3 ./Clipart/Popular/STOP.WMF 7 ./Clipart/Popular/STOPLGHT.WMF 20 ./Clipart/Popular/TENNIS.WMF 6 ./Clipart/Popular/THUMBDN.WMF 8 ./Clipart/Popular/TRIUMPH.WMF 4 ./Clipart/Popular/TROPHY.WMF 7 ./Clipart/Popular/TURTLE.WMF 17 ./Clipart/Popular/WEARHAT.WMF 12 ./Clipart/Popular/WHATNOW.WMF 2 ./Clipart/Popular/YINYANG.WMF 470 ./Clipart/Popular/POP97.CAG 1048 ./Clipart/Popular 1 ./Clipart/Clipart on Word CD.lnk 1049 ./Clipart 1 ./WORDSPEC.INI 1 ./Microsoft Word Setup.lnk 1 ./Microsoft Word.lnk 0 ./Queries/MSCREATE.DIR 1 ./Queries/Detailed Stock Quote by PC Quote, Inc.iqy 1 ./Queries/Dow Jones Stocks by PC Quote, Inc.iqy 1 ./Queries/Get More Web Queries.iqy 1 ./Queries/Multiple Stock Quotes by PC Quote, Inc.iqy 4 ./Queries 1 ./Microsoft Excel Setup.lnk 1 ./Microsoft Excel.lnk 10 ./sizes.txt 46197 .

-- Anonymous, April 20, 2001


Um, what the heck is going on here. How did I get here????

-- Anonymous, July 25, 2001

Ugh. That didn't turn out the way I expected. :(

-- Anonymous, April 20, 2001

Here is a summary of what I tried (and failed) to post earlier: 46MB My Office Directory (Word 97 and Excel 97)

... Some Interesting Big Numbers ...

18MB DLLs and EXEs (The main Excel EXE is 5,604,624 bytes) 11MB Help Files 3MB Templates 3MB Excel Add-Ins

I worry more about runtime memory usage bloat more than disk space bloat.

-- Anonymous, April 20, 2001

I have to agree with Joel on this. It's very easy to confuse buggy code with bloatware, and the two are not necessarily identical.

However, I do have a particular gripe about MS Office products that Joel also tangentially addresses in some of his other columns:

Why do these guys have to change the actions/meanings of some of the features in the product? It's hard enough to learn to format Word documents once... each time a new version comes out there is some feature that behaves differently than the previous version. This is probably due to having 10000 programmers sitting around having less to do than five years ago!

-- Anonymous, April 21, 2001

Moderation questions? read the FAQ