Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Bug Microsoft Programming Technology

Anatomy Of A Bug In Microsoft Office 642

bender writes "An insightful look at what it is like to track down and fix a bug in Microsoft Office is available from Microsoft's Blog site."
This discussion has been archived. No new comments can be posted.

Anatomy Of A Bug In Microsoft Office

Comments Filter:
  • But... (Score:5, Funny)

    by Joey Patterson ( 547891 ) on Friday August 27, 2004 @01:11PM (#10089803)
    • by krog ( 25663 ) on Friday August 27, 2004 @01:14PM (#10089834) Homepage
      Here, drive this Yugo instead.
      • Comment removed (Score:4, Insightful)

        by account_deleted ( 4530225 ) on Friday August 27, 2004 @01:53PM (#10090162)
        Comment removed based on user account deletion
      • by vwjeff ( 709903 )
        Oh, your Ferrari has a broken cupholder?

        Here, drive this Yugo instead.

        Which one is the Ferrari and which one is the Yugo? Don't think about this question for more than two seconds otherwise your head will explode!!
      • by WebCowboy ( 196209 ) on Friday August 27, 2004 @05:51PM (#10092163)
        ...is a pretty good analogy when you thnk about it:

        * MS Word/Office is built around a big, powerful and complex engine, just like a Ferrari. Both are high-performance but tempermental and quirky.

        * OpenOffice is derived from another project (StarOffice) which Sun bought (through purchase of StarDivision) rather than invented itself. The Yugo is derived from the Zastava GTL from Eastern Europe, the design of which Zastava bought (from Fiat for the Fiat 128) rather than invented itself.

        * The casual MS Word user is completely mystified by its exotic internal workings. When things go wrong they must contend with clueless and/or irritated tech support people who offer incomprehensible advice. Proper support is expensive. The Ferrari driver is also mystified by the internal workings of his car, and when things go wrong must contend with a clueless and/or irritated Italian mechanic who offers incomprehensible advice. Parts and labour are expensive.

        * The dealer network was always sparse and is now non-existant, so Yugo drivers must fend for themselves by searching the wrecking yards for parts. The internal workings are primitive but well known to owners--there is no fancy, proprietary technology. Tech support for OpenOffice is sparse to non-existant, so OO.o users must fend for themselves by Googling for patches on the 'net. The source is less complex than that of MS Office and is open, so it is known to many of its users.

        * A lot of people know and use MS office because it is more powerful and popular than the rest, so they put up with all the annoyances and pay a lot of money for it, even though they don't use it to its full potential. Most Ferrari drivers buy a Ferrari because it is powerful and a popular status symbol, so they put up with all the annoyances and pay a fortune for it, even if they can't legally drive it anywhere NEAR it's full potential--and seldom do.

        * Properly cared for, a Yugo can serve you well as basic transportation--even though it has less features than a lot of other cars and is slow to start. OpenOffice, properly used, can serve you well as a productivity suite--even though it has less features than some other office suites and is a bit slow to start.

        * Both the Yugo and OpenOffice can be obtained and used for basically no money and some amount of tinkering.
    • Re:But... (Score:5, Insightful)

      by dan_sdot ( 721837 ) * on Friday August 27, 2004 @01:14PM (#10089840)
      Actually, I have to be honest and admit that Microsoft Office is a good product. Its stable, has alot of nice features and is intuitive to use.
      I am not _at all_ a fan of M$, but we should be fair about this. Office is pretty solid.
      • Re:But... (Score:5, Informative)

        by 1010011010 ( 53039 ) on Friday August 27, 2004 @01:59PM (#10090213) Homepage
        Uh, are you sure you're using MS-Office? Ever have any Bullet Madness? Sudden appearance of Times New Roman? Word saving files it can't later read back in (but OpenOffice can)? 1k HTML files processed into 100K HTML files by Word? Pasting text from one document into another and having the document's margins get reset? ... and that's just today!
      • Re:But... (Score:5, Interesting)

        by mandos ( 8379 ) on Friday August 27, 2004 @02:15PM (#10090379) Homepage
        I call BS on this. I've not been a fan of MS for years, but recently I had to write a business plan and due to decisions out of my control I had to do it in Word and Excel. I am quite good with both but have generally avoided using them since my previous job of training others to use them. After extensive use I can tell you that they are NOT better, people just are willing to put up with more shit from MS. If it's not from MS it has to be perfect, just to be considered. All MS's hand waving about being able to conviently put Excel charts and such in Word documents is BS. It can be done, but not with out a lot of effort to make it worthwhile. I prefer OpenOffice and am more then willing to admit it has issues. However, whenever I have to choose between the two, I'll take the latest version OpenOffice.
        • Re:But... (Score:4, Informative)

          by twiddlingbits ( 707452 ) on Friday August 27, 2004 @02:44PM (#10090644)
          Ditto, ever get a REALLY big document into Word, say 100's of pages..it gets nasty to work with. And importing things from Excel, Powerpoint, etc. can get hairy. If you are doing small,simple documents you don't notice the issues with Word. But it is far from being a Desktop Publishing system.
  • Bug Triage (Score:5, Funny)

    by Anonymous Coward on Friday August 27, 2004 @01:11PM (#10089804)
    1. Does it affect Clippy? Fix immediately!
    2. Does it affect features? Fix this week.
    3. Does it affect security? Fix when you get around to it.
    • Re:Bug Triage (Score:5, Insightful)

      by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Friday August 27, 2004 @02:14PM (#10090370) Homepage Journal
      This should be marked +1, Insightful. You only think you're being funny. But when a bug affects every one of your installed customers -- such as a security bug or a major feature change -- you had better be damned sure that you fix it completely and that the fix does not break behavior that third parties have come to expect.

      Take this Active X thing. Do you realize how many essential web components, many of them from companies that are now out of business, would stop working if ActiveX were turned off altogether? Many, many websites would stop working, and you can bet the people running them would blame Microsoft. Poor security doesn't cost you anywhere NEAR as much as losing ISVs would. So you spend a lot of time planning, reviewing and executing the patch, and equal time testing it.

      But bugs in trivial features? Shit nobody uses or really cares about? You can fix that really quickly, because if the fix is still broken, it won't make much of a difference. You don't need a tiger team or testers working late hours. You can put a single intern on it and get it "done" in an hour.

      It's a matter of caution, not priority. When the potential fix affects the core of your business, you move slower fixing it. You release work arounds while you're planning and testing. And you slowly roll out the repairs.
      • Re:Bug Triage (Score:5, Interesting)

        by TedCheshireAcad ( 311748 ) <ted@fUMLAUTc.rit.edu minus punct> on Friday August 27, 2004 @02:21PM (#10090445) Homepage
        Do you realize how many essential web components, many of them from companies that are now out of business, would stop working if ActiveX were turned off altogether?

        There is no excuse, ever, for using ActiveX. If your web site depends on or even uses ActiveX, you need to hang yourself from your server rack with a cat5 cable.

        ActiveX is not cross platform, and therefore by no means suitable for web purposes. If you can't accomplish the task with DHTML/JavaScript, then you need to find another way.

        As for the atrocity against humanity that is stateful programs embedded into web sites, if you're going to commit the crime, Java better be your weapon of choice.
        • Re:Bug Triage (Score:5, Insightful)

          by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Friday August 27, 2004 @02:38PM (#10090589) Homepage Journal
          Okay I'll bite. Here's a fantastic excuse for using ActiveX: every one of your customers will be using Windows with Internet Explorer anyway, and you want to quickly develop a program that will permit them to locally control their machine without having to download and install software.

          Java won't cut it (security models vary too greatly). Flash won't cut it (no access to local libraries). Only ActiveX will do. I know entire software suites in the $1000+ range that rely on ActiveX's "security flaws" for proper operation. I would never buy one of these, but I also wouldn't want to be told that software I purchased is no longer usable because of a security patch. I've been told that in the past (an old Bently automotive manual that no longer works due to Java "security enhancements" that make it unable to start) and it sucked. It wasn't my decision to use the technology...I shouldn't be punished because of someone else's technology choice.

          I dont' like Active X. I don't even like this kind of website. But for many developers in the intranet services market, it's a godsend. Rapid development and a trustworthy, no-obtrusive, support free platform. Basically, all the same reasons it's used to spread spyware and viruses.
          • Re:Bug Triage (Score:3, Informative)

            by javaxman ( 705658 )
            one of your customers will be using Windows with Internet Explorer

            Do you know that for a fact, huh? What do you do when my company becomes ( or wants to become ) a customer, and you learn that we all have Macintosh OS X machines on our desktops, and only one or two PCs in the building, which we won't want to use for your website?

            If you think this is some sort of joke, it's not. There is at least one major business service we're dumping this year because their website supports only a specific version of W

        • Re:Bug Triage (Score:3, Insightful)

          by Cereal Box ( 4286 )
          If you can't accomplish the task with DHTML/JavaScript, then you need to find another way.

          And inevitably, some web designer who's even more hardcore than you will say that you should hang yourself with CAT5 cable if your website uses any kind of HTML that Lynx can't render...

          Eventually you will have to draw a line somewhere and realize that there is basically no way to make a modern website/web application that won't exclude some amount of the web browsing world. There's plenty of "standard" features th
          • Re:Bug Triage (Score:3, Insightful)

            by jsebrech ( 525647 )
            And inevitably, some web designer who's even more hardcore than you will say that you should hang yourself with CAT5 cable if your website uses any kind of HTML that Lynx can't render...

            Not lynx, it doesn't do tables, which are quite useful, but I've for a long time been of the opinion that the majority of websites have no excuse if they don't show up in links. Stuff like popup menus, tab navigation and hover effects can be done with CSS in a cross-browser way that degrades gracefully on older/simpler bro
  • by StevenHenderson ( 806391 ) <[stevehenderson] [at] [gmail.com]> on Friday August 27, 2004 @01:12PM (#10089817)
    what it is like to track down and fix a bug

    Track a bug? Sounds like trying to follow a single mosquito in the ranforest. :)
  • The steps (Score:4, Funny)

    by samhart ( 89298 ) on Friday August 27, 2004 @01:13PM (#10089822) Homepage
    Step 1: Deny existence of bug.
    Step 2: Classify bug as feature.
    Step 3: Cave to user demand and try to fix bug.
    Step 4: Introduce new bugs during the fix.
    Step 5: Classify those bugs as features.
    Step 6: Pretend bugs are fixed and continue playing Minesweeper.
  • Debugged humans eh? (Score:5, Interesting)

    by Rosco P. Coltrane ( 209368 ) on Friday August 27, 2004 @01:14PM (#10089837)
    One of my favorite Chris Mason quotes comes from that memo, "Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do."

    Then it would seem humans working at Microsoft are less debugged than everybody else. Because *boy*, at some point Microsoft was a bug factory.

    To their credit though, this is changing fast. Microsoft is a huge company that can turn on a dime, and they've understood that having shite engineers onboard won't do much good to their latest "trustworthy computing" PR stunt. Not to mention, they actually have a nice R&D shop now, not just the pretense of one anymore.
    • by gl4ss ( 559668 ) on Friday August 27, 2004 @01:23PM (#10089928) Homepage Journal
      **To their credit though, this is changing fast. Microsoft is a huge company that can turn on a dime, and they've understood that having shite engineers onboard won't do much good to their latest "trustworthy computing" PR stunt. Not to mention, they actually have a nice R&D shop now, not just the pretense of one anymore.**

      but wasn't quotes like this seen already in '91, then in '95 and then in 2000 already?

      • by khasim ( 1285 ) <brandioch.conner@gmail.com> on Friday August 27, 2004 @01:34PM (#10089996)
        gl4ss is completely correct.

        Win95 was THE MOST ADVANCED OS in the world!

        Win98 fixed all the bugs in Win95.

        Win98SE fixed all the bugs in Win98.

        Windows2000 is crash proof and the Unix killer!

        Windows XP is even more stable than Win2K and will be sure to slay *nix.

        Go digging through the press releases and gushing "journalists" for every single release (except WinME) since (and including) Win95. You'll see the same quotes over and over and over.
        • by lspd ( 566786 ) on Friday August 27, 2004 @02:06PM (#10090286) Journal
          Win95 was THE MOST ADVANCED OS in the world!

          Win98 fixed all the bugs in Win95.

          Win98SE fixed all the bugs in Win98.


          WinME: The bugs strike back.
    • by peragrin ( 659227 ) on Friday August 27, 2004 @01:39PM (#10090034)
      >>Not to mention, they actually have a nice R&D shop now, not just the pretense of one anymore.

      Ah so they finally upgraded the Reverse engineering dept. It's about time.
    • I can't remember the guy's name but I do remember what the head of marketing for one of my past employers once said...


      All software has bugs. If it doesn't have bugs, then it isn't software.
  • by revery ( 456516 ) * <charles@NoSpam.cac2.net> on Friday August 27, 2004 @01:17PM (#10089869) Homepage
    Humans are bugs, err, humans are viruses. Correction: Humans have bugs.

    Programs are like onions. Ogres are like onions. Donkeys like cake.

    Mac Office X is the red-headed step child of Microsoft development efforts

    Microsoft is a lot like the police.

    --

    Was it the sheep climbing onto the altar, or the cattle lowing to be slain,
    or the Son of God hanging dead and bloodied on a cross that told me this was a world condemned, but loved and bought with blood.
  • "feature" filled (Score:4, Insightful)

    by xsupergr0verx ( 758121 ) on Friday August 27, 2004 @01:20PM (#10089891)
    Why don't they fix that awful formatting in MS Word?

    You know, push enter twice and it returns to the default font/size. That really bothers me.
    • If you're seeing this, it's because you're using Word wrong. Office uses a stylesheet based formatting engine, much like the modern world wide web. When you change the font using the FONT field in the taskbar, you're changing the font at the paragraph level. Hitting enter twice starts a new paragraph, which causes word to load up the original paragraph style.

      What you're asking for -- markup based layout -- is how Word Perfect works. There are pluses and minuses to both styles and markup, though styles
  • by newandyh-r ( 724533 ) on Friday August 27, 2004 @01:23PM (#10089920)
    "And, always remember that I can't fix what I can't see. I have to be able to reproduce the problem while being able to run some kind of diagnostic tool. The key to fixing a bug is predictability. Without predictability, I can't fix it, because without predictability I have no way to understand how the complex interactions in modern software cause the specific problem to occur."
    • Which is funny to hear, because (history: I work for IBM on the AIX kernel) I've fixed a lot of bugs I can't see, via code inspection and knowing roughly what was happening when the system crashed.

      I'm sure Word has a milti-million line codebase. But so does AIX. It's split into different components, and there's quite a few bugs where I know roughly which code must have been running. So stare at the code for a few hours envisioning different inputs/control flows, and eventually a case that's not accounted for properly will show itself.

      Bah. Amateurs.

      Cheers, Matt

    • by Tailhook ( 98486 ) on Friday August 27, 2004 @06:11PM (#10092317)
      The key problem is expressed in very few words

      The statement you quote is generically correct. I conclude based on my read of the entry that the developer is "over his head". He, and many like him, have a dependence on elaborate debugging tools and often claim that without these tools they are unable to fix problems. He already has sufficient diagnostic tools available to him and he either doesn't know about them or they've been obscured by bad code.

      By design, Word will open an infinite number of files (this implements so called unlimited undo.) This is crap design. Damn near every OS in existence imposes some limit on open files. Even if there is no "built in" arbitrary limit provided by the OS, RAM will eventually be exhausted just keeping track of open files. Whoever failed to consider this is the origin of the problem; everything that has happened since is his/her fault.

      Now, discovering that there are limits to open files is what the blog entry was about. The first clue eventually appeared only after someone managed to reproduce the problem in a debugger. This took a long time. Also, the altered state of running the app inside the debugger further obfuscated the problem (read the blog entry.) Perhaps it would have taken less time if simpler tools had been used...

      One can easily observe OS resource usage of a running application without elaborate debugging environments. Some OSes make this easier than others. The blog entry author recalls a moment when a discovery was made by someone else using "some tools" in OS-X. He doesn't specify what these tools are. He probably doesn't know (due to abject dependence on his debugger.) In Linux I can observe file handle usage with tools that include ls and cat. In Windows I could use Sysinternals Process Explorer (a non-microsoft tool, btw) to do the same thing.

      Simple observation of open files using non-debugging environment tools might have led someone to ask; "Why is Word attempting to hold <<insert large number>> files open...?"

      Further, the error message displayed by Word; "Disk full." indicates another sad failure. The disk wasn't full at all. It is my guess that Word uses some generic catch-all whenever a file system operation fails. Can't write to a file? Disk Full. Can't open a file? Disk Full. etc, etc. The catch-all manages to isolate a subset of possible causes and dumps the rest into "Disk full".

      Type "man open" into the shell of any POSIX like system that provides manual pages. Look for ENFILE. This is the error code you will see if you write a program, like Word, that opens too many files. If you then have your program display an accurate error message, whoever ends up maintaining your little miracle will spend fewer months fixing it. I've no doubt Windows API provides similar.

      Bad design, bad coding and low-skill maintainers. Thus mickysoft.
  • Loved it... (Score:5, Funny)

    by PsiPsiStar ( 95676 ) on Friday August 27, 2004 @01:23PM (#10089922)
    I wonder if they'll do another writeup when they fix the next bug.
  • by tao_of_biology ( 666898 ) * <(moc.liamg) (ta) (ygoloib.fo.oat)> on Friday August 27, 2004 @01:23PM (#10089924)
    From the article:
    • More than 850 command functions (e.g. Bold and Italic are the same command function)
    • More than 1600 distinct commands (e.g. Bold and Italic are distinct commands)
    • At any given time roughly 50% of these commands are enabled (conservative estimate)
    • With just 3 steps, the possible combinations of code execution paths exceeds 500 million

    Adding new features and abilities to Word would affect a complex system like this in totally unpredictable ways. And, trying to debug such a complex system seems like an almost impossibly complicated task.

    Now I know sarcastic answers will abound to this, but I wonder how much MS invests in testing such complicated programs? It has to be way, WAY more than they invest in the development of the program.

    Now, I'm no Microsoft fanboy, but I am seriously impressed with Word. It never crashes on me, features always work as expected with other features and the interface does rock. I had no idea how complex the program was, and I am even more awed.

    By the way, if you don't know much about complexity or chaos theory I recommend reading the following books to give you a nice appreciation of complex systems like this: COMPLEXITY [amazon.com] and CHAOS [amazon.com].

    • Now, I'm no Microsoft fanboy, but I am seriously impressed with Word. It never crashes on me, features always work as expected with other features and the interface does rock. I had no idea how complex the program was, and I am even more awed.

      This will be one of the sarcastic answers abounding to your post. I've been using GUI based word processors for around 20 years. I am seriously unimpressed with word. I agree with you that it takes an incredible testing/debugging effort to release such a piece of

    • by fireboy1919 ( 257783 ) <rustypNO@SPAMfreeshell.org> on Friday August 27, 2004 @02:03PM (#10090260) Homepage Journal
      Obviously you've never tried to make big documents with Word.

      Writing a book with pictures in Word is extremely difficult. It randomly moves stuff around, changes fonts, and deletes sections of the code when you exceed somewhere around 2MB file size (or 10 pages...I'm not really sure about the limit).

      The interface isn't the whole problem either. Exporting to rtf format creates files that don't actually meet the rtf specification (which has been defined by Microsoft, by the way), so have errors (even when read by Microsoft's rtf importer), and html output is even worse.

      Latex has more features than Word without any of these problems. Also, given the original "find a bug and win money" challenge, I think I can say it is probably one of the most stable pieces of software on the planet, and it has an extension mechanism built in (Word does too, by the way - several of them).

      There are some things that Microsoft makes that beat the competition, but I don't think that Word is one of them.
    • by jafac ( 1449 ) on Friday August 27, 2004 @02:03PM (#10090270) Homepage
      You can blab and whine all you want about complexity. Then you gotta explain why, since Word 95, there's been an issue with Section Breaks spontaneously changing type, and causing page numbering problems.

      Still exists in Word 2003.

      Countless usenet posts exist describing the anguish of VBA programmers when they encounter this bug, classify the behavior, report it to Microsoft, find out it's been a known issue for over 9 years, with no plan to fix it.

      That's not caused by complexity. That's caused by bad management. Folks with no conscience. No pride in their work.
    • by Theatetus ( 521747 ) on Friday August 27, 2004 @02:17PM (#10090405) Journal
      It never crashes on me, features always work as expected with other features and the interface does rock.

      So, do you never user bullets, alter tables' sizes, change a region's font, change regions to bold/italic/etc, or paste from other applications?

      For me, about 1 time in 20 I use them, the last bullet is in a different style/size than the others, the table suddenly takes up the width of the entire page and even forces the page into landscape, the whole region becomes Times New Roman, the whole region becomes size 2, and the document's margins disappear, respectively (and actually widening a table has caused the document's margins to disappear, also).

      I'm sure OOo has these problems too; I've given up on WYSIWYG document editors entirely and now write my papers in ascii and mark them up in TeX.

  • by Sheetrock ( 152993 ) on Friday August 27, 2004 @01:28PM (#10089954) Homepage Journal
    is less an example of a failed process than it is a testament to the difficulties of debugging feature-rich software on a timetable that meets marketing demands and indeed provides some insight into the mind of the average consumer.

    Do you want it buggy today or robust tomorrow? One need only look at the overclocking community and throngs of beta-testers to work out the answer. History is littered with technically superior failures in the marketplace (Betamax, Divx, BeOS) and the reason is that the consumer is more fickle about price and features than about technical superiority or stability.

    Read any book put out by Microsoft Press and it's plain there are a number of people there that are as or more capable than most open source programmers. But the open source programmer doesn't have to appease any person or schedule other than those he sets himself -- and can therefore program under much better circumstances.

    • ...is less an example of a failed process than it is a testament to the difficulties of debugging feature-rich software on a timetable that meets marketing demands...

      Um, except the part where a developer and a tester go round and round about differences between "debug mode" and "release mode" problems. I mean come on, what kind of amatuer windows developer doesn't recognize the gigantic differences between debug and release mode apps on win32??!! If these guys would just learn to use printf() and/or the
    • by billtom ( 126004 ) on Friday August 27, 2004 @03:58PM (#10091282)
      Read any book put out by Microsoft Press and it's plain there are a number of people there that are as or more capable than most open source programmers.

      It's not all that important, I suppose, but just in case you don't know, Microsoft Press books are not written by Microsoft developers (well, a few are, but not most). Microsoft Press is just a regular publisher and their authors come from the same pool of writers as every other technical publisher. So the quality of books from MS Press says nothing, good or bad, about the company's software products or practices.
  • Nice Serveice: (Score:3, Interesting)

    by zulux ( 112259 ) on Friday August 27, 2004 @01:30PM (#10089970) Homepage Journal
    From on of the comments from the blog:



    By the way I did try to report the bug via our $500,000+/year global support contract with Microsoft, and was told directly by our Microsoft support representative, and I quote, "I wouldn't know how to file a bug report for that." Never was able to get it addressed, even though I had two good sample documents for reproduction of the problem.



    Half a million? No wonder Bill Gates has billions - He's not spending the money on developers.
  • by Herbmaster ( 1486 ) on Friday August 27, 2004 @01:30PM (#10089972)
    1. Get assigned bug to fix; get distracted and read slashdot instead.
    2. ???
    3. Bug is fixed; I profit.

    Hmm....
  • by 4of12 ( 97621 ) on Friday August 27, 2004 @01:30PM (#10089973) Homepage Journal

    From the article
    Now, there's a philosophical issue about the desirability of increasingly complex software, but I'm not going to discuss it here. For all practical purposes, I don't think there's much benefit to getting into a discussion about it.

    But there is a benefit to discussing complexity because it does seem to impact how many bugs arise and the maintainability, upgradeability, and usability of the software.

    It's not merely a philosophical issue, either. This is a real, practical issue that impacts millions of people everyday.

    The complexity of interacting software components is like the dark side of Metcalfe's Law about the usefulness of networks increasing quadratically with the number of participants in the network.

    The maintainability of software decreases as the number of interacting components increase and as the number of ways of interaction increases.

    I've developed code for a long time and seen great ideas turn into great code with creeping useful features gradually added on until a day comes when you wonder how you ended up working on such a monstrosity.

    A good friend once told me years ago

    "Every now and then you need to flush."
  • by Anonymous Coward on Friday August 27, 2004 @01:34PM (#10089998)
    27-08-2004 08:14

    Several bugs have been sighted near the southern perimeter and some of our QA staff have been wounded in a couple of minor skirmishes. Strategic Command said the enemy's main move will not come for weeks and certainly not in this sector, though I am beginning to doubt.

    27-08-2004 08:26

    The skirmishes have intensified and several QA squads are trapped between an unknown number of bugs. We even had a few lightning strikes beyond our perimeter, which took out our BugTraq listening post. I tried to call in for assistence from StratCom, because I suspect the main strike is happening here as we speak. 27-08-2004 08:54

    The minor skirmishes have ceased along all sectors. We are trying to evacuate the wounded and salvage what's left of some of our equipment. 3rd QA batallion took heavy losses, as did 6th QA and 8th Helpdesk. What is this, some cat and mouse game they are playing with us?

    27-08-2004 09:06

    All hell broke loose! While we were trying to evacuate the wounded, we found our sector under attack from multiple vectors, including artillery and naval support. Whatever remained of 3rd and 6th QA that was stationed in the rear has now been wiped out. 8th Helpdesk has been decimated and I had no other option to commit 24th, 12th and 2nd Developer batallion to the battle, at least untill reinforcements arrive. The enemy seems to be using a superior number of SFU-506 "Sasser" class fighters with ActiveX payloads. I nearly begged StratCom to send some "KB900364" SAM batteries.

    27-08-2004 15:56

    We have pulled back and regrouped in Sector 56. 3rd, 4th, 6th QA got decimated. 8th, 12th and 15th Helpdesk have been routed as well. 24th, 12th and 2nd Developer have been utterly destroyed to save the rest from annihilation. The few who remain are now en-route back home. Some are shell-shocked, one fat guy keeps jumping around yelling "Developers!"... Poor sod, this is war at it's worst.

  • by autophile ( 640621 ) on Friday August 27, 2004 @01:36PM (#10090013)
    It's not uncommon for users to make a few edits to a document, save the document, make a few more edits, save the document again, make a few more changes, and continue this process of edit/save for hours on end.

    Gee, I wonder why.

    --Rob

    • by alispguru ( 72689 ) <bob,bane&me,com> on Friday August 27, 2004 @01:58PM (#10090203) Journal
      If you have auto-save turned on (it's on by default in Word for OS X), Word saves at N-minute intervals behind your back, and you get the same buggy behavior as you do when you do it manually. All you have to do is leave a document open for a long time.

      I was asked by my supervisors to try and use MS tools to minimize their grief in reading my output. So, while I was debugging a program on a remote machine (via X11), I left a Word document open for my notes. After a few days, I suddenly couldn't save any more. I gave up and started keeping my notes in an emacs buffer (which has infinite undo, and can stay up for days with no trouble - go figure).

      I remember thinking at the time, "this has got to be a file-handle leak problem". I'm surprised to see I was right!
  • by ribond ( 149811 ) on Friday August 27, 2004 @01:38PM (#10090025) Journal
    I like seeing such a dedicated description of how bugs can remain.. This line:

    "Why did it take so long to figure out what was up with this?" Well, you might as well ask why police departments continue to have a large number of unsolved crimes on the books. The issue is the same: the investigation stalls for the lack of any further leads to follow.

    Describes a huge chunk of my life in Software QA. It's an example of what is great about MS software and what is awful:

    Great: dedicated test resources to chase down corner cases/non-obvious scenarios, accountability for broken scenarios, etc
    Awful: Iterations of releases built on legacy code means no one (or two, or three) people can understand the problem or scope the fix.

    For all the complaints here about MS code I wonder that no one has noticed the Windows weakness that is not getting exploited..? If MS software is really as bad as everyone here makes out then why doesn't someone do it better? Blah blah Linux blah blah... Build software for Windows that people can use without rebuilding their systems. If you do it well enough tell them it's even better on Platform X.
  • by spaceyhackerlady ( 462530 ) on Friday August 27, 2004 @01:39PM (#10090032)
    Rather, we're talking about the shear volume of things the user can do.

    Memo to Microsoft: it may be spelled correctly, but that doesn't guarantee it's the right word.

    ...laura

  • too few eyeballs (Score:3, Insightful)

    by KGBear ( 71109 ) on Friday August 27, 2004 @01:40PM (#10090043) Homepage
    I do understand all the complexities involved in trying to fix a bug the way the article describes. That's exactly why Open Source is superior. Instead of wasting a decade while 3 or 4 guys look at the problem from different angles, we'd have 3 or 4 hundred guys working on it not because it's their job but because they need it fixed. That's why fixes usually take days or hours on Open Source products.
    OTOH, lots of people know enough programming to solve that kind of problem to their satisfaction. We don't have to submit that fix, so we don't have to worry too much about the side effects of the fix. That enables us to keep working with the product until some official (and usually better) solution comes along.
  • by Akiba ( 589290 ) on Friday August 27, 2004 @01:42PM (#10090055)
    Very interesting read. One thing I have to dissagree with is about needing to see/reproduce a problem in order to fix it. It's true that not being able to reproduce makes finding a bug much harder but it's not impossible. As a server programmer I frequently have to debug race condition bugs, corruption bug or other problems that are not reproduceable at will. Sometimes good detective work can lead you to a find and sometime not. Often you end up having to add some diagnostic code that hopes to gather more information on the problem the next time someone encounters it. If it happened just once, often we cant fix it but then it's not that important... If it happens "once in a while" and/or "only in production at a large customer site" then we can usually fix it given enough time to work on it. I actually enjoy these kinds of bugs :-) -Akiba
  • by wfberg ( 24378 ) on Friday August 27, 2004 @01:43PM (#10090067)
    They spent years in the dark that the "disk is full" error was caused by too many open files.
    You'd think that if the disk isn't actually full, you'd look at other places that can generate that error. Even though obviously the error should have been along the lines of "too many open files".

    Note that this underlying problem isn't just a technical one. You get over-general error messages on windows (and with various badly designed software) all the time.

    The least you can do when you pop-up an error is to give some additional information; like where it occurred ("Bad Thing Happened in somefile.c line #456"), so even if, like in this case, you can't reproduce the error in a debugger, you know where the error got kicked into being. Not quite as useful as a full stacktrace like in Java, but pretty usefull.

    Compare this to how (non-Microsoft) geeks write error codes; from man ep;

    ep0: 3c509 in test mode. Erase pencil mark!

    This means that someone has scribbled with pencil in the test area on the card. Erase the pencil mark and reboot. (This is not a joke).


    Even if you don't understand the error code, at least you can google for its pretty unique description "erase pencil mark".
  • just goes to show (Score:3, Insightful)

    by zarniwhoop ( 698439 ) on Friday August 27, 2004 @01:48PM (#10090110)
    what a bunch of morons work at M$.

    Let's see...

    Introduce some gobbledeegook, heath-robinson-esq software design (ala piece-tables) just so the user can copy/paste ever so fast. <quote>For example, if you copy text from one document to another, you don't have to actually copy the text from one file to another--at least not right away</quote>

    yes - therein lies the screw-up!!

    They then live with this dog's breakfast of a code base for upwards of 10 (yes ten!!) years until its time to fix it. And the developers cant even work out which "Open file limit" has been reached. Well not very quickly anyway.

    I have seen so much of this kind of "engineering" it makes me bleed from my ears. What's more, the author of this article portrays the story with so much nobility.

    Things to always bear in mind I find are:

    KISS
    OCCAM's RAZOR
    DONT TRY TO BE TOO SMART

    END_OF_RANT
  • Thanks MBU! (Score:3, Insightful)

    by dourk ( 60585 ) on Friday August 27, 2004 @01:52PM (#10090156) Homepage
    Isn't it great that the Mac unit can show the Windows guys the right way to fix a bug?
  • Comment removed (Score:5, Interesting)

    by account_deleted ( 4530225 ) on Friday August 27, 2004 @01:55PM (#10090177)
    Comment removed based on user account deletion
  • by Bitmanhome ( 254112 ) <[bitman] [at] [pobox.com]> on Friday August 27, 2004 @02:49PM (#10090690)
    To put this into perspective, the person who implemented multiple undo in Word is one of the best developers who has ever worked on Word, and has, since, been recognized as a Microsoft Distinguished Engineer.
    So .. the guy that added multiple undo knowingly created a file handle leak .. and got an award for it? And he's the *best* engineer they got? Yeah, that sounds like Microsoft to me.
  • by gillbates ( 106458 ) on Friday August 27, 2004 @03:22PM (#10091006) Homepage Journal

    "Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do." We work to minimize the bugs in the software we ship, but they'll always be there.[emphasis mine]

    And Microsoft thinks they're ready for the Enterprise Market....

    I did RTFA. I'm trying hard not to flame, but this guy is a downright pathetic programmer. I've fixed more complicated bugs in the last week than this. And his defense - Word is complicated - just doesn't cut it:

    • I work with production systems which have over ten thousand modules, with dozens, if not hundreds of interconnected and interdependent systems. Yet, in spite of this, the average bug fix takes around two weeks.
    • The last time I remember hearing of a data-integrity bug was last year. I can't remember any before that. But, the interesting thing is that it was fixed within a week and the corrupted file was rebuilt from other, known good files. In the end, we lost NO data.
    • We as programmers cannot release a system with any known bugs. If we do, we won't expect to hear, "Well, we haven't fully debugged humans yet," but rather, "If this continues, I'll have to ask you to re-evaluate your employment here..."
    • Our systems are more complicated, yet contain fewer bugs than MS's software.
    • We are given as much time as we need to test. We aren't allowed, nor expected, to release buggy software simply to meet a deadline.
    • We have professional technical architects working for us. Because of the quality of our design, debugging even very large, complex programs is actually manageable. Furthermore, we don't have to do much of it because QA keeps buggy code from getting into production in the first place. The majority of our fixes revolve around ease-of-use and additional functionality issues.
    • We can't just release code "as is" and think about fixing it later. Failure of our systems could cause very serious damage to our clients; perhaps bankrupt some of them. We don't have the liberty to be unprofessional.

    There used to be a time when programmers were more professional.

    • What the amateur coder says: "we can't fix every bug..."
    • What they really mean: "I'm an idiot programmer who can't be bothered to actually employ good design principles, nor debug the code I've written. I, quite frankly, could care less about the idiot end user, 'cause, I like, know computers and I'm smarter than you so just whine about bugs to someone who actually cares. Oh, and what about my stock options?"

    Quite frankly, I hate to see this attitude in programmers. If you are charging for the code you write, you should at least have the professionalism to fully debug it before release. Your customers deserve better than to have your software ruin their business.

  • by aardwolf204 ( 630780 ) on Friday August 27, 2004 @03:31PM (#10091070)
    From the MSDN Blog [msdn.com]:

    Well, not directly, but they sure took the wind out of my sails with their new Picasa Photo Organizer and corresponding photo publisher Hello. I've been working on a photo editor/publisher application for personal use off and on for around 2 years. Lately, I've been think about how a lite weight, easy to use solution would be a big hit among new parents/grandparents like myself. Here they go giving it away for free. Who could do such a thing?

    You know what? I will not be daunted. I will rise up from my defeat and create a better application. That'll show 'em. One that publishes your photos to your blog, other users of your application, or via email. Wait, Hello already does that? How about cropping and reformatting your photos and organizing them into an album. What, Picasa has that covered?

    But, aha! I'll bet their solution doesn't use the power of Visual Basic.Net and the .Net Framework. With .Net behind me, nothing can stop me! And, maybe I'll publish my source. More on this later...

    Emphasis mine. having never read the MSDN blog before and seeing this now, all I can say is "OMFG"...
  • Boo Hoo (Score:3, Interesting)

    by andy_geek ( 522404 ) on Friday August 27, 2004 @03:51PM (#10091234) Homepage
    I see this as a pity play by M$, wanting users to just chill about bugs because they're so damned hard to fix. Well, excuse me, but last time I checked Microsoft wasn't giving Office software away for free, and if someone is going to shell out beaucoup bucks for something they have a right to demand it works as advertised.

    Cry me a river, Microsoft. I'll save my pity and empathy for people who do community or open source development.

  • printf (Score:3, Insightful)

    by Coward Anonymous ( 110649 ) on Friday August 27, 2004 @05:12PM (#10091864)
    The author seems to be really attached to his debugger. He should learn to use the printf() the most powerful debugging tool ever devised.

"If it ain't broke, don't fix it." - Bert Lantz

Working...