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 107, 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 107 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