In defense of Microsoft’s 63,000 bugs

This iBrotha article was originally published at MacAddict.com by Rodney O. Lain. In honor of Rodney’s death, a good friend and contributor, we are reposting here with the permission of MacAddict. We would like to thank them for their generosity in allowing us to remember Rodney by keeping this archive of his work.

 

In defense of Microsoft’s 63,000 bugs

fri apr.14.2000

Each time you edit your own writings, you increase the chance that you will introduce more typos or grammatical gaffes.

Not too long ago, I worked briefly as a software developer. The good part of that experience is that I learned first hand how the software-development process works. The downside is that my lessons were learned within an all-PC environment. 

In light of the various opinions, analyes and other forms of intellectual masturbation about Judge Thomas Penfield Jackson’s “duh” ruling on Micro$oft, I thought it a good time to talk about some of those lessons I’ve learned, as a prelude to discussing an often-overlooked aspect of the software giant’s modus operandi. This is possibly a common practice for other companies, too.

Let’s look at the process of developing software from the perspective of the software developing company — using Microsoft as a microcosm. Looking at it from this perspective may explain why Microsoft’s products are as bug-ridden at they are claimed to be. I hasten to add that this isn’t an excuse for buggy software, since I am by no means a Micro$oft apologist. Rather, it is an attempt to shed light and understanding on the pressures and constraints under which computer applications are created and sold.

Three things you should never watch being made: sausage, legislation…and computer software

I say this in jest.

Actually, watching the creation of your favorite software title can actually make you appreciate it more. You’ll understand why it doesn’t contain the feature(s) that you wish it did. You find out the amount of programming code that must be written or rewritten to give you your favorite wishlist bell-and-whistle. It could also increase your respect for and appreciation of the people who write such programs for a living.

Microsoft Windows is purported to comprise millions upon millions of lines of programming code. Imagining such a number of computer instructions — the DNA of computer software — makes me marvel that Windows and other applications work at all, much less productively.

The longest work I have written was a 126-page book, and I must admit that there were times (especially in the initial stages of writing) that I had to go back and read my own writing in order to understand what I was doing. Computer programming is much more complex, and requires far more self-awareness throughout the process. In addition to bug fixes, there are checklists of features that must be implemented in order for the product to remain competitive.

Where do the bugs come from?

Imagine that your small, relatively new company is creating an updated version of your best-selling software title. You have created the software to run on Windows. You develop the program on a Windows NT machine. One of your co-programmers alpha tests the software. She finds that major bugs are found when running the app on her computer, which runs an older version of Windows. Aghast, the other programmers slap themselves on the forehead: they never thought to test the software on older versions of Windows.

After all, you are new to these things.

So you initiate stringent quality assurance testing and find out that major rewriting must be done. Your programmers consider the cost of the effort and conclude that it’s worth the extra time. While they’re at it, they decide that they want to write a Mac version. Ditto for the Linux version.

After producing these non-Windows versions, testing reveals that certain native office applications have conflicts with the software. More code rewriting results. One of the beta testers happens to have his favorite shareware program running. It crashes. Diagnostic software reveals that your product is the culprit.

It’s only shareware, you argue, and say there is no need to add the revision for an insignificant issue. Your beta tester refutes that argument by showing articles praising this shareware for being one of the best-selling software applications of the year.

Point taken. Back to the drawing board.

More quality assurance takes place. The product is tested for compatibility with competing products, with complementary products, with the latest and older versions of most-used software. Regularly, a major conflict is found with a product. Rewriting the software sets the release date back at least month. The Marketing Department is upset because their adds that tout the new product have been saturating the media for weeks now. A ship date has been committed. Twice. The date has come and gone.

More testing resumes, until finally, the product is ready for prime time.

As the product is in its final stages of completion, one more software conflict is discovered. Argument over the seriousness of this flaw are bandied about. In the midst of the discussion, it is discovered that your competitor has announced that they will ship an upgraded product in three weeks.

A decision is made: start working immediately on a bug fix — but it will only be available as a patch for users after the fact…

Here’s my the point

This all may not be too far from the truth with many companies. One of the most time-consuming parts of the software-development process could very well be exemplified by the above situation. True, we complain when an application doesn’t work. Even with the above scenario explained, it’s hard to accept the truth about computer software. In terms of stability, you may be dealing in odds comparable to a crap shoot.

Let’s be honest: should we reasonably expect that a product be compatible with every software title under the sun? No, but we should expect that it be compatible with a good portion of what the average customer uses. My experience has been as anger-filled as the next guy’s, but for some reason, I’m becoming more tolerant of software behaving and misbehavin’. This is why I’m developing a wait-and-see approach concerning the reports that Windows 2000/ME will have some 63,000 reported bugs.

Coupled with the fact that Apple has developed a penchant for needed bug fixes for its venerable OS, I’m less inclined to call anyone else’ kettle black.

But my tolerance has its limits. Customers demand bug-free software, but reality imposes less harsh demands. Just give us a product that ships with the unwritten promise that bug-fixes are forthcoming — and free — on a regular basis, and nearly anything can be forgiven.

While you laugh at Microsoft (along with me; you think I won’t?) keep in mind that Microsoft’s “issues” with Windows 2000 may very well be legion, but they aren’t isolated. If you think that OS 8.1, 8.5.1, 9.0.2 and 9.0.4 were merely cosmetic fixes, dream on. They, too, served the same purpose that upcoming upgrades to Windows 2000 will serve when and if the Operating Systems suffers from the alleged 63,000 bugs.

Or maybe this whole explanation is a roundabout way to justify what we’ve said all along: Windows sucks.