9-15-85

The following advice is borrowed from Communications of the ACM,
September 1985, Programming Pearls, page 896-899. Individual credits
are omitted in the interests of brevity, and can be found in the source.

Coding

When in doubt, use brute force.

Avoid arc-sine and arc-cosine functions -- you can usually do better by
applying a trig identity or computing a vector dot-product.

Allocate four digits for the year part of a date: a new millennium is
coming.

Avoid asymmetry.

The sooner you start to code, the longer the program will take.

If you can't write it down in English, you can't code it.

Details count.

If the code and the comments disagree, then both are probably wrong.

A procedure should fit on a page.

If you have too many special cases, you are doing it wrong.

Get your data structures correct first, and the rest of the program will
write itself.

User Interfaces

[The Principle of Least Astonishment] Make a user interface as
consistent and as predictable as possible.

A program designed for inputs from people is usually stressed beyond the
breaking point by computer-generated inputs.

Twenty percent of all input forms filled out by people contain bad data.

Eighty percent of all input forms ask questions they have no business
asking.

Don't make the user provide information that the system already knows.

For 80 percent of all data sets, 95 percent of the information can be
seen in a good graph.

Debugging

Of all my programming errors, 80 percent are syntax errors. Of the
remaining 20 percent, 80 percent are trivial logical errors. Of the
remaining 4 percent, 80 percent are pointer errors. And the remaining
0.8 percent are hard.

It takes three times the effort to find and fix bugs in system test than
when done by the developer. It takes ten times the effort to find and
fix bugs in the field than when done in system test. Therefore, insist
on unit tests by the developer.

Don't debug standing up. It cuts your patience in half, and you need
all you can muster.

Don't get suckered in by the comments -- they can be terribly
misleading. Debug only code.

Testing can show the presence of bugs, but not their absence.

Each new user of a new system uncovers a new class of bugs.

If it ain't broke, don't fix it.

If we can't fix it, it ain't broke.

The first step in fixing a broken program is getting it to fail
repeatedly.

Performance

[The First Rule of Program Optimization] Don't do it.

[The Second Rule of Program Optimization--For experts only] Don't do it
yet.

The fastest algorithm can frequently be replaced by one that is almost
as fast and much easier to understand.

On some machines indirection is slower with displacement, so the most-
used member of a structure or a record should be the first.

In non-I/O-bound programs, a few percent of the source code typically
accounts for over half the run time.

Before optimizing, use a profiler to locate the "hot spots" of the
program.

[Conservation of Code Size] When you turn an ordinary page of code into
just a handful of instructions for speed, expand the comments to keep
the number of source lines constant.

If the programmer can simulate a construct faster than the compiler can
implement the construct itself, then the compiler writer has blown it
badly.

To speed up an I/O-bound program, begin by accounting for all I/O.
Eliminate that which is unnecessary or redundant, and make the remaining
as fast as possible.

The fastest I/O is no I/O.

The cheapest, fastest, and most reliable components of a computer system
are those that aren't there.

[Compiler Writer's Motto--Optimization Pass Making a wrong program worse
is no sin.

Electricity travels a foot in a nanosecond.

LISP programmers know the value of everything but the cost of nothing.

[Little's Formula] The average number of objects in a queue is the
product of the entry rate and the average holding time.

Documentation

[The Test of Negation] Don't include a sentence in documentation if its
negation is obviously false.

When explaining a command, or language feature, or hardware widget,
first describe the problem it is designed to solve.

[One Page Principle] A (specification, design, procedure, test plan)
that will not fit on one page of 8.5-by-11 inch paper cannot be
understood.

The job's not over until the paperwork's done.

Managing Software

The structure of a system reflects the structure of the organization
that built it.

Don't keep doing what doesn't work.

[Rule of Credibility] The first 90 percent of the code accounts for the
first 90 percent of the development time. The remaining 10 percent of
the code accounts for the other 90 percent of the development time.

Less than 10 percent of the code has to do with the ostensible purpose
of the system; the rest deals with input-output, data validation, data
structure maintenance, and other housekeeping.

Good judgement comes from experience, and experience comes from bad
judgement.

Don't write a new program if one already does more or less what you
want. And if you must write a program, use existing code to do as much
of the work as possible.

Whenever possible, steal code.

Good customer relations double productivity.

Translating a working program to a new language or system takes 10
percent of the original development time or manpower or cost.

Don't use the computer to do things that can be done efficiently by
hand.

Don't use hands to do things that can be done efficiently by the
computer.

I'd rather write programs to write programs than write programs.

[Brooks' Law of Prototypes] Plan to throw away, you will anyhow.

If you plan to throw one away, you will throw away two.

Prototypes cuts the work to produce a system by 40 percent.

[Thompson's Rule for first-time telescope makers] It is faster to make a
four-inch mirror then a six-inch mirror than to make a six-inch mirror.

Furious activity is no substitute for understanding.

Always do the hard part first. If the hard part is impossible, why
waste time on the easy part? Once the hard part is done, you're home
free.

Always do the easy part first. What you think at first is the easy part
often turns out to be the hard part. Once the easy part is done, you
can concentrate all your efforts on the hard part.

Miscellaneous Rules

If you lie to the computer, it will get you.

If a system doesn't have to be reliable, it can do anything else.

One person's constant is another person's variable.

One person's data is another person's program.

One ostrich egg will serve 24 people for brunch.

A submarine will move through the water most efficiently if it is 10 to
13 times as long as it is wide.

Omit needless words.

Keep it simple to make it faster.

Do not take shortcuts at the cost of clarity.

[Brook's Law] Adding manpower to a late software project makes it later.

Principles

If you made it this far, you'll certainly appreciate this excellent
advice.