Pop Quiz on Quality

A Pop Quiz on Quality

How can you tell if a software group has gone off the track? Listen for tell-tale phrases that warn of trouble, remarks such as "that's not my job" and "it's against our policy." How many of the excuses below have your heard?

That's a feature, not a bug.

If the user points out the spot in the documentation showing that she's right, there is still the second tell-tale excuse:

That's an error in the manual.

With those two replies, a programmer can deflect any conceivable bug report.

Why would you want to do that?

The sign of a truly great program is that even when used in unanticipated ways, it still works.

If there are no questions, everyone must be happy.

Wrong! If people don't ask questions, it just means they've given up expecting answers. Users who like software constantly ask for more features. If you deliver new software and no one complains, then no one has tried it.

We've lost the source code.

Remember, programs are valuable assets; programs depend on an infrastructure for their preservation.

We're too busy to document that.

No wonder you're busy if you don't even document your software. Make sure you create reusable software. Then if a programmer suffers to solve a problem, other programmers who work with that program won't have to suffer as well.

It must be a hardware problem.

This is a sure fire excuse when you can't find the reason for a particularly bizarre and puzzling bug. The ugly truth is that hardware is amazingly reliable, while software is not.

It would cost too much to update the paperwork.

Sometimes in our attempt to avoid error we surround software development with so much paperwork that it overwhelms the software.

No one will ever notice.

This is a good one to use when you want to cut corners. Unfortunately, we seldom know which features will be important to the users.

One more Go To won't hurt much.

Good programmers use structured programming as easily as they breathe.

We'll just reuse this data item.

A program is written once, but read many times, so make it easy to read by following the Laws of Naming.

That could never fail -- don't bother testing for it.

Everything can fail under some condition! Accept the fact that your programs will include many more lines of code to handle failure than to handle success.

Fascinating project -- too bad it failed.

Grandiose schemes usually lead to white elephants with pretentious objectives, high costs, fantastic claims, neglect of other projects, fanatical denial of failure, and a sudden, total write-off. This is the normal method of developing systems!

We tested it once by hand, isn't that enough?

You can't test for the complete absence of bugs, but you can test the typical cases and the boundary cases: minimum value, maximum value, and no value. Is that too much work? Automated testing is the answer.

It's fixed, but is waiting for the next release cycle.

To quicken the cycle, automate every step in sight. At Robelle our nightly jobs even copy the new product manual from MPE to a Windows/NT server and use the WinHelp compiler to convert it into a Windows Help file.

It can't be changed, too much code references it.

Global variables are the worst enemy of good software. The weapon for winning this battle is "Encapsulation."

That would mean changing all the programs

A good system design uses modular programming to hide details. If we had a module which handled all date functions, we wouldn't have to worry about the year 2000.

We gave the users what they asked for.

The firmer the specs, the more likely to be wrong. Users can't tell us what they need, but they certainly recognize what they don't like when they see it. One solution is to use iterative development known as the Step by Step Method.

How many of my tell-tale signs were you guilty of? The full text of this "pop quiz" is available on Robelle's Web server, as is the earlier paper "Improving Software Quality" and the latest update: "Building Better Software".

Bob Green