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
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.
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
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
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
that it overwhelms the software.
No one will ever notice.
This is a good one to use when you
want to cut corners.
we seldom know which features will be
important to the users.
One more Go To won't hurt much.
Good programmers use
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?
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
That would mean changing all the programs
A good system design uses
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
as is the earlier paper
"Improving Software Quality"
and the latest update:
"Building Better Software".