Saying “goodbye to our intern” leads to a reason why a bug did not get fixed in Office 97

    Anirudh Saraf is winding up his internship this week. He's been pretty busy while here - diving into the subtleties of Hyper-V, learning how to get machines working on our network domain, moving into Windows Server 2008, learning our automation system and some of the tools we have, getting some of our automation running in those virtual images he learned about with Hyper-V and working on new features for OneNote! Whew - that's a lot of work for ten weeks. I expect now that he will get back to his blog he'll let us all know what he really thinks… 🙂

    He and I met yesterday and he had some paperwork which I also needed but had not had time to print. As we went to the photocopier to make me a copy, for no particular reason I was reminded about a bug I found in an addin for Excel way back in Office 97.


    I had only been here a few weeks at the time, and Office 97 was in the final stages of shipping. We were looking for the core "ship stopping" bugs and staying focused only on the most severe problems. I was working with the Solver addin for Excel and wanted to print the sample (solvsamp.xls) which came with it. I printed the sample and went to the printer to pick up my copy. The printer was busy printing my copy, then another, and another, and another and so on… I didn't think I had selected multiple copies but went back to my computer to make sure. In the print dialog, the default number of copies which I had assumed was 1 was actually 12334. Yikes! I tried cancelling the print job, but that failed. I went running back to the printer and powered it down simply to save paper, called our helpdesk to let them know why the printer was off and went back to my office to file a bug. I was pretty nervous since I had only been here a few weeks and was wasting paper and unplugging printers. I had no idea what the policies were so I made sure I entered the bug ASAP.

    Here's what the print dialog I had blindly clicked OK on looked like:


    The bug came back to me resolved as Postponed. To Office, that means the bug is important and we will fix it, but won't be fixed for the release. In this case, it meant Office 97 would ship with this bug and we would fix it in a future release. Considering the panic I had just been through, I disagreed at first. I fought a little to get the bug fixed (after all, it's only changing a single value in the code). I lost my fight, and here's why:

    • First, further testing showed it was only the second sheet of the sample workbook which had this error. There were seven sheets total (although one of the other sheets had -1 as the number of copied to print). If you tried to print it, Clippy would make you choose a valid number.

    • The Solver addin was an optional component and did not install by default. This means the likelihood of a large number of users hitting this is small.

    • Solver is a technically deep addin, and those users who do install it typically know something about linear optimization to begin with. Again, the number of people noticing the sample spreadsheet number of copies is bogus is small.

    • It had been in the product for the entire development cycle and no one had noticed, found or complained about it. Again, the number of users hitting this will be small, and is getting smaller the more I thought about this.

    • There is no data loss. This is limited to printing that one sample spreadsheet, so no one will lose any work.

    • There is no crash in Excel. Since we were in ship stopper mode, crashes and data loss were the most serious bugs.

    • A simple workaround is to type "1" in the number of copies field of the form. The number of copied was already highlighted. If I had been paying attention, I might have noticed it before I printed.

    For all of these reasons, we decided not to attempt a fix before releasing Office 97. It was just too late to try something as risky as "just one number being changed. What could go wrong?" We shipped and as far as I could tell, no one ever called PSS to report this. We eventually did fix the problem, though, so the bug is no longer there.


    Kind of a long winded story about a bug, but it serves as an example of a minor bug that we don't want to fix since it puts the entire product at risk. Fixing any bug is a balancing act, and in this case, I think we made the right decision.

    Good luck to Ani as he heads back to school. Keep an eye on his blog for more addins for OneNote and his point of view for how the summer went.

    Questions, comments, concerns and criticisms always welcome,


Comments (9)

  1. Thanks John. It was great working with everyone this summer and definitely keep an eye out on my blog as I get back and try to be at least semi regular with it 🙂 lots of stories and news to share … Thanks for the excitement filled summer.

  2. John says:

    I don’t understand.  All of the reasons you listed only reinforce the idea that the bug is minor; why would fixing it put the entire product at risk?

  3. Mark says:

    John: the analysis shows potential benefit is minor.  In contrast, there’s a base level of risk for any bug, due to human error, and effort due to process.

  4. Athan says:

    Sorry but the listed reasons are lame excuses.

    You could fix this minor issue faster than analyzing potential benefits.

  5. From elsewhere in the collective.

  6. Ian Johns says:

    "You could fix this minor issue faster than analyzing potential benefits."

    … sayeth the build-breaker on ship day.

  7. RobM says:

    *You could fix this minor issue faster than analyzing potential benefits.*

    I used to think that way too before I broke a project the day before it was due to launch. All I did was fix a tiny little bug… shame the perfectly valid fix caused ripples that broke other more major stuff.

  8. John says:

    Yep, done that too.  I broke a build of Exchange Server once by changing a < to <= .  Sigh.

Skip to main content