BUMPER STICKER COMPUTER SCIENCE   These are taken from the column 'Programming Pearls', by Jon Bentley, in the Sept85 issue of 'Communications of the ACM', and are brought to you courtesy of Victoria University (who provided a copy of the article), and JJB TEMPLAR, who typed all this in (and added the {squiggly} bits).   Coding   "When in doubt, use brute force"  - Ken Thomson, Bell Labs. {UNIX}  "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/Calsapn Advanced Technology Center.  "Allocate four digits for the year part of a date: a new millenium 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 Carloson, 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.  "A procedure should fit on a page"  - David Tribble, Arlington, Texas.  "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.   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. {C}  "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 percent of all data sets, 95 percent of the information can be  seen in a good graph"  - William S. Cleveland, Bell Labs.   Debugging   "Of all my programming bugs, 80 percent are syntax errors. Of the  remaining 20 percent, 80 percent are trivial logic errors. Of the  remaining 4 percent, 80 percent are pointer errors. And the remaining  0.8 percent are hard"  - Marc Donner, IBM T.J.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 the 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 Stores, Cedar Rapids, Iowa.  "Don't get sucked in by the comments - they can be terribly misleading.  Debug only the code"  - Dave Stores, Cedar Rapids, Iowa.  "Testing can show the presence of bugs, not their absence"  - Edsger W. Dijkstra, University of Texas. {Bane of Computer Science students everywhere}  "Each new user of a new system uncovers a new class of bugs"  - Brian Kernighan, Bell Labs. {C}  "If it ain't broke, don't fix it"  - Ronald Reagan, Santa Barbara, California. {Prez}  "[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 to get it to fail  repeatedly"  - Tom Duff, Bell Labs.   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. {NOT MJ the W}  "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. {True for 68000}  "In non-I/O-bound programs, a few percent of the source code typically  accounts for over half the run time"  - Don Knuth, Stanford University.{TeX, Art of Computer Programming}  "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 a 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, Morristown, 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.  "[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. {Finder of the first 'bug'. A frizzled moth in one of the old vacuum tube things - this moth still exists}  "LISP programmers know the value of everything but the cost of nothing"  - Alan Perlis, Yale University.  "[Little's Formula] The average number of objects in a queue is the  product of the entry rate and the average holding time"  - Peter Denning, RIACS. {Father of relational databases}   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, Morristown, 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" 0m - Anon.   Managing Software   "The structure of a system reflects the structure of the organization  that built it"  - Richard E. Fairley, Wang Institue.  "Don't keep doing what doesn't work"  - Anon.  "[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"  - Tom Cargill, Bell Labs.  "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"  - Mary Shaw, Carnegie-Mellon University.  "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 10  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 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 percent"  - 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.   Miscellaneous Rules   "If you lie to the computer, it will get you"  - Perry Farrer, 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 Geghart, Microelectronics and Computer Technology Corp.  "One person's data is another person's program"  - Guy L. Steele, Jr., Tartan Laboratories.   Principles   "Eschew clever rules"  - Joe Condon, Bell Labs.  "Make it work first before you make it work fast"  - Bruce Whiteside, Woodridge, Illinois.