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.