Excerpts from Programming Pearls and More Programming Pearls

Work on the right problem.
Explore the design space of solutions.
Look at the data.
Use the back of the envelope.
Design with components.
Build prototypes.
Make tradeoffs when you have to.
Keep it simple.

COLUMN 6: BUMPER-STICKER COMPUTER SCIENCE

Every now and then, programmers have to convert units of time.If a program processes 100 records per second, for instance, howlong will it take to process one million records? Dividing showsthat the task takes 10,000 seconds, and there are 3600 secondsper hour, so the answer is about three hours.

But how many seconds are there in a year? If I tell you thereare 3.155 x 10⁷, you'll probably forget it. On theother hand, it is easy to remember that, to within half apercent,

π seconds is a nanocentury.

Tom Duff

Bell Labs

So if your program takes 10⁷ seconds, be preparedto wait four months.

The February 1985 column in Communications of the ACM solicitedfrom readers bumper-sticker sized advice on computing. Some ofthe contributions aren't debatable: Duff's rule is a memorablestatement of a handy constant. This rule about a program testingmethod (regression tests save old inputs and outputs to make surethe new outputs are the same) contains a number that isn't asironclad.

Regression testing cuts test intervals in half.

Larry Bernstein

Bell Communications Research

Bernstein's point remains whether the constant is 30% or 70%:these tests save development time.

There's a problem with advice that is even less quantitative.Everyone agrees that

Absence makes the heart grow fonder.

Anon

and

Out of sight, out of mind.

Anon

Everyone, that is, except the sayings themselves. There aresimilar contradictions in the slogans in this column. Althoughthere is some truth in each, all should be taken with a grain ofsalt.

A word about credit. The name associated with a rule isusually the person who sent me the rule, even if they in factattributed it to their cousin Ralph (sorry, Ralph). In a fewcases I have listed an earlier reference, together with theauthor's affiliation (as of September 1985, when this columnfirst appeared). I'm sure that I have slighted many people bydenying them proper attribution, and to them I offer thecondolence that

Plagiarism is the sincerest form of flattery.

Anon

Without further ado, here's the advice, grouped into a fewmajor categories.

6.1 Coding

When in doubt, use brute force.

Ken Thompson

Bell Labs

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

Jim Conyngham

Arvin/Caispan Advanced Technology Center

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

David Martin

Norristown, Pennsylvania

Avoid asymmetry.

Andy Huber

Data General Corporation

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

Roy Carlson

University of Wisconsin

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

Peter Halpern

Brooklyn, New York

Details count.

Peter Weinberger

Bell Labs

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

Norm Schryer

Bell Labs

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

Craig Zerouni

Computer FX Ltd.

London, England

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

David Jones

Assen, The Netherlands

6.2 User Interfaces

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

Contributed by several readers

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

Dennis Ritchie

Bell Labs

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

Vic Vyssotsky

Bell Labs

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

Mike Garey

Bell Labs

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

Rick Lemons

Cardinal Data Systems

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

William S. Cleveland

Bell Labs

6.3 Debugging

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

Marc Donner

IBM Watson Research Center

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.

Larry Bernstein

Bell Communications Research

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

Dave Storer

Cedar Rapids,Iowa

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

Dave Storer

Cedar Rapids, Iowa

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

Edsger W. Dijkstra

University of Texas

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

Brian Kernighan

Bell Labs

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

Ronald Reagan

Santa Barbara, California

[The Maintainer's Motto] If we can't fix it, it ain't broke.

Lieutenant Colonel Walt Weir

United States Army

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

Tom Duff

Bell Labs

6.4 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.

Michael Jackson

Michael Jackson Systems Ltd.

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

Douglas W Jones

University of Iowa

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

Mike Morton

Boston, Massachusetts

In non-I/O-bound programs, less than four per cent of a program generally accounts for more than half of its running time.

Don Knuth

Stanford University

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

Mike Morton

Boston, Massachusetts

[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.

Mike Morton

Boston, Massachusetts

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

Guy L. Steele, Jr.

Tartan Laboratories

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.

David Martin

Norristown, Pennsylvania

The fastest I/O is no I/O.

Nils-Peter Nelson

Bell Labs

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

Gordon Bell

Encore Computer Corporation

Most assembly languages have a loop operation that does a compare and branch in a single machine instruction; although it was intended for loops, it can sometimes be used to do a general comparison very efficiently.

Guy L. Steele, Jr.

Tartan Laboratories

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

Bill McKeeman

Wang Institute

Electricity travels a foot in a nanosecond.

Commodore Grace Murray Hopper

United States Navy

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

Alan Perlis

Yale University

6.5 Documentation

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

Bob Martin

AT&T Technologies

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

David Martin

Norristown, Pennsylvania

[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.

Mark Ardis

Wang Institute

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

Anon

6.6 Managing Software

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

Richard E. Fairley

Wang Institute

Don't keep doing what doesn't work.

Anon

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

Tom Cargill

Bell Labs

Less than 10% 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.

Mary Shaw

Carnegie-MellonUniversity

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

Fred Brooks

University of North Carolina

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.

Richard Hill

Hewlett-Packard S.A.

Geneva, Switzerland

Whenever possible, steal code.

Tom Duff

Bell Labs

Good customer relations double productivity.

Larry Bernstein

Bell Communications Research

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

Douglas W Jones

University of Iowa

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

Richard Hill

Hewlett-Packard S.A.

Geneva, Switzerland

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

Tom Duff

Bell Labs

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

Dick Sites

Digital Equipment Corporation

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

Fred Brooks

University of North Carolina

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

Craig Zerouni

Computer FX Ltd.

London, England

Prototyping cuts the work to produce a system by 40%.

Larry Bernstein

Bell Communications Research

[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.

Bill McKeeman

Wang Institute

Furious activity is no substitute for understanding.

H. H. Williams

Oakland, California

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.

Al Schapira

Bell Labs

6.7 Miscellaneous Rules

[Sturgeon's Law - This applies as well to computer science as to science fiction.] Sure, 90% of all software is crap. That's because 90% of everything is crap.

Mary Shaw

Carnegie -Mellon University

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

Perry Farrar

Germantown, Maryland

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

H. H. Williams

Oakland, California

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

Susan Gerhart

Microelectronics and Computer Technology Corporation

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

Guy L. Steele, Jr.

Tartan Laboratories

[KISS] Keep it simple, stupid.

Anon

6.8 Principles

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

Eschew clever rules.

Joe Condon

Bell Labs

6.9 Problems

Although this column has allocated just a few words to eachrule, most of the rules could be greatly expanded (say, into anundergraduate paper or into a bull session over a few beers).These problems show how one might expand the following rule.

Make it work first before you make it work fast.

Bruce Whiteside

Woodridge, Illinois

From Programming Pearls by Jon Bentley; Addison-Wesley1986 ISBN 0-201-10331-1 and
More Programming Pearls, Addison-Wesley 1988 ISBN0-201-11889-0