section 0

The Software Skeptic's User Guide

Introduction

The bewildering variety of software available can be baffling to beginning PC user and professional alike. Worse than that, product reliability is all over the board. This article is written by Summitlake.com for:

• users who typically have a heavy investment in software and depend on it frequently
• users who want better ways to evaluate shopping criteria and purchasing decisions
• users who ask, "don't manufacturers ever use or test this stuff themselves?"
• readers who want an inside look at software quality control.
• both software professionals and beginning users

You'll notice, in this article, that we'll often discuss software in the same breath as other industries, such as automotive and retail. Software is no longer new. We'll show that making quality software is in fact a complex challenge. We'll also argue that consumers and analysts need to learn to evaluate software in the much broader context of "all goods and services". The mysterious era of smoke and mirrors is over.

Much of this article is written as the lay person's guide to software quality control, at a very high level that skips whole layers of detail about software quality assurance. You would be surprised at the number and severity of software bugs that ultimately get released to the consumer, despite the best efforts of somebody's software QA department to prevent this.

You'll also see something of the corporate "technical difficulties" that often prevent the original software concept from getting out the door.

The word "compromise" is not used again in this article. It is a political and marketing term which does little to explain slipshod products. Yet, to some, it lends an aura of putting a more positive spin on an epidemic of unacceptability.

This article will give you a better basis for judging an acceptable level of software bugs, and a better understanding of software engineering, and how bugs get into the product in the first place.

Software "quality" has at least two aspects: the feature set's effectiveness and utility, and how well the featured components actually work compared to published specs. We'll spend almost all our time on the second aspect, software defects and quality control.

For example, Windows 2000 doesn't support, and XP Home Edition will not support, multiple monitors. This feature was standard, and worked wonderfully, in Windows 98. Windows 2000 has support for dual processors, but this feature will be yanked out of XP Home Edition.

Although regrettable, these are marketing and product positioning strategies, not quality control issues. We wish we could look at feature sets, but we'll have to save that for another time.

While neither highly technical, nor above most people's heads, this article relies on a good deal of detail and simple examples. Software development is nothing, if not about managing complexity.

"Almost Pretty Good" is organized, tabbed and indexed to make it easy for you to browse and skip around in any order that you see fit.

Finally, we offer tips and considerations, many of which you may not have thought of, that may help you sleep better at night.