Exterminate Those Bugs!


When I close my email program if often doesn’t really close. The UI disappears, but Task Manager shows the process to still be present. It’s either doing some very extensive processing or stuck in an endless loop; I let it run for multiple hours once to no avail. The only visible sign it hasn’t crashed is its constantly increasing usage of memory.

The manufacturer of my Tablet PC decided to provide its own power management utility rather than use the one that’s built into Windows. That would be fine except that it crashes every time I close it. It takes the custom power manager with it, which means no more auto-changing power profiles when I dock or undock my Tablet until I log out of and back into Windows.

My dad purchased a different brand of Tablet PC. He used it for a couple weeks before installing Service Pack 2 for Windows, which slowed things down to a crawl. Simply updating drivers probably would have solved this, but the company told him SP2 doesn’t work with their Tablet and so to uninstall it.

My video driver crashes when I scroll a certain list box in my application line by line. This happens for everyone on my team who has the same video card as I do.

I write these blog entries in Notepad. On some machines, when I save the document (via both File|Save and Ctrl+S) the caret moves back some number of characters.

Each of these is a sign of insufficient testing. Which is not to say that the respective teams haven’t made an effort to thoroughly test their product, just that they’ve missed at least one test case.

Applications are so complex these days that it is more-or-less impossible to write bug-free software. Techniques such as pair programming and code inspections can help you approach this goal, but the effort required to actually reach it is so immense that in most cases (excepting such things as life-critical software) the costs are judged to outweigh the benefits.

This state of affairs is of course deplorable, and lots of smart people are working to correct it. It may not actually matter though.

Is a bug a bug if no one ever sees it? If your printing subsystem is riddled with bugs that your users never print, do you care?

(Yes, yes, yes; if your users aren’t going to print you shouldn’t have spent time building that functionality. I agree. But if they swear up and down that they need it and are willing to pay for it and won’t be dissuaded, it can be best to just build it.)

The idealist in me says that of course you should care. That you should do everything you can to prevent bugs from occurring. That buggy code is messy code. That well-designed and -built code is by nature less buggy.

The pragmatist in me doesn’t disagree but realizes that until it is possible to write bug-free code without undue effort (read “at a cost that management sees as acceptable for the business”) bugs will happen.

Given that state of affairs, it is of utmost importance to fix every bug you or your customer finds. The business types tend to poke their head in here and demand justification for the costs of doing this. I believe that justification is self-evident: a customer is going to run into the bug.  (Has already, if it came from a customer.) Fixing every bug is worth the effort. Yes that may mean you won’t have time to build as much new functionality. Getting rid of those bugs, though, not only gives your customers a better experience but also gives you a more stable base on which to build the next release, which can only make building it easier.

Less bugs. Stabler products. Happier customers. More productive product teams. It’s your classic win-win-win situation!

*** Comments, questions, feedback? Want a fun job on a great team? Send two coding samples and an explanation of why you chose them, and of course your resume, to me at michhu at microsoft dot com. I need a tester and my team needs program managers. Great coding skills required for all positions.

Comments (5)

  1. Jerry Pisk says:

    I would suggest Raymond Chen’s blog (http://weblogs.asp.net/oldnewthing). Take a look at his arguments why Microsoft will not require developers to write bug free code. If you want a culture that forces developers to write better code you need to stop using Microsoft’s products.

  2. typhoon says:

    Agreed. It is very frustrating to see these little bugs espically memory bugs because other programs could use that memory. I think that Windows Error Reporting is and the OCA are great. But what Idont like is the fact that some MS products like Media Player, Windows Movie Maker dont get updated as often as they sould. (Media Player 9 was not updated other than security untill came out Seems like evyone from the smallest to the largest companies have issues. DDrivers are the worst. So many drivers are buggy and slow and not updated often.

  3. SpiderMan says:

    I have the same Outlook issue after I move to Office 2003. Too bad! :-(

  4. >Each of these is a sign of insufficient testing. Which is not to say that the respective teams haven’t made an effort to thoroughly test their product, just that they’ve missed at least one test case.

    I’m not sure that’s so. It’s common for development teams to find the bug and decide, consciously, to ignore it. That’s not a happy thing for us users, to be sure; it’s merely reality.

    >I believe that justification is self-evident: a customer is going to run into the bug. (Has already, if it came from a customer.) Fixing every bug is worth the effort.

    I would have to disagree there. I would agree if you said that /understanding/ every bug is worth the effort. That’s because, as Richard Feynman said of the Challenger disaster, "when the system is in an unpredicted state, it’s in an unpredictable state".

    If the Notepad development team knows that the caret moves back exactly two spaces on saving a document (some function counting the final CRLF, and some other function counting it again, perhaps?), and they know why it happens, and they decide that it would be a bigger pain to fix than to ship, that could be a reasonable decision. If, on the other hand, they failed to figure out why the problem was happening and simply said, "two characters–big deal", then they’re taking on a risk without information, which would be a bad idea.

    I used to agree with you. Interestingly, I believed that one should fix every bug when I was a tester for a commercial software company. Then I became a program manager, and I began to believe it less. Then I became a much better tester, and recognized that it’s not up to us to make those decisions; only to provide information to management so that it can make informed choices. Your well-taken point about costs that are acceptable to the business drives those choices.

    As users, we could get a more perfect Notepad. Would we be willing to pay for it? The answer is Yes, for some of us; I purchased TextPad. But lots of Windows users will be happy with the Notepad they’ve got–so they get what they pay for.

    You would probably enjoy reading Jerry Weinberg’s work, especially "Quality Software Management, Vol. 1: Systems Thinking". For my part, I’ve enjoyed reading what I’ve seen of your blog so far.

    Cordially,

    —Michael Bolton

    DevelopSense: Software Testing in Plain English

    http://www.developense.com