1256 quotes about technology. Curated.

Silicon Axioms:

1. You don’t manage people, you manage things. You lead people. — Admiral Grace Hopper

2. Program testing can be used to show the presence of bugs, but never to show their absence. — Edsger W. Dijkstra

3. It is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. — Edsger W. Dijkstra

4. Computer science is no more about computers than astronomy is about telescopes. — Edsger W. Dijkstra

5. If you have a procedure with ten parameters, you probably missed some. — Alan Perlis

6. Adding manpower to a late software project makes it later. — Fred Brooks

7. We can only discover knowledge in an environment that contains that knowledge. — Philip G. Armour

8. Process only allows us to do things we already know how to do. You cannot have a process for something you have never done or do not know how to do. — Philip G. Armour

9. The only processes we can use on the current project were defined on previous projects, which were different from this one. — Philip G. Armour

10. We can only define software processes at two levels: too vague or too confining. — Philip G. Armour

11. What all software developers really want is a rigorous, iron-clad, hide-bound, concrete, universal, absolute, total, definitive, and complete set of rules that they can break. — Philip G. Armour

12. The very last type of knowledge to be considered as a candidate for implementation into an executable software system is the knowledge of how to implement knowledge into an executable software system. — Philip G. Armour

13. If you can’t show that your process is better than random, don’t use it. — Gerald Weinberg

14. Everything in the project must be visible at all times. — Gerald Weinberg

15. Nothing is real until it has passed independent review. — Gerald Weinberg

16. Anything you don’t measure will be out of your control. — Gerald Weinberg

17. If you don’t have to meet requirements, management is no problem. — Gerald Weinberg

18. Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter’s Law” — Douglas Hofstadter

19. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it is a disguise that the error is the programmer’s own creation. — Edsger W. Dijkstra

20. Not everything that can be counted counts, and not everything that counts can be counted. — Albert Einstein (1879–1955)

21. “Cover” is probably the most important word in the tester’s lexicon. If you don’t use some kind of structural coverage metric such as branch cover, you can’t have a quantitative notion of how thorough your testing has been. Am I suggesting that we now drop the use of structural coverage metrics? No! We still want to use whatever coverage metrics we can, such as statement, branch, predicate condition, and data-flow. — Boris Beizer

22. “Good enough software” is rarely good enough. It is a sad manifestation of the spirit of modern times, in which an individual’s pride in his/her work has become rare. The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed. Nothing but economic success and monetary reward is acceptable. Hence our occupations have become mere jobs. But quality of work can be expected only through personal satisfaction, dedication and enjoyment. In our profession, precision and perfection are not a dispensible luxury, but a simple necessity. — Niklaus Wirth

23. “Interim steps” have a tendency to become permanent in our industry, where “Compatibility” is the way the sins of the fathers are inflicted upon the third and fourth generations … — William Kahan

24. “Legacy code” is a term often used derogatorily to characterize code that is written in a language or style that (1) the speaker/writer considers outdated and/or (2) is competing with something sold/promoted by the speaker/writer. “Legacy code” often differs from its suggested alternative by actually working and scaling. — Bjarne Stroustrup

25. “Paradosfunctionoracle” is the term used by technicians to describe the reason no one knows why your computer won’t work. — J. H. Goldfuss

26. “Privacy,” I repeatedly hear, is the fetish of ponytailed paranoids who have something to hide. Wrong. Digital privacy is a simple, practical matter, a necessary step so we can get on with ecommerce without creating an avalanche of unsolicited interruptions. The digital world is already too noisy — I want anonymity for reasons of tranquility, not dishonesty. — Nicholas Negroponte

27. “Run everywhere” isn’t very everywhere, is it? Some days it’s just “Windows and maybe Linux or Mac.” If J2SE isn’t worth running on set-top boxes and game consoles, and if it’s always behind or half-baked on Mac and Linux, is it ultimately just a “me too” way to write Windows applications? — Chris Adamson

28. “Variety is the spice of life” applies to programming also. — Bjarne Stroustrup

29. In+a+programming+language Simple things should be simple and complex things should be possible. — Alan Kay

30. Internet sites need to be able to interact in one single, universal space. — Tim Berners-Lee

31. John+von+Neumann had the invaluable faculty of being able to take the most difficult problem and separate it into its components, whereupon everything looked brilliantly simple. — Stanislaw Ulam

32. Perl is the sanctuary of dunces. The godsend for brainless coders. The means and banner of sysadmins. The lingua franca of trial-and-error hackers. The song and dance of stultified engineers. — Xah Lee

33. Programming is the only job I can think of where I get to be both an engineer and an artist. There’s an incredible, rigorous, technical element to it, which I like because you have to do very precise thinking. On the other hand, it has a wildly creative side where the boundaries of imagination are the only real limitation. — A. Hertzfeld

34. Software+engineering+advocates have climbed a social ladder for a few decades and are now fighting against a tide of open source software that seems to be bringing bazaar anarchy and taking the well-deserved control out of their hands. Part of this is their utopia of “software engineering” by some magic cathedral approach which has never worked and whose failure the authors of these utopias tend to blame on the lack of control that copyright offers them over their projects. The strange thing here is that they have had the chance to put all these things into practice in their university haven. But, strangely enough, the more successful university projects are carried out in a bazaar-like open-source manner. — Hartmut Pilch

35. Testing+a+statistically+insignificant+portion+of+the+input+space+is a bad bet because you’re asserting that there is a functional relation between the parameters, or even worse, that there is a bug that will create a functional relation between parameters that were not otherwise related. That’s more likely to be sabotage than a bug. You test extreme point combinations only if there is a known functional relation between the parameters or if there is a high likelihood of a bug that could create such a relation. Otherwise, testing combinations of extreme points isn’t much better than attempting all possible input values. — Boris Beizer

36. [The robotic dog’s software is] stored on an 8MB Sony “memory stick” about two inches long. Sure enough, the memory stick gets inserted into the dog’s body in exactly the place you’d sort of hoped they would not have asked you to insert it. — Sony “Aibo” robotic dog owner John Wharton

37. The+trick+in+software+engineering+is+to+find+out how to do intellectually-intensive work in teams. — R. E. Fairley

38. 100 pages of comments will not make a poorly written page of code not suck. — Robert Mollitor

39. 111,111,111 x 111,111,111 = 12,345,678,987,654,321 — from Useless Facts

40. 2 + 2 = 5, for large values of 2. — Anonymous

41. 90% of code written today is getting around other people’s mistakes. — Alan Kay

42. A “hacker” is any person who derives joy from discovering ways to circumvent limitations. — Robert Bickford

43. A programming language is there to allow, not to restrict. — Mathieu Bouchard

44. A brute force solution that works is better than an elegant solution that doesn’t work. — Steve McConnell

45. A C program is like a fast dance on a newly waxed dance floor by people carrying razors. — Waldi Ravens

46. A class is where we teach objects how to behave. — Richard Pattis

47. A common angry protest from software developers and users is that test cases are unrealistic. The developer protests that you’re stressing the software too much in the wrong way, in ways that don’t represent realistic use — I sure hope so. The user complains that because so much of your testing is based on weird situations, that they don’t have confidence that the software will work as intended when actually put to use — the user is also right. But they are also both wrong. They are both wrong because they are confusing two different test objectives. If you make (most of) your tests realistic, you’ll be destroying the effectiveness of the one objective without accomplishing the other. The two objectives are: (1) testing to reveal bugs and (2) testing to support statistically valid inferences about the product’s fitness for use in a real environment. — Boris Beizer

48. A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. — Douglas Adams

49. A complex system that works is invariably found to have evolved from a simple system that works. — John Gall

50. A computer and a cat are somewhat alike — they both purr, and like to be stroked, and spend a lot of the day motionless. They also have secrets they don’t necessarily share. — John Updike

51. A computer cannot turn bad data into good data. — John R. Pierce

52. A computer does not substitute for judgment any more than a pencil substitutes for literacy. But writing without a pencil is no particular advantage. — Robert McNamara

53. A computer does not think, it feels nothing, and what it is said to “know” — bits of information all cast in the digital mode — has no fringe. Nor has it a memory, only storage room. On any point called for, the answer is all or none. Vagueness, intelligent confusion, original punning on words or ideas never occur, the internal hookups being unchangeable; they were determined once for all by the true minds that made the machine and program. When plugged in, the least elaborate computer can be relied on to work to the fullest extent of its capacity; the greatest mind cannot be relied on for the simplest thing; its variability is its superiority. — Jacques Barzun

54. A computer is a state machine. Threads are for people who can’t program state machines. — Alan Cox

55. A computer is essentially a trained squirrel: acting on reflex, thoughtlessly running back and forth and storing away nuts until some other stimulus makes it do something else. — Ted Nelson

56. A computer is like a violin. You can imagine a novice trying first a phonograph and then a violin. The latter, he says, sounds terrible. That is the argument we have heard from our humanists and most of our computer scientists. Computer programs are good, they say, for particular purposes, but they aren’t flexible. Neither is a violin, or a typewriter, until you learn how to use it. — Marvin Minsky

57. A computer is only as smart as the numbskull sitting in front of it. — Micah Branstetter

58. A computer lets you make more mistakes faster than any other invention in human history, with the possible exception of handguns and tequila. — Mitch Radcliffe

59. A computer once beat me at chess, but it was no match for me at kick boxing. — Emo Philips

60. A computer programmer is a device for turning requirements into undocumented features. It runs on cola, pizza and Dilbert cartoons. — Bram Moolenaar

61. A computer shall not harm your work or, through inaction, allow your work to come to harm. — Jef Raskin

62. A computer shall not waste your time or require you to do more work than is strictly necessary. — Jef Raskin

63. A computer terminal is not some clunky old television with a typewriter in front of it. It is an interface where the mind and body can connect with the universe and move bits of it about. — Douglas Adams

64. A computer will do what you tell it to do, but that may be much different from what you had in mind. — Joseph Weizenbaum

65. A computer without COBOL and FORTRAN is like a piece of chocolate cake without ketchup or mustard. — John Krueger

66. A computer won’t clean up the errors in your manual of procedures. — Sheila M. Eby

67. A consequence of a functional dominance to the test organization is that different tests are likely to be based on different test techniques rather than the specifics of the application. An application orientation means that you’ll have a syntax test followed by a state-machine test, then a domain test, etc., with the consequence that you have to bop back and forth between different test tools: in itself, a major hindrance to both test design and test execution automation. A more practical organization of test suites is: 1. The driver used to execute the test. 1.1. Within that, the technique used to create the test. 1.1.1. Within that, component groups that implement the feature. 1.1.1.1. Within that, the functionality seen by the user. — Boris Beizer

68. A crash is when your competitor’s program dies. When your program dies, it is an “idiosyncrasy.” — Guy Kawasaki

69. A curious kind of tribalism seems to be part and parcel of the social psychology of software development. For many people, being proficient in some technical skill is not enough: one must become a true believer, taking the view that one’s technology of choice is vastly superior and that practitioners of different approaches are misguided, at best. I am a proponent of effective testing, which means that we must consider what can go wrong. Clearly, this analysis must be based on facts, not tribalism. — Robert Binder

70. A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable. — Leslie Lamport

71. A general-purpose programming language should support a variety of ways of thinking and a variety of programming styles. — Bjarne Stroustrup

72. A girl walked into the computer center where I work. She said she was having problems with her Mac. I asked what kind of Mac she had. In an indignant voice, she replied, “Duh, Intosh.” — Samuel Stoddard

73. A good debugging practice is to keep a record of every mistake that is made. Even though this will probably be quite embarrassing, such information is invaluable to anyone doing research on the debugging problem, and it will also help you learn how to reduce the number of future errors. — Donald Knuth

74. A good design is one that you can explain to someone in an elevator ride without wincing internally at your simplifications. The fewer floors you need, the better your design is. — Michael Feathers

75. A good model guides your thinking, a bad one warps it. — Brian Marick

76. A good programmer is someone who looks both ways before crossing a one-way street. — Doug Linder

77. A good programming language is a conceptual universe for thinking about programming. — Alan Perlis

78. A good programming language should, like oil paint, make it easy to change your mind. — Paul Graham

79. A good scare is worth more to a man than good advice. — Edgar Watson Howe

80. A good scientist is a person with original ideas. A good engineer is a person who makes a design that works with as few original ideas as possible. There are no prima donnas in engineering. — Freeman Dyson

81. A good system can’t have a weak command language. — Alan Perlis

82. A good threat is worth a thousand tests. — Boris Beizer

83. A great lathe operator commands several times the wage of an average lathe operator, but a great writer of software code is worth 10,000 times the price of an average software writer. — Bill Gates

84. A hacker on a roll may be able to produce, in a period of a few months, something that a small development group, say seven or eight people, would have a hard time getting together over a year. IBM used to report that certain programmers might be as much as 100 times as productive as other workers, or more. — Peter Seebach

85. A human can do better than what a machine does best. Recursive and true. — Assaad Chalhoub

86. A language that doesn’t affect the way you think about programming, is not worth knowing. — Alan Perlis

87. A language that doesn’t have everything is actually easier to program in than some that do. — Dennis Ritchie

88. A LISP programmer knows the value of everything, but the cost of nothing. — Alan Perlis

89. A lot is written about digital identity, particularly about using the Net to role-play, to pretend you are somebody other than who you are. Almost nothing is written about the value of being nobody — not somebody different, but nobody in particular. — Nicholas Negroponte

90. A main purpose of testing is to discover bugs. In every test method there is an implicit assumption about the kinds of bugs you’re likely to find. If for example, you have lots of domain bugs, then domain testing is implied. Similarly, a weak front-end for command-driven software implies syntax testing. — Boris Beizer

91. A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits. A programming language is a tool that has profound influence on our thinking habits. — Edsger Dijkstra

92. A one-question geek test. If you get the joke, you’re a geek: Seen on a California license plate on a VW Beetle: “FEATURE” — Joshua D. Wachs

93. A pattern is always a problem-solution pair that can be applied in a particular context. Although the solutions might look similar in different patterns, the problems they are solving are different. In fact from ten thousand meters most patterns solve a problem by adding a level of indirection. What is interesting is how this indirection comes about and in particular why it needs to happen. Therefore if you just look at the solution to the problem, it isn’t that enlightening and everything starts to look the same. When we wrote design patterns we often had this feeling — they all started to look like the Strategy pattern. — Erich Gamma

94. A picture is worth 10K words, but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. — Alan Perlis

95. A program is complex when an optimum solution exists but it cannot be found. — Rodolfo A. Frino

96. A program is never less than 90% complete, and never more than 95% complete. — Terry Baker

97. A program should follow the “Law of Least Astonishment.” What is this law? It is simply that the program should always respond to the user in the way that astonishes him least. — The Tao of Programming

98. A program without a loop and a structured variable isn’t worth writing. — Alan Perlis

99. A programmer is a person who passes as an exacting expert on the basis of being able to turn out, after innumerable punching, an infinite series of incomprehensive answers calculated with micrometric precisions from vague assumptions based on debatable figures taken from inconclusive documents and carried out on instruments of problematical accuracy by persons of dubious reliability and questionable mentality for the avowed purpose of annoying and confounding a hopelessly defenseless department that was unfortunate enough to ask for the information in the first place. — IEEE Grid newsmagazine

100. A programming language is a system of notation for describing computations. A useful programming language must therefore be suited for both description (i.e., for human writers and readers of programs) and for computation (i.e., for efficient implementation on computers). But human beings and computers are so different that it is difficult to find notational devices that are well suited to the capabilities of both. — R. Tennant

101. A programming language is a tool that has profound influence on our thinking habits. — Edsger Dijkstra

102. A programming language is like a natural, human language in that it favors certain methaphors, images, and ways of thinking. — Seymour Papert

103. A programming language is low level when its programs require attention to the irrelevant. — Alan Perlis

104. A really good language should be both clean and dirty: cleanly designed, with a small core of well understood and highly orthogonal operators, but dirty in the sense that it lets hackers have their way with it… A real hacker’s language will always have a slightly raffish character. — Paul Graham

105. A scientific approach is generally characterized by the words logical, systematic, impersonal, calm, rational, while an artistic approach is characterized by the words aesthetic, creative, humanitarian, anxious, irrational. It seems to me that both of these apparently contradictory approaches have great value with respect to computer programming. — Donald E. Knuth

106. A software system should be like a Mozart symphony: Perfection at all levels. — Bjarne Dacker

107. A solved problem creates two new problems, and the best prescription for happy living is not to solve any more problems than you have to. — Russell Baker

108. A specification, design, procedure, or test plan that will not fit on one page of 8.5-by-11 inch paper cannot be understood. — Mark Ardis, Wang Institute

109. A standard for copy protection is as premature as a standard for teleportation. — Edward Felten

110. A system support specialist’s life is a sorry one. The only advantage he has over ER doctors is that malpractice suits are rare. On the other hand, ER doctors never have to deal with patients installing new versions of their own innards! — Dick Maliska

111. A UNIX signature isn’t a return address, it’s the ASCII equivalent of a black velvet clown painting. It’s a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. — Chris Maeda

112. A well used door needs no oil on its hinges. A swift-flowing stream does not grow stagnant. Software rots if not used. These are great mysteries. — The Tao of Programming

113. A well-designed and humane interface does not need to be split into beginner and expert subsystems. — Jef Raskin

114. A while ago I was received a call from a woman who said that Eudora Pro was showing her password. I found this to be strange, because when you type it in your password in Eudora, it displays asterisks. So when I went over to her office and looked at her desktop. She had renamed the Eudora Pro icon with her password. — Samuel Stoddard

115. A year spent in artificial intelligence is enough to make one believe in God. — Alan Perlis

116. A.C.R.O.N.Y.M. — A Contrived Reduction Of Nouns, Yielding Mnemonics — Unknown

117. About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead. — Edsgar W. Dijkstra

118. About two months ago, a client called in screaming profanities at me and demanding that I either give him a refund on his one year old system or send a technician out to repair it immediately. His problem was that the taskbar was on the right-hand side of his screen, and he couldn’t get it back to the bottom. — Samuel Stoddard

119. Above all, I hope we in computer science don’t become missionaries. Don’t feel as if you’re Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don’t feel as if the key to successful computing is only in your hands. What’s in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more. — Alan Perlis

120. Adapting old programs to fit new machines usually means adapting new machines to behave like old ones. — Alan Perlis

121. After more than 30 years of programming we ought to know that the design of complex software is inherently difficult. Edsger Dijkstra called Software Engineering “Programming in spite of the fact that you can’t.” Indeed, the woes of Software Engineering are largely due to lack of sufficient technical competence. A good designer must rely on experience, on precise, logic thinking; and on pedantic exactness. No magic will do. It is particularly sad that in many informatics curricula, programming in the large is badly neglected. Design has become a non-topic. As a result, software engineering has become the El Dorado for hackers. The more chaotic a program looks, the smaller the danger that someone will take the trouble of inspecting and debunking it. — Niklaus Wirth

122. Ah, the “Birds” fly. Except penguins, kiwis, ostriches… problem. — Hugh Eng

123. AI and Software Engineering. It may well be that the way to build an intelligence is just to get your hands on dirty engineering problems. We don’t have a theory of automobiles. We have good cars, but there are no fundamental equations of automotive science. — Hans Moravec

124. All C programs do the same thing: look at a character and do nothing with it. — Peter Weinberger

125. All language designers are arrogant. Goes with the territory… — Larry Wall

126. All models are wrong; some models are useful. — George Box

127. All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use a hammer. — 1925 IBM Maintenance Manual

128. All programmers are optimists. Perhaps this modern sorcery especially attracts those who believe in happy endings and fairy godmothers. Perhaps the hundreds of nitty frustrations drive away all but those who habitually focus on the end goal. Perhaps it is merely that computers are young, programmers are younger, and the young are always optimists. But however the selection process works, the result is indisputable: “This time it will surely run” or “I just found the last bug.” — Fred Brooks

129. All software sucks. — Alan Cox

130. All sorts of computer errors are now turning up. You’d be surprised to know the number of doctors who claim they are treating pregnant men. — Isaac Asimov

131. All stable processes we shall predict. All unstable processes we shall control. — John von Neumann

132. All successful softwares are results of dreams — Assaad Chalhoub

133. Almost without exception the most recent release of any software product is slightly worse than what it’s replacing. Take a deep breath and repeat after me: “Leave it alone.” Well intentioned ameliorations have turned elegant solutions into bloated programs, the “upgrade” often being that you can do almost the same thing in five or more different ways, with inconsistent results. — Nicholas Negroponte

134. Always design your programs as a member of a whole family of programs, including those that are likely to succeed it. — Edsger Dijkstra

135. Always make new mistakes! — Esther Dyson

136. Alzheimer’s Law of Programming: Looking at code you wrote more than two weeks ago is like looking at code you are seeing for the first time. — Dan Hurvitz

137. Americans have a pathological fear of formal manipulation. It seems that the United States has a century of demathematicization which of course is very tragic because in the same century the mathematical computer is invented which is a major mathematical challenge. Somehow or other the mathematical nature of the challenge seems to have been ignored here as politically unpalatable. — Edsger Dijkstra

138. An adequate bootstrap is a contradiction in terms. — Alan Perlis

139. An algorithm must be seen to be believed. — Donald Knuth

140. An application that does something really great that people really want to do can be pathetically unusable, and it will still be a hit. And an application can be the easiest thing in the world to use, but if it doesn’t do anything anybody wants, it will flop. — Joel Spolsky

141. An effective way to test code is to exercise it at its natural boundaries — Brian Kernighan

142. An initial underscore already conveys strong feelings of magicalness to a C programmer. — Larry Wall

143. An interactive debugger is an outstanding example of what is not needed — it encourages trial-and-error hacking rather than systematic design, and also hides marginal people barely qualified for precision programming. — Harlan D. Mills

144. An old puzzle asks how a barometer can be used to measure the height of a building. Answers range from dropping the instrument from the top and measuring the time of its fall to giving it to the building’s superintendent in return for a look at the plans. A modern version of the puzzle asks how a personal computer can balance a checkbook. An elegant solution is to sell the machine and deposit the money. — Jon Bentley

145. An organization that treats its programmers as morons will soon have programmers that are willing and able to act like morons only. — Bjarne Stroustrup

146. Analytical software enables you to shift human resources from rote data collection to value-added customer service and support where the human touch makes a profound difference. — Bill Gates

147. And despite the occasional predictions that assembly language will be outlawed by the US government sometime this decade, it is likely that someone who is absolutely determined to sink to the lowest level of programming languages will be able to find an employer who will indulge his base instincts. — Ed Yourdan in 1991

148. And don’t tell me there isn’t one bit of difference between null and space, because that’s exactly how much difference there is. — Larry Wall

149. And every now and then people find the bugs, and they interpret those as cool failures in the Sims terms. For them it’s like a treasure hunt, you know. Players like to know that they’ve discovered things that even the designers didn’t know were in the game. — Will Wright

150. And no, I’m not a Java fan. I dislike hype, I dislike marketing of programming tools to nonprogrammers, I dislike proprietary languages, and I like lots of programming languages. — Bjarne Stroustrup

151. And then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. — B. Bryson

152. Another effective debugging technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarrassed “Never mind, I see what’s wrong. Sorry to bother you.” This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor. — Brian Kernighan

153. Another good debugging practice is to keep a record of every mistake that is made. Even though this will probably be quite embarrassing, such information is invaluable to anyone doing research on the debugging problem, and it will also help you learn how to reduce the number of future errors. — Donald Knuth

154. Another terrible stress testing practice is to attempt manual stress testing — only the testers gets stressed. It’s another, worthless, feel-good testing method. — Boris Beizer

155. Any attempt to brew coffee with a teapot should result in the error code “418 I’m a teapot.” The resulting entity body MAY be short and stout. — HTCPCP Spec, RFC 2324

156. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — R. Fowler

157. Any general system law will have at least two peculiar exceptions. — Gerald Weinberg

158. Any Internet user knows it is quite difficult to stumble across pornography. — Senator Russel Feingold

159. Any nitwit can understand computers. Many do. — Ted Nelson

160. Any noun can be verbed. — Alan Perlis

161. Any one “view” of requirements is insufficient to understand or describe the desired behavior of a complex system. — Alan M. Davis

162. Any performance problem can be solved by removing a level of indirection. — Mike Haertel

163. Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem. — Davin Wheeler

164. Any sufficiently advanced bug is indistinguishable from a feature. — Rick Kulawiec

165. Any teacher that can be replaced by a computer, deserves to be. — David Thornburg

166. Anybody who’s studied software engineering knows that a schedule which underestimates the time needed to develop a project actually makes the project take longer. — Jeff Raskin

167. Anyone attempting to generate random numbers by deterministic means is, of course, living in a state of sin. — John Von Neumann

168. Anyone can make a project fail through sheer luck. Only the savvy know how to do it by design. — Naomi Karten

169. Anyone who has lost track of time when using a computer knows the propensity to dream, the urge to make dreams come true and the tendency to miss lunch. — Tim Berners-Lee

170. Anyone who slaps a “this page is best viewed with Browser X” label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. — Tim Berners-Lee

171. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient. — Bjarne Stroustrup

172. AOL is like the cockroach left after the nuclear bomb hits. They know how to survive. — Jan Horsfall

173. Applicants must also have extensive knowledge of UNIX, although they should have sufficiently good programming taste to not consider this an achievement. — MIT job advertisement

174. Are you quite sure that all those bells and whistles, all those wonderful facilities of your so called powerful programming languages, belong to the solution set rather than the problem set? — Edsger Dijkstra

175. Arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark. — Thant Tessman

176. Arguments over grammar and style are often as fierce as those over IBM versus Mac, and as fruitless as Coke versus Pepsi and boxers versus briefs — Jack Lynch

177. Around computers it is difficult to find the correct unit of time to measure progress. Some cathedrals took a century to complete. Can you imagine the grandeur and scope of a program that would take as long? — Alan Perlis

178. Artificial intellegence is no match for natural stupidity. — Sarah Chambers

179. Artificial Intelligence is whatever hasn’t been done yet. — Larry Tesler

180. Artificial Intelligence: the art of making computers that behave like the ones in movies. — Bill Bulko

181. Artificial intelligences make mistakes too, only faster. — Larry Wall

182. As a rule, software systems do not work well until they have been used, and have failed repeatedly, in real applications. — David Parnas

183. As a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure. — Edsger W. Dijkstra

184. As complexity rises, precise statements lose meaning, and meaningful statements lose precision. — Lotfi Zadeh

185. As economics is known as “The Miserable Science,” software engineering should be known as “The Doomed Discipline” — doomed because it cannot even approach its goal since its goal is self-contradictory. If you carefully read its literature and analyze what its devotees actually do, you will discover that software engineering has accepted as its charter, “How to program if you cannot.” The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsman, viz., programmers. — Edsger W. Dijkstra

186. As far as I’m concerned, manual testing is ludicrous and self-contradictory. It’s based upon a fallacy. Anybody who thinks they can test manually, doesn’t take into account the error rate in manual test execution. — Boris Beizer

187. As far as the customer is concerned, the interface is the product. — Jef Raskin

188. As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now 1972 that we have gigantic computers, programming has become a gigantic problem. As the power of available machines grew by a factor of more than a thousand, society’s ambition to apply these new machines grew in proportion, and it was the poor programmer who found his job in this exploded field of tension between the ends and the means. The increased power of the hardware, together with the perhaps more dramatic increase in its reliability, made solutions feasible that the programmer had not dared to dream about a few years before. And now, a few years later, he had to dream about them and even worse, he had to transform such dreams into reality! It is no wonder that we found ourselves in a software crisis — Edsger Dijkstra

189. As machines become more and more efficient and perfect, so it will become clear that imperfection is the greatness of man. — Ernst Fischer

190. As part of the conversion, computer specialists rewrote 1,500 programs — a process that traditionally requires some debugging. — USA Today, referring to the IRS switchover to a new computer system

191. As soon as the+Wardenclyffe+facility+is completed, it will be possible for a business man in New York to dictate instructions, and have them instantly appear in type at his office in London or elsewhere. He will be able to call up, from his desk, and talk to any telephone subscriber on the globe, without any change whatever in the existing equipment. An inexpensive instrument, not bigger than a watch, will enable its bearer to hear anywhere, on sea or land, music or song, the speech of a political leader, the address of an eminent man of science, or the sermon of an eloquent clergyman, delivered in some other place, however distant. In the same manner any picture, character, drawing, or print can be transferred from one to another place … — Nikola Tesla, Wireless Telegraphy and Telephony, 1908

192. As soon as we have a single requirement in our net we can start testing. The aim is to trap requirements-related defects as early as they can be identified. We prevent incorrect requirements from being incorporated in the design and implementation where they will be more difficult and expensive to find and correct. — Suzanne Robertson

193. As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs. — Maurice Wilkes discovers debugging, 1949

194. As testers, we must test every line of code (or see to it that someone has done it). That means exercising many conditions that are unlikely to come up in any one user’s experience. The programmer who protests that we’re being unrealistic is contradicting herself because much of her code is “unrealistic” in the same sense. Another reason for using “unrealistic” tests is that realistically, that’s often the only way to force certain low probability timing and race conditions to which our software must be invulnerable. — Boris Beizer

195. As the world becomes increasingly inundated with information, value shifts from individual pieces of information to the structure placed on the information. — Michael F. Schwartz

196. As Will Rogers would have said, “There is no such thing as a free variable.” — Alan Perlis

197. At a place like IBM, there’s an infinite world of products that you can create. But, too often, management would say, “Great, you big-idea guys, go go go.” But then they give all the money to the people who control the revenue streams, the people with the overhead projectors and PowerPoint slides. — Ted Selker

198. At first I hoped that such a technically unsound project [the PL/I design phase] would collapse, but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way, and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay. — Charles Anthony Richard Hoare

199. At Microsoft there are lots of brilliant ideas but the image is that they all come from the top — I’m afraid that’s not quite right. — Bill Gates

200. At some point in the project somebody will start whining about the need to determine the project requirements. This involves interviewing people who don’t know what they want but, curiously, know exactly when they need it. — Scott Adams

201. At some point you have to decide whether you’re going to be a politician or an engineer. You cannot be both. To be a politician is to champion perception over reality. To be an engineer is to make perception subservient to reality. They are opposites. You can’t do both simultaneously. — H. W. Kenton

202. At the risk of being a total killjoy, I propose that you look at the next Dilbert cartoon that falls under your eye in a totally different way. Ask yourself about Dilbert’s role in whatever corporate nonsense is the butt of the joke. At least partly at fault for every bad management move is some gutless Dilbert who allows it to happen. — Tom DeMarco

203. At this time I do not have a personal relationship with a computer. — Janet Reno

204. Bad code isn’t bad, it’s just misunderstood. — Lettie Buena

205. Bandwidth grows at least three times faster than computer power. — George Gilder

206. Barring miracles, you could not run your car by doing a computer simulation of the oxidation of gasoline, and you could not digest pizza by running a program that simulates such digestion. It seems obvious that a simulation of cognition will similarly not produce the effects of the neurobiology of cognition. — John Searle

207. Base eight is just like base ten really, if you’re missing two fingers. — Tom Lehrer

208. BASIC is to computer programming as QWERTY is to typing. — Seymour Papert

209. Basic research is what I’m doing when I don’t know what I’m doing. — John Von Neuman

210. Basically, our goal is to organize the world’s information and to make it universally accessible and useful. — Larry Page

211. Be nice to nerds. Chances are you’ll end up working for one. — Bill Gates

212. Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defense against complexity. The geniuses of the computer field, on the the other hand, are the people with the keenest aesthetic senses, the ones who are capable of creating beauty. Beauty is decisive at every level: the most important interfaces, the most important programming languages, the winning algorithms are the beautiful ones. — David Gelernter

213. Because every person knows what he likes, every person thinks he is an expert on user interfaces. — Paul Heckel

214. Because of its vitality, the computing field is always in desperate need of new cliches: Banality soothes our nerves. — Alan Perlis

215. Because we are returning a copy for postfix expressions, statements such as (c+)+; won’t work as expected. — Weiskamp & Flamig, “The Complete C++ Primer”

216. Before software can be reusable it first has to be usable. — Ralph Johnson

217. Before we work on artificial intelligence why don’t we do something about natural stupidity? — Steve Polyak

218. Being a better programmer means being able to design more effective and trustworthy programs and knowing how to do that efficiently. It is about not wasting storage cells or machine cycles and about avoiding those complexities that increase the number of reasoning steps needed to keep the design under strict intellectual control. — Edsger Dijkstra

219. Being a Linux user is sort of like living in a house inhabited by a large family of carpenters and architects. Every morning when you wake up, the house is a little different. Maybe there is a new turret, or some walls have moved. Or perhaps someone has temporarily removed the floor under your bed. — John R. Levine and Margaret Levine Young in “Unix For Dummies”

220. Being able to break security doesn’t make you a hacker anymore than being able to hotwire cars makes you an automotive engineer. — Eric Raymond

221. Being abstract is something profoundly different from being vague… The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise. — Edsger Dijkstra

222. Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it. — Guy Steele

223. Being really good at C++ is like being really good at using rocks to sharpen sticks. — Thant Tessman

224. Besides a mathematical inclination, an exceptionally good mastery of one’s native tongue is the most vital asset of a competent programmer. — Edsger Dijkstra

225. Best Practice: If you’re trying to find true system bugs and have never subjected this software to a real stress test, then it is high time you started. Dollar for dollar, stress testing has probably the highest payoff of any test technique for finding system bugs. Proper stress testing is useful in finding synchronization and timing bugs, interlock problems, priority problems, resource loss bugs, and general abuse of the API. Stress testing is usually easy to set up. You can create stress loads by looping transactions back on themselves so that the system stresses itself: e.g., an incoming message is output on a looped-back line to generate another incoming message. Alternatively you can use another system of comparable size to create the stress load. — Boris Beizer

226. Best Practice: Once we’ve found and fixed the low level bugs it’s time to address real system bugs. We do this because if we don’t, our end-users will find these bugs for us. Most system bugs, such as resource loss, timing, and synchronization bugs can be found by applying specific system testing methods. There’s no need to be victimized by such bugs if you’ve made a concerted effort to find them. And there’s also no excuse for them. — Boris Beizer

227. Best Practice: Testing the interfaces between otherwise correct components to assure that they are compatible. Integration bugs are just behind unit bugs in frequency; and for object-oriented software, are probably more frequent. — Boris Beizer

228. Best Practice: Using small, representative sample of your installed user base (e.g., under 1%) for+beta+testing can be an effective way to wring out latent configuration sensitivity and performance bugs not previously found. The sample must be representative of both high-end and low-end configurations and high-end and low-end users. — Boris Beizer

229. Best Practice: We build software for users. They’re not (should not be) concerned with how the software works, how it’s organized, or the cute programming tricks we used. They’re only concerned with how it behaves and therefore, testing that behavior must be central to the testing effort. This philosophy must be applied to every level because the “user” of an internal subroutine, say, is the programmer who calls that subroutine. Therefore, testing to requirements of every level should be an objective at every testing level. — Boris Beizer

230. Beta testers are vulnerable to what I have called “programmers’ immunity.” This is the phenomenon in which programmers or testers subconsciously modify their behavior in order to avoid bugs that they are barely, consciously, aware of. It’s amazing how quickly the subconscious mind teaches us how to walk through a mine field. Judging from how often software that flies through beta testing with honors crashes in the field, programmers’ immunity must also be at work with+beta+testers. Automated testing minimizes the effects of programmers’ immunity, but most beta testers aren’t automated and consequently, for them, the immunity is likely to be more prevalent. False confidence again. — Boris Beizer

231. Beta testing seems to be firmly entrenched as the last bastion against rampaging bugs. But beta testing is effective only when the internal testing isn’t. If the software is well tested, beta testers don’t find much that your own testers and programmers haven’t found earlier. Furthermore, they report hundreds of symptoms for the same bug and it’s a big job to correlate all those trouble reports and find out that you’ve been talking about the same bug that has long ago been scheduled for repair. — Boris Beizer

232. Between 1892 say, and 1904, movies were made by the cameraman because he understood the equipment. And that is exactly where we are now in+software+design. In 1904 they invented the director; what was the director? It was the guy who didn’t have to know how to load the camera didn’t have to know how to sew costumes, play a violin, dance, fence, or hang the lights. But, he had to know how to make those effects come together in a unified experience. Why are video games so much better designed than office software? Videogames are designed by people who love to play video games. Office software is designed by people who want to do something else on the weekend. What does showbusiness teach you? It teaches you that design is war; it is a power struggle between the producers, directors, authors, everyone who wants to be involved. — Ted Nelson

233. Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy. — Alan Perlis

234. Beyond this I must add that programming in Smalltalk is fun. On the one hand, the act of assembling expressions into statements and then into methods is not very different from conventional programming. On the other hand, the experience is totally different, for the objects which populate and traverse the code are active entities, and writing expressions feels like organizing trained animals rather than pushing boxes around. — Daniel Ingalls, 1978

235. Blink your eyelids periodically to lubricate your eyes. — page 16 of the HP “Environmental, Health Safety Handbook for Employees”

236. Bringing computers into the home won’t change either one, but may revitalize the corner saloon. — Alan Perlis

237. British troops conducting counter-insurgency operations in Aden in the 1960s reputedly tied terror suspects up to an old IBM mainframe computer, explaining that radiation from their lie detector would drain away their manhood unless they told the truth. — Australian Associated Press

238. Brooks’ Law: Adding manpower to a late software project makes it later. — Fred Brooks

239. BTW, a member of the ANSI C committee once told me that the only thing rand is used for in C code is to decide whether to pick up the axe or throw the dwarf. — Tim Peters

240. Bug, n.: An aspect of a computer program which exists because the programmer was thinking about Jumbo Jacks or stock options when he or she wrote the program. Fortunately, the second-to-last bug has just been fixed. — Ray Simard

241. bug, n: An elusive creature living in a program that makes it incorrect. The activity of “debugging”, or removing bugs from a program, ends when people get tired of doing it, not when the bugs are removed. — “Datamation”, January 15, 1984

242. Bugs lurk in corners and congregate at boundaries. — Boris Beizer

243. Building large applications is still really difficult. Making them serve an organization well for many years is almost impossible. — Malcolm P. Atkinson

244. Burn-out in a developer is the death of the artistic self, a perverse maturation, a shrinking with age, a withering with experience. — Jim McCarthy

245. But I have always been a hacker if you want to put it that way. I prefer to call it unorthodox or guerilla research protocols that test the limits of society, technological advances, overall impact upon our world and the never ending thirst for finding out just what the hell is out there. — Ian Murphy

246. But in our enthusiasm, we could not resist a radical overhaul of the system, in which all of its major weaknesses have been exposed, analyzed, and replaced with new weaknesses. — Bruce Leverett

247. But it’s a general way to debug: tell someone what right things your program is doing. Chances are that you will see the wrong thing(s) before the other person has said anything. I just stick a picture of a face on my monitor and talk to it to find bugs. — Richard van de Stadt

248. But let your communication be Yea, yea; nay, nay: for whatsoever is more than these cometh of evil. — Matthew 5:37 New+Testament+affirmation+of+the+binary+number+system

249. But that’s not the most insidious thing about beta testing. You can’t really do away with beta testing because the mythic effectiveness of beta testing is so strong that the trade press won’t let you get away without it. The worst part about beta testing is the pesticide paradox and programmers’ immunity. Beta testers wear out. Because most beta testers aren’t professional testers, they’re unlikely to change their behavior or how they go about finding bugs. But the bugs they could have found are now gone. So you get a clean bill of health from the beta testers and you (falsely) confidently believe that your software is now robust. Wrong! It’s only robust against this group of beta testers and not the general user population. — Boris Beizer

250. But there’s more to defining processes and coordinating people than assigning someone to dream up a checklist and get it blessed in a staff meeting — James Bach

251. But those are negative reasons for having independent testing. Independent testing can be useful (here he goes contradicting himself again) if the tester bring specialized expertise to the test floor that the developers do not, or cannot conveniently have. That is, if they add value. By specialized expertise I mean such things as: localization, usability, performance, security, cross platform compatibility, configuration, recovery, network, distributed processing — and a whole lot more. Whether such value-added independent testing is done by an organizationally independent test group is largely a parochial cultural thing and also a question of process maturity. — Boris Beizer

252. Buying the right computer and getting it to work properly is no more complicated than building a nuclear reactor from wristwatch parts in a darkened room using only your teeth. — Dave Barry

253. By claiming that they can contribute to software engineering, the soft scientists make themselves even more ridiculous. (Not less dangerous, alas!) In spite of its name, software engineering requires (cruelly) hard science for its support. — Edsger Dijkstra

254. C /n./: A programming language that is sort of like Pascal, except more like assembly, except that it isn’t very much like either one, or anything else. It is either the best language available to the art today, or it isn’t. — Ray Simard

255. C has all the expressive power of two dixie cups and a string. — Jamie Zawinski

256. C is often described, with a mixture of fondness and disdain varying according to the speaker, as “a language that combines all the elegance and power of assembly language with all the readability and maintainability of assembly language.” — MIT Jargon Dictionary

257. C is quirky, flawed and an enormous success. — Dennis Ritchie

258. C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, it blows away your whole leg. — Bjarne Stroustrup

259. C program is like a fast dance on a newly waxed dance floor by people carrying razors. — Waldi Ravens.

260. C#: Computer language that reminds us it is not intended for musicians. — Rodolfo A. Frino

261. C() is a write-only, high-level assembler language. — Stefan Van Baelen

262. C++ : Where friends have access to your private members. — Gavin Russell Baker

263. C++ has its place in the history of programming languages. Just as Caligula has his place in the history of the Roman Empire. — Robert Firth

264. C++ in Cantonese is pronounced “C ga ga.” Need I say more? — Mark Glewwe

265. C++ is an atrocity, the bletcherous scab of the computing world, responsible for more buffer overflows, more security breaches, more blue screens of death, more mysterious failures than any other computer language in the history of the planet Earth. — Eric Lee Green

266. C++ is history repeated as tragedy. Java is history repeated as farce. — Scott McKay

267. C++ is like jamming a helicopter inside a Miata and expecting some sort of improvement. — Drew Olbrich

268. C++ is the only current language making COBOL look good. — Bertrand Meyer

269. C++ programmer: Class of person who inherits from multiple parents. — Rodolfo A. Frino

270. C++ tries to guard against Murphy, not Machiavelli. — Damian Conway

271. C+ would make a decent teaching language if we could teach the + part without the C part. — Michael B. Feldman

272. C++: Where friends have access to your private members. — Gavin Russell Baker

273. Cannot empty the recycle bin. Try freeing up some space by emptying your recycle bin. — Windows 2000 error message

274. CautionCape does not enable user to fly. — Batman costume warning label

275. Celestial navigation is based on the premise that the Earth is the center of the universe. The premise is wrong, but the navigation works. An incorrect model can be a useful tool. — Kelvin Throop, III

276. Certainly not every good program is object-oriented, and not every object-oriented program is good. — Bjarne Stroustrup

277. Claiming Java is easier than C++ is like saying that K2 is shorter than Everest. — Larry O’Brien

278. COBOL has almost no fervent enthusiasts. As a programming tool, it has roughly the sex appeal of a wrench. — Charles Petzold

279. COBOL was designed so that managers could read code.

280. BASIC was designed for people who are not programmers.

281. FORTRAN is for scientists.

282. ADA comes from a committee — a government committee no less.

283. PILOT is for teachers.

284. PASCAL is for students.

285. LOGO is for children.

286. APL is for Martians.

287. FORTH, LISP and PROLOG are specialty languages.

288. C, however, is for programmers. — Al Stevens

289. Code generation, like drinking alcohol, is good in moderation. — Alex Lowe

290. Code should run as fast as necessary, but no faster; something important is always traded away to increase speed. — Richard Pattis

291. Code-coverage testing: Making every line of code feel appreciated and needed. — Sara Ford

292. Comments lie. Code doesn’t. — Ron Jeffries

293. Commercial pressures of one sort or another will divert the attention of the best thinkers from real innovation to exploitation of the current fad, from prospecting to mining a known lode. Perhaps this effect explains why so few interesting software systems have come from the larger computer companies; they are locked into the existing world. — Dennis M. Richie

294. Complexity has and will maintain a strong fascination for many people. It is true that we live in a complex world and strive to solve inherently complex problems, which often do require complex mechanisms. However, this should not diminish our desire for elegant solutions, which convince by their clarity and effectiveness. Simple, elegant solutions are more effective, but they are harder to find than complex ones, and they require more time, which we too often believe to be unaffordable — Nicklaus Wirth

295. Complexity is a sign of technical immaturity. Simplicity of use is the real sign of a well design product whether it is an ATM or a Patriot missile. — Daniel T. Ling

296. Composing computer programs to solve scientific problems is like writing poetry. You must choose every word with care and link it with the other words in perfect syntax. There is no place for verbosity or carelessness. To become fluent in a computer lnaguage demands almost the antithesis of modern loose thinking. It requires many interactive sessions, the hands-on use of the device. You do not learn a foreign language from a book, rather you have to live in the country for years to let the langauge become an automatic part of you, and the same is true for computer languages. — James Lovelock

297. Computation has made the tree flower. — Alan Perlis

298. Computer architecture, like other architecture, is the art of determining the needs of the user of a structure and then designing to meet those needs as effectively as possible within economic and technological constraints. Architecture must include engineering considerations, so that design will be economical and feasible; but the emphasis in architecture is upon the needs of the user, whereas in engineering the emphasis is upon the needs of the fabricator. — Fred Brooks

299. Computer dating is fine, if you’re a computer. — Rita Mae Brown

300. Computer games don’t affect kids, I mean if Pac Man affected us as kids, we’d all be running around in darkened rooms, munching pills and listening to repetitive music. — Marcus Brigstocke

301. Computer programming is an art form, like the creation of poetry or music. — Donald Knuth

302. Computer programming is an art…because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty. — Donald E. Knuth

303. Computer programming is tremendous fun. Like music, it is a skill that derives from an unknown blend of innate talent and constant practice. Like drawing, it can be shaped to a variety of ends — commercial, artistic, and pure entertainment. Programmers have a well-deserved reputation for working long hours but are rarely credited with being driven by creative fevers. Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see. — Larry O’Brien and Bruce Eckel

304. Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter. — Eric Raymond

305. Computer Science is a science of abstraction — creating the right model for a problem and devising the appropriate mechanizable techniques to solve it. — A. Aho and J. Ullman

306. Computer Science is embarrassed by the computer. — Alan Perlis

307. Computer science is the first engineering discipline ever in which the complexity of the objects created is limited by the skill of the creator and not limited by the strength of the raw materials. If steel beams were infinitely strong and couldn’t ever bend no matter what you did, then skyscrapers could be as complicated as computers. — Brian K. Reid

308. Computer Science is the first engineering discipline in which the complexity of the objects created is limited solely by the skill of the creator, and not by the strength of raw materials. — Brian Reid

309. Computer Science is the only discipline in which we view adding a new wing to a building as being maintenance. — James J, Horning

310. Computer science is to biology what calculus is to physics. It’s the natural mathematical technique that best maps the character of the subject. — Harold Morowitz

311. Computer science only indicates the retrospective omnipotence of our technologies. In other words, an infinite capacity to process data…but only data — i.e. the already given…and in no sense a new vision. With that science, we are entering an era of exhaustivity, which is also an era of exhaustion. — Jean Baudrillard

312. Computer Science: 1. A study akin to numerology and astrology, but lacking the precision of the former and the success of the latter. 2. The boring art of coping with a large number of trivialities. — Stan Kelly-Bootle

313. Computer Science: Science that studies ways to improve algorithms invented in the 18th century. — Rodolfo A. Frino

314. Computer Science:

1. A study akin to numerology and astrology, but lacking the precision of the former and the success of the latter.

2. The boring art of coping with a large number of trivialities. — Stan Kelly-Bootle

315. Computer system analysis is like child-rearing; you can do grievous damage, but you cannot ensure success. — Tom DeMarco

316. Computera million morons working at the speed of light. — David Ferrier

317. Computer-based interruptions fall into a sort of Heisenbergian uncertainty trap: it is difficult to know whether an e-mail message is worth interrupting your work for unless you open and read it — at which point you have, of course, interrupted yourself. Our software tools were essentially designed to compete with one another for our attention, like needy toddlers. — Clive Thompson

318. Computers “remember” things in the form of discrete entries: the input of quantities, graphics, words, etc. Each item is separable, perhaps designated by a unique address or file name, and all of it subject to total recall. Unless the machine malfunctions, it can regurgitate everything it has stored exactly as it was entered, whether a single number or a lengthy document. Human memory, on the other hand, is the invisible psychic adhesive that holds our identity together from moment to moment. This makes it a radically different phenomenon from computer memory. It flows not only through the mind, but through the emotions, the senses, the body. We remember things as no computer can — in our muscles and reflexes: how to swim, play an instrument, use a tool. — Theodore Roszak

319. Computers allow you to make more mistakes faster than any other invention in human history with the possible exception of handguns and tequila. — Mitch Ratcliffe

320. Computers are composed of nothing more than logic gates stretched out to the horizon in a vast numerical irrigation system. — Stan Augarten

321. Computers are good at following instructions, but not at reading your mind. — Donald Knuth

322. Computers are incredibly fast, accurate, and stupid. Human beings are incredibly slow, inaccurate, and brilliant. Together they are powerful beyond imagination. — Albert Einstein

323. Computers are like bikinis. They save people a lot of guesswork. — Sam Ewing

324. Computers are like Old Testament gods; lots of rules and no mercy. — Joseph Campbell

325. Computers are magnificent tools for the realization of our dreams, but no machine can replace the human spark of spirit, compassion, love, and understanding. — Louis Gerstner

326. Computers are merely ingenious devices to fulfill unimportant functions. The computer revolution is an explosion of nonsense. — Neil Postman

327. Computers are obstinate about precision. Miss a period here or a semicolon there, and you’ll get

328. pistachios instead of caviar every time.

n Bill Weinman

329. Computers are to computing as instruments are to music. Software is the score whose interpretations amplifies our reach and lifts our spirits. Leonardo da Vinci called music the shaping of the invisible, and his phrase is even more apt as a description of software. — Alan Kay

330. Computers are useless. They can only give you answers. — Pablo Picasso

331. Computers as we know them today will a) be boring, and b) disappear into things that are first and foremost something else: smart nails, self-cleaning shirts, driverless cars, therapeutic Barbie dolls, intelligent doorknobs that let the Federal Express man in and Fido out, but not 10 other dogs back in. Computers will be a sweeping yet invisible part of our everyday lives: We’ll live in them, wear them, even eat them. — Nicholas Negroponte, December 1998

332. Computers can figure out all kinds of problems, except the things in the world that just don’t add up. — James Magary

333. Computers do not solve problems, they execute solutions. — Laurent Gasser

334. Computers don’t die, they password away. — Rodolfo A. Frino

335. Computers don’t introduce order anywhere as much as they expose opportunities. — Alan Perlis

336. Computers have enabled people to make more mistakes faster than almost any invention in history, with the possible exception of tequila and hand guns. — Carl Gundlach

337. Computers make it easier to do a lot of things, but most of the things they make it easier to do don’t need to be done. — Andy Rooney

338. Computers represent a radical novelty in our history. The usual way in which we plan for tomorrow is in yesterday’s vocabulary. By means of metaphors and analogies, we try to link the new to the old, the novel to the familiar. Coping with radical novelty requires an orthogonal method. Coming to grips with a radical novelty amounts to creating and learning a new foreign language that cannot be translated into one’s own mother tongue. Computers embody not one radical novelty but two of them. — Edsger W. Dijkstra

339. Computers shouldn’t be unusable. You don’t need to know how to work a telephone switch to make a phone call, or how to use the Hoover Dam to take a shower, or how to work a nuclear-power plant to turn on the lights. — Scott McNealy

340. Computers will never take the place of books. You can’t stand on a floppy disk to reach a high shelf. — Sam Ewing

341. Computers will start thinking the day they realize we have built them. — Rodolfo A. Frino

342. Computing is not about computers any more. It is about living. — Nicholas Negroponte

343. Computing science is — and will always be — concerned with the interplay between mechanized and human symbol manipulation usually referred to as “computing” and “programming,” respectively. — Edsger W. Dijkstra

344. Considering the current sad state of our computer programs, software development is clearly still a black art, and cannot yet be called an engineering discipline. — Bill Clinton

345. Consistently separating words by spaces became a general custom about the tenth century CE, and lasted until about 1957, when FORTRAN abandoned the practice.

346. Constants aren’t. — John Peers

347. Constraints often boost creativity. — Jim Hugunin

348. Control over computing belongs with users. — Brandt Allen

349. Controlling complexity is the essence of computer programming. — Brian Kernighan

350. Counting in binary is just like counting in decimal if you are all thumbs. — Glaser and Way

351. Counting in octal is just like counting in decimal, if you don’t use your thumbs. — Tom Lehrer

352. Crappy old OSes have value in the basically negative sense that changing to new ones makes us wish we’d never been born. — Neal Stephenson

353. Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn’t really do it, they just saw something. It seemed obvious to them after a while. That’s because they were able to connect experiences they’ve had and synthesize new things. And the reason they were able to do that was that they’ve had more experiences or they have thought more about their experiences than other people. — Steve Jobs

354. Cringley’s Second Law: Ease of use with equivalent performance varies with the square root of the cost of development. That means that to design a computer that’s ten times easier to use would cost 100 times as much. — Robert Cringley

355. Cubicles have become such an icon of nasty workplaces that it’s shocking that the companies who manufacture them still have the chutzpah to pretend that they’re efficient, productive, and pleasant. — Joel Spolsky

356. Custom development is that murky world where a customer tells you what to build, and you say, “are you sure?” and they say “yes,” and you make an absolutely beautiful spec, and say, “is this what you want?” and they say “yes,” and you make them sign the spec in indelible ink, nay, blood, and they do, and then you build that thing they signed off on, promptly, precisely and exactly, and they see it and they are horrified and shocked, and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you’ve gotten yourself into or merely the settlement cost. Or, if you’re really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back. — Joel Spolsky

357. Cutler, armed with a schedule for+finishing+Microsoft+Windows+NT, was urging the team to “eat its own dog food.” Part macho stunt and part common sense, the “dog food diet” was the cornerstone of Cutler’s philosophy. “We’re going to run on the program we build,” he insisted. Eating dog food meant there would be no escape from facing the flaws and imperfections of NT. Even while immersed in his own piece of NT, a code writer would confront all of its weaknesses. By controlling the operations of a code writer’s computer, NT would define the quality of his life. If at first NT tasted no better than dog food, all the better. Code writers would feel an urgent need to raise the dietary level by quickly fixing the errant code and writing more durable code in the first place. — G. Pascal Zachary

358. Cyberspace. A consensual hallucination experienced daily by billions of legitimate operators, in every nation, by children being taught mathematical concepts… A graphic representation of data abstracted from the banks of every computer in the human system. Unthinkable complexity. Lines of light ranged in the nonspace of the mind, clusters and constellations of data. Like city lights, receding… — William Gibson

359. Data does have a problem, in that it’s only available about the past. — Clayton Christensen

360. Data is a lot like humans: It is born. Matures. Gets married to other data, divorced. Gets old. One thing that it doesn’t do is die. It has to be killed. — Arthur Miller

361. Data is not information. Information is not knowledge. Knowledge is not understanding. Understanding is not wisdom. — Gary Schubert

362. Data without generalization is just gossip. — Robert Pirsig

363. Dave, my mind is going. I can feel it. I can feel it. My mind is going. There is no question about it. I can feel it. I can feel it. I can feel it. I’m afraid. — HAL

364. Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You’ve solved the wrong problem. Work hard to improve. — Alan Perlis

365. Debugging is an art that needs much further study. The most effective debugging techniques seem to be those which are designed and built into the program itself — many of today’s best programmers will devote nearly half of their programs to facilitating the debugging process on the other half; the first half…will eventually be thrown away, but the net result is a surprising gain in productivity. Another good debugging practice is to keep a record of every mistake that is made. Even though this will probably be quite embarrassing, such information is invaluable to anyone doing research on the debugging problem, and it will also help you learn how to reduce the number of future errors. — Donald Knuth

366. Debugging is twice as hard as writing code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. — Brian Kernighan

367. Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. — Brian W. Kernighan

368. Design and programming are human activities; forget that and all is lost. — Bjarne Stroustrup

369. Designers must do two seemingly contradictory things at the same time: They must design for perfection, and they must design as though errors are inevitable. And they must do the second without compromising the first. — Bob Colwell

370. Designers talk and think a lot like science fiction writers do, except in a much less melodramatic and histrionic way. — Bruce Sterling

371. Despite many assertions to the contrary, the brain is not “like a computer.” Yes, the brain has many electrical connections, just like a computer. But at each point in a computer only a binary decision can be made: yes or no, on or off, 0 or 1. Each point in the brain, each brain cell, contains all the genetic information necessary to reproduce the entire organism. A brain cell is not a switch. It has a memory; it can be subtle. Each brain cell is like a computer. The brain is like a hundred billion computers all connected together. It is impossible to understand because it is too complex. As Emerson Pugh wrote, “If the human brain was so simple that we could understand it, we would be so simple that we couldn’t.” — Jean M. Goodwin

372. Despite their reputation for thick-headedness or stubbornness, it is important for technicians to see themselves as superior people who can easily adapt to change. — Taiichi Ohno

373. Development is maintenance. — Brian Marick

374. Distributed file systems are a cruel hoax. — Zalman Stern

375. Divide each difficulty into as many parts as is feasible and necessary to resolve it. — Rene Descartes

376. Do not assume more variables than necessary. — William of Occam

377. Do not expose your LaserWriter to fire or intense heat. — Apple LaserWriter manual

378. Do not look into the laser with remaining eye! — Warning message on the side of laboratory laser

379. Do only what only you can do. — Edsger W. Dijkstra

380. Do what you think is interesting, do something that you think is fun and worthwhile, because otherwise you won’t do it well anyway. — Brian Kernighan

381. Documentation is like sex; when it’s good, it’s very, very good, and when it’s bad, it’s better than nothing. — Dick Brandon

382. Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits. — Alan Perlis

383. Documentation is not understanding, process is not discipline, formality is not skill. — Jim Highsmith

384. Documentation is the castor oil of programming. — Gerald Weinberg

385. Doing linear scans over an associative array is like trying to club someone to death with a loaded Uzi. — Larry Wall

386. Doing more things faster is no substitute for doing the right things. — Stephen R. Covey

387. Doing research on the Web is like using a library assembled piecemeal by pack rats and vandalized nightly. — Roger Ebert

388. Don’t anthropomorphize computers. They don’t like it. — Stefan Chakerian

389. Don’t blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for “the average programmer.” You must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. — Edsger Dijkstra

390. Don’t fix bugs later; fix them now. — Steve Maguire

391. Don’t get suckered in by the comments — they can be terribly misleading: Debug only the code. — Dave Storer

392. Don’t have good ideas if you aren’t willing to be responsible for them. — Alan Perlis

393. Don’t include a sentence in documentation if its negation is obviously false. — Bob Martin, AT&T

394. Don’t keep “trying” solutions until you find one that works. Take the time to find the correct solution. — Steve Maguire

395. Don’t worry about what anybody else is going to do. The best way to predict the future is to invent it. Really smart people with reasonable funding can do just about anything that doesn’t violate too many of Newton’s Laws. — Alan Kay

396. Don’t worry, be crappy. Revolutionary means you ship and then test… Lots of things made the first Mac in 1984 a piece of crap — but it was a revolutionary piece of crap. — Guy Kawasaki

397. Don’t you hate code that’s not properly indented? Making indenting part of the syntax guarantees that all code is properly indented. — Guido van Rossum

398. Doom should be an Olympic sport. — Dave Goldberger

399. DOS computers manufactured by companies such as IBM, Compaq, Tandy, and millions of others are by far the most popular, with about 70 million machines in use worldwide. Macintosh fans, on the other hand, may note that cockroaches are far more numerous than humans, and that numbers alone do not denote a higher life form. — New York Times, November 26, 1991

400. During a code review, when I asked why (besides the source control file headers) there was not a comment in 240,000 lines of code which was getting handed over to me for maintenance, the programmer replied, “I’m terse.” — Samuel Stoddard

401. Each new user of a system uncovers a new class of bugs. — Brian Kernighan

402. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice. — Christopher Alexander

403. Editing is a rewording activity. — Alan Perlis

404. Eiffel borrows quite heavily from some earlier programming languages and I am sure that if we had found a good programming construct in C we would have used it as well. — Bertrand Meyer

405. Einstein argued that there must be simplified explanations of nature, because God is not capricious or arbitrary. No such faith comforts the software engineer. — Fred Brooks

406. Elegance is not a dispensable luxury but a factor that decides between success and failure. — Edsger Dijkstra

407. EMACS could not have been reached by a process of careful design, because such processes arrive only at goals which are visible at the outset, and whose desirability is established on the bottom line at the outset. Neither I nor anyone else visualized an extensible editor until I had made one, nor appreciated its value until he had experienced it. EMACS exists because I felt free to make individually useful small improvements on a path whose end was not in sight. — Richard Stallman

408. Encapsulate the concept that varies — Erich Gamma

409. Encryption is a powerful defensive weapon for free people. It offers a technical guarantee of privacy, regardless of who is running the government. It’s hard to think of a more powerful, less dangerous tool for liberty. — Esther Dyson

410. Engineering conveys an image of bridge or building construction. Software engineering is therefore a metaphor for how software should be constructed, that is, in a manner analogous to constructing a physical structure. Formalists love this metaphor, but object advocates find it counterproductive. A better metaphor for assembling objects to collectively perform tasks is theater. — David West

411. Engineering is not merely knowing and being knowledgeable, like a walking encyclopedia; engineering is not merely analysis; engineering is not merely the possession of the capacity to get elegant solutions to non-existent engineering problems; engineering is practicing the art of the organized forcing of technological change. Engineers operate at the interface between science and society. — Dean Gordon Brown

412. Engineering is the conscious application of science to the problems of economic production. — H. P. Gillette

413. EngineeringFinding the balance between what is technically feasible and what is economically acceptable. — DeGarmo, Sullivan and Bontadelli

414. Error, no keyboard detected, press F1 to continue — Motherboard error message

415. Errors using inadequate data are much less than those using no data at all. — Charles Babbage

416. Even the humble everyday ATM does not really diagnose and repair itself. It demands a largely hidden staff of technicians, some of whom are paid four times as much as bank tellers. — Edward Tenner

417. Even the word “users” is an artifact of the [command-and-control] mentality. — Christopher Locke

418. Even under the assumption of flawlessly working machines we should ask ourselves the questions: “When an automatic computer produces results why do we trust them, if we do so?” and after that: “What measures can we take to increase our confidence that the results produced are indeed the results intended?” — Edsger Dijkstra

419. Even when you have skilled, motivated, hard-working people, the wrong team structure can undercut their efforts instead of catapulting them to success. A poor team structure can increase development time, reduce quality, damage morale, increase turnover, and ultimately lead to project cancellation. — Steve McConnell

420. Every decision a person makes stems from the person’s values and goals. People can have many different goals and values; fame, profit, love, survival, fun, and freedom, are just some of the goals that a good person might have. When the goal is to help others as well as oneself, we call that idealism. — Richard Stallman

421. Every great mistake has a halfway moment, a split second when it can be recalled and perhaps remedied. — Pearl Buck

422. Every language has its partisans, usually among folks deeply immersed in their particular theology, triumphant in having divined the inner meaning of some esoteric operations, like a medieval Jesuit hot on the trail of the final ontological proof, whose conciseness in solving a single problem makes them almost swoon with ecstacy at the expected savings of many keystrokes, as if those very keystrokes represented a lot of heavy lifting and hauling on their part. — John Holmgren

423. Every once in a while, you just have to go down to the native code to really feel like a real programmer. Those garbage collections and bytecode verifications are all great, but it’s just not so fun to live in an environment where you can’t even shoot yourself. — Kohsuke Kawaguchi

424. Every operating system out there is about equal. We all suck. — Brian Valentine, Microsoft

425. Every piece of software written today is likely going to infringe on someone else’s patent. — Miguel de Icaza

426. Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. — Jamie Zawinski

427. Every program has (at least) two purposes; the one for which it was written and another for which it wasn’t. — Alan Perlis

428. Every program is a part of some other program and rarely fits. — Alan Perlis

429. Every program starts off with bugs. Many programs end up with bugs as well. There are two corollaries to this: first, you must test all your programs straight away. And second, there’s no point in losing your temper every time they don’t work. — Z80 Users Manual

430. Every time I write about the impossibility of effectively protecting digital files on a general purpose computer, I get responses from people decrying the death of copyright. “How will authors and artists get paid for their work?” they ask me. Truth be told, I don’t know. I feel rather like the physicist who just explained relativity to a group of would-be interstellar travelers, only to be asked, “How do you expect us to get to the stars, then?” I’m sorry, but I don’t know that, either. — Bruce Schneier

431. Every time we’ve moved ahead in IBM, it was because someone was willing to take a chance, put his head on the block, and try something new. — Thomas J. Watson

432. Everything really interesting that happens in software projects eventually comes down to people. — James Bach

433. Everything should be built top-down, except the first time. — Alan Perlis

434. Exceptions relieve the programmer of tediously writing boilerplate code — without removing the semantics of said code — and they allow the programmer to arrange the code so that error handling code is more separate from the main program logic. — Herb Sutter

435. Exploratory testing can be described as a martial art of the mind. It’s how you deal with a product that jumps out from the bushes and challenges you to a duel of testing. Well, you don’t become a black belt by reading books. You have to work on it. — James Bach

436. False confidence comes from running tens of thousands of tests, most of which won’t find bugs. Like it or not, we tend to be impressed by test quantities rather than quality. Even experienced testers get impressed. You can’t test for 1000+ years, so you knock off a few billion tests over the next several months. But the tests you ran represent a statistically insignificant portion of the input space and no confidence, statistical or otherwise, is warranted. — Boris Beizer

437. Fancy algorithms are slow when N is small, and N is usually small. — R. Pike

438. Fancy optimizers have fancy bugs. — R. Pike

439. Fast, fat computers breed slow, lazy programmers. — Robert Hummel

440. Few companies that installed computers to reduce the employment of clerks have realized their expectations. They now need more, and more expensive clerks even though they call them “operators” or “programmers.” — Peter F. Drucker

441. Few influential people involved with the Internet claim that it is a good in and of itself. It is a powerful tool for solving social problems, just as it is a tool for making money, finding lost relatives, receiving medical advice, or, come to that, trading instructions for making bombs. — Esther Dyson

442. Few people request influence when their world is behaving rationally. As a result, consultants tend to see more than their fair share of irrationality. — Gerald M. Weinberg,

443. Fifty years into the First Computing Era some of us in the computing arena have come to realize we’ve made a false start, and for us to finally be able to produce lasting, correct, beautiful, usable, scalable, enjoyable software that stands the tests of time and moral human endeavor, we need to start over. — Richard P. Gabriel

444. Fifty years of programming language research, and we end up with C++ ? — Richard A. O’Keefe

445. Fig Newton: The force required to accelerate a fig 39.37 inches/second. — J. Hart

446. Find something you’re passionate about and keep tremendously interested in it. — Julia Child

447. Finding a way to reduce the number of testers and the perpetual excuse that nothing can be done because it’s a testing hit is a good idea. The current system is not going to scale and we will soon be at the point that nothing can get done because it can’t be tested. — Dave Cutler

448. First law of Bad Management: If something isn’t working, do more of it. — Tom DeMarco

449. First learn computer science and all the theory. Next develop a programming style. Then forget all that and just hack. — George Carrette

450. First we thought the PC was a calculator. Then we found out how to turn numbers into letters with ASCII : and we thought it was a typewriter. Then we discovered graphics, and we thought it was a television. With the World Wide Web, we’ve realized it’s a brochure. — Douglas Adams

451. First you listen to the users; then you ignore them. — Ken Arnold

452. Fixing fresh bugs is easier than fixing old ones. It’s usually fairly quick to find a bug in code you just wrote. When it turns up you often know what’s wrong before you even look at the source, because you were already worrying about it subconsciously. Fixing a bug in something you wrote six months ago (the average case if you release once a year) is a lot more work. And since you don’t understand the code as well, you’re more likely to fix it in an ugly way, or even introduce more bugs. When you catch bugs early, you also get fewer compound bugs. Compound bugs are two separate bugs that interact: you trip going downstairs, and when you reach for the handrail it come off in your hand. In software this kind of bug is the hardest to find, and also tends to have the worst consequences. The traditional “break everything and then filter out the bugs” approach inherently yields a lot of compound bugs. And software released in a series of small chances inherently tends not to. The floors are constantly being swept clean of any loose objects that might later get stuck to something. — Paul Graham

453. Foolproof systems don’t take into account the ingenuity of fools. — Gene Brown

454. Fools ignore complexity. Pragmatists suffer it. Experts can avoid it. Geniuses remove it. — Alan Perlis

455. For 250 packages each of which can be in 100 states, and assuming 100 test cases per set-up, executed at 100 tests per second we have almost twenty years of testing. If you take the load order of the programs into account, multiply the above by about 1017 for a mere 107 universe lifetimes. The combinatorics are awful and whatever testing you do, is a statistically insignificant sample of the realm of possibilities. You don’t do configuration compatibility testing because you really can’t and because attempting to do it just leads to false confidence. — Boris Beizer

456. For a long time it puzzled me how something so expensive, so leading edge, could be so useless, and then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match. — Bill Bryson

457. For me, the first challenge for computing science is to discover how to maintain order in a finite, but very large, discrete universe that is intricately intertwined. And a second, but not less important challenge is how to mold what you have achieved in solving the first problem, into a teachable discipline. It does not suffice to hone your own intellect (that will join you in your grave), you must teach others how to hone theirs. The more you concentrate on these two challenges, the clearer you will see that they are only two sides of the same coin. Teaching yourself is discovering what is teachable. — Edsger W. Dijkstra

458. For systems, the analogue of a face-lift is to add to the control graph an edge that creates a cycle, not just an additional node. — Alan Perlis

459. For the first objective, note that most of the code (e.g., 75%) concerns low probability but potentially harmful situations. In a statistical sense, much of the code is fundamentally unrealistic. As testers, we must test every line of code (or see to it that someone has done it). That means exercising many conditions that are unlikely to come up in any one user’s experience. The programmer who protests that we’re being unrealistic is contradicting herself because much of her code is “unrealistic” in the same sense. Another reason for using “unrealistic” tests is that realistically, that’s often the only way to force certain low probability timing and race conditions to which our software must be invulnerable. — Boris Beizer

460. For the time being, programming is a consumer job, assembly line coding is the norm, and what little exciting stuff is being performed is not going to make it compared to the mass-marketed crap sold by those who think they can surf on the previous half-century’s worth of inventions forever. — Eric Naggum

461. For us scientists it is very tempting to blame the lack of education of the average engineer, the shortsightedness of the managers, and the malice of the entrepreneurs for this sorry state of affairs, but that won’t do. You see, while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy. — Edsger W. Dijkstra

462. FORTRAN was the language of choice for the same reason that three-legged races are popular. — Ken Thompson

463. FORTRAN, the infantile disorder, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. — Edsger Dijkstra, circa 1970

464. Frequently, crashes are followed with a message like “ID 02.” “ID” is an abbreviation for idiosyncrasy and the number that follows indicates how many more months of testing the product should have had. — Guy Kawasaki

465. Fresh software is like a box of chocolates, testers never know what they are going to get. — John Littlejohn

466. Friends don’t let friends do capture-replay. — Harry Robinson

467. From a practical viewpoint, it’s easy to see that C will always be with us, taking a place beside Fortran and Cobol as the right tool for certain jobs. — Larry O’Brien

468. From a programmer’s point of view, the user is a peripheral that types when you issue a read request. — P. Williams

469. Functions delay binding; data structures induce binding. Moral: Structure data late in the programming process. — Alan Perlis

470. Furthermore, test tools by themselves have no long-term viability unless they become part of a comprehensive software development environment. Development tool vendors have realized this and have turned their attention to test tools. Tool vendors are merging, being bought, or going out of business. — Boris Beizer

471. Gates has always understood Moore’s Law better than anyone else in the industry. If you can make something run at all, get it out there — it may be slow and clunky, but hardware improvements will bail you out. If you wait until it’s running perfectly on the hardware already in the field, it will be obsolete before it’s released. This philosophy built Microsoft and is the main reason Microsoft won the war IBM declared back in the OS/2 days. — Jerry Pournelle

472. Gather some statistics on your beta test effort and do some cost justification for it (true total cost) and then determine if the effort is worth continuing or if the money is better spent on beefing up inspections, unit testing, and in-house system testing. — Boris Beizer

473. Geeks like to think that they can ignore politics, you can leave politics alone, but politics won’t leave you alone. — Richard Stallman

474. Getting information off the Internet is like taking a drink from a fire hydrant. — Mitchell Kapor

475. Given enough eyeballs, all bugs are shallow; e.g., given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. — Eric Raymond

476. Giving a man space is like giving a dog a computer: the chances are he will not use it wisely. — Bette-Jane Raphael

477. Giving the Linus Torvalds Award to the Free Software Foundation is a bit like giving the Han Solo Award to the Rebel Alliance. — Richard Stallman

478. Giving up on assembly language was the apple in our Garden of Eden: Languages whose use squanders machine cycles are sinful. The LISP machine now permits LISP programmers to abandon bra and fig-leaf. — Alan Perlis

479. Going from programming in Pascal to programming in C, is like learning to write in Morse code. — J.P. Candusso

480. Good code is its own best documentation. As you’re about to add a comment, ask yourself, ‘How can I improve the code so that this comment isn’t needed?’ Improve the code and then document it to make it even clearer. — Steve McConnell

481. Good engineering doesn’t consist of random acts of heroism. — Harry Robinson

482. Good engineering is the difference between code running in eight minutes or eight hours. It affects real people in real ways. It’s not a “matter of opinion,” any more than a bird taking a flight is a “matter of opinion.” — H. W. Kenton

483. Good programmers know what to write. Great ones know what to use. — Eric Raymond

484. Good programmers know what’s beautiful and bad ones don’t. — David Gelernter

485. Good software, like wine, takes time. — Joel Spolsky

486. Google confuses me; if you search for “michael hudson” my page is the third hit — but my name doesn’t actually appear anywhere on the linked page! The “did you mean to search for…” feature is also downright uncanny. They’ve clearly sold their souls to the devil — there’s no other explanation. — Michael Hudson

487. Goto, n.: A programming tool that exists to allow structured programmers to complain about unstructured programmers. — Ray Simard

488. Great software requires a fanatical devotion to beauty. If you look inside good software, you find that parts that no one is ever supposed to see are beautiful too. I’m not claiming I write great software, but I know that when it comes to code I behave in a way that would make me eligible for prescription drugs if I approached everyday life the same way. It drives me crazy to see code that’s badly indented, or that used ugly variable names. — Paul Graham

489. Habitability is the characteristic of source code that enables programmers coming to the code later in its life to understand its construction and intentions and to change it comfortably and confidently… Software needs to be habitable because it always has to change… Programs are written and maintained, bugs are fixed, features are added, performance is tuned, and a whole variety of changes are made both by the original and new programming team members… What is important is that it be easy for programmers to come up to speed with the code, to be able to navigate through it effectively, to be able to understand what changes to make, and to be able to make them safely and correctly. — Richard Gabriel

490. Hacking is the art of fixing program bugs without knowing what you’re doing. — Rodolfo A. Frino

491. Handle your special cases just once. — Steve Maguire

492. Hard Drive: The part of the computer that stops working when you spill beer on it. — Dave Barry

493. Hardwarethe parts of a computer that can be kicked. — Jeff Pesis

494. Haven’t we all been taught that good software is defensive; that good software defends itself against the vagaries of input errors? The question is what are we defending against? If we look at much of contemporary software we find low-level internal routines that have no direct interface with the outside world (users, for example) protecting themselves against the vagaries of potentially harmful internally generated data. That’s programming under the assumption that your fellow programmer is a fool at best or a cad at worst. That’s programming under the assumption that there is no effective process; that there are no inspections; that there hasn’t been any effective unit testing. Programming in order to cover your ass and fix blame rather than in order to fix problems. The trouble with this kind of code is that there are so many idiosyncratic notions of danger that there’s no way to test that code. — Boris Beizer

495. He who spends his time reading aphorisms of another to have one of his own, has no time or brains to have any of his own. — M. Bernheisel

496. Here are terms to beware of: “fool-proof” or “idiot-proof” — oh, you mean you think your customers are fools or idiots?; “user-friendly” — which usually means to hold users by the hand and force them to do things one step at a time, in prescribed order, whether they like it or not; and “intuitive” — which in actuality means so automatic it is not conscious, but those who use the term forget that almost everything we call intuitive, such as walking or using a pencil took years of practice. — Don Norman

497. Here’s to the crazy ones. The misfits. The rebels. The troublemakers. The round heads in the square holes. The ones who see things differently. They’re not fond of rules. You can quote them. Disagree with them. Glorify or vilify them. But the only thing you can’t do is ignore them. Because they change things. They push the human race forward. And while some may see them as the crazy ones, we see genius. Because the people who are crazy enough to think they can change the world, are the ones who do. — Apple Computer advertisement

498. Heresy! Beta testing seems to be firmly entrenched as the last bastion against rampaging bugs. Beta testing assures that bad bugs don’t get to the user. Lets see an alternate view of beta testing. Beta testing is effective only when the internal testing isn’t. Some major players in the software game have learned that with good internal unit testing, good integration testing, and thorough in- house system testing, that the bugs found by beta testing aren’t worth the cost of administrating a beta test effort even if the “testers” work unpaid. Beta testing isn’t free. You have to ship them the software. You have to provide above normal support at no cost to them. You have to have enough additional ports to handle the load. If the software is well tested, beta testers don’t find much that your own testers and programmers haven’t found earlier. Furthermore, they report hundreds of symptoms for the same bug and it’s a big job to correlate all those trouble reports and find out that you’ve been talking about the same bug that has long ago been scheduled for repair. — Boris Beizer

499. Hitting your modem with an aluminum baseball bat is only going to get you electrocuted. Try a wooden one. — Lynn Marshall

500. Hoaxes use weaknesses in human behaviour to ensure they are replicated and distributed. In other words, hoaxes prey on the Human Operating System. — Stewart Kirkpatrick

501. Home computers are being called upon to perform many new functions, including the consumption of homework formerly eaten by the dog. — Doug Larson

502. How can you be just like a real techie? Frequently use the word “irrelevant,” but never spell it correctly. Try “irrelivant,” “irelivent,” and “irrevelant” to start with, but be sure to develop your own sub-literate variations for extra coolness! — Jeffrey Carl

503. How could this Y2K be a problem in a country where we have Intel and Microsoft? — Al Gore

504. How does a project get to be a year late? — One day at a time. — Fred Brooks

505. How good the design is doesn’t matter near as much as whether the design is getting better or worse. If it is getting better, day by day, I can live with it forever. If it is getting worse, I will die. — Kent Beck

506. How rare it is that maintaining someone else’s code is akin to entering a beautifully designed building, which you admire as you walk around and plan how to add a wing or do some redecorating. More often, maintaining someone else’s code is like being thrown headlong into a big pile of slimy, smelly garbage. — Bill Venners

507. Human beings are not accustomed to being perfect, and few areas of human activity demand it. If one program character, one pause of the incantation is not strictly in proper form, the magic doesn’t work. Adjustment to the requirement for perfection is, I think, the most difficult part of learning to program. — Frederick Brooks

508. Humans are allergic to change. They love to say, “We’ve always done it this way.” I try to fight that. That’s why I have a clock on my wall that runs counter-clockwise. — Grace Hopper

509. Humor is incongruity in action. The universe is incongruous. Humor is therefore the best expression of the truth underlying the universe. — Stanley Bing

510. I always leave the most controversial to last. I don’t believe in independent test groups and I never have, despite the fact that I have at times pushed it very hard and have often fought for it (sometimes without success). Independent test groups are an immature phase in the evolution of the software development process through which most organizations must go. I don’t believe in independent test groups because I don’t believe in testing. Testing is quality control. It finds bugs after they’ve been put in. As a long-term goal, we must strive to avoid or prevent the bugs, not just find them and fix them. I don’t believe in testing because every time a test reveals a bug, that’s one more opportunity to prevent a bug that we somehow missed. We will keep on finding and deploying better bug prevention methods, but as we do, we’ll also keep building more complicated and subtler software with even subtler bugs that demand, in turn, even more powerful test methods. So while I don’t believe in testing, I also believe that some kind of testing will always be with us. — Boris Beizer

511. I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don’t, and the spirit of the passionate intellect that has tied them together, or tried. That’s why programming — or buying software — on the basis of “lists of features” is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess. — Ted Nelson

512. I am a hard-core believer that the clean desktop is the way to go… At the same time, we told OEMs that if they were going to put a bunch of icons on the desktop, then so were we. — Jim Allchin

513. I am not the only person who uses his computer mainly for the purpose of diddling with his computer. — Dave Barry

514. I am one of the culprits who created the Y2K problem. I used to write those programs back in the ’60s and ’70s, and was so proud of the fact that I was able to squeeze a few elements of space by not having to put ‘19’ before the year. — Alan Greenspan

515. I am only a footnote, but proud of the footnote I have become. My subsequent work — on eliciting principles and developing the theory of interface design, so that many people will be able to do what I did — is probably also footnote-worthy. In looking back at this turn-of-the-century period, the rise of a worldwide network will be seen as the most significant part of the computer revolution. — Jef Raskin

516. I am sometimes something of a lazy person, so when I end up spending a lot of time using something myself — as I did with Google in the earliest of days, I knew it was a big deal. — Sergey Brin, Google

517. I believe the hard part of building software is the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems. — Frederick P. Brooks, Jr.

518. I can see computers everywhere — except in the productivity statistics. — Robert Solow

519. I cannot imagine any condition which would cause this ship to founder. Modern shipbuilding has gone beyond that. — E. J. Smith, Captain of the Titanic

520. I chose C as a base for my work because I needed something that allowed me to express the machine fairly directly. And machines are things with addresses and sequences of objects. Unless you can do efficient operations on that, you’re sunk. — Bjarne Stroustrup

521. I code therefore I exist — somewhere between Heaven and HTML. — Ad Hales

522. I consider C++ the most significant technical hazard to the survival of your project and do so

523. without apologies. — Alistair Cockburn

524. I consider it the obligation of scientists and intellectuals to ensure that their ideas are made accessible and thus useful to society instead of being mere playthings for specialists. — Bjarne Stroustrup

525. I do not fear computers. I fear the lack of them. — Isaac Asimov

526. I don’t believe in testing. Testing is quality control. It finds bugs after they’ve been put in. As a long-term goal, we must strive to avoid or prevent the bugs, not just find them and fix them. I don’t believe in testing because every time a test reveals a bug, that’s one more opportunity to prevent a bug that we somehow missed. We will keep on finding and deploying better bug prevention methods, but as we do, we’ll also keep building more complicated and subtler software with even subtler bugs that demand, in turn, even more powerful test methods. So while I don’t believe in testing, I also believe that some kind of testing will always be with us. — Boris Beizer

527. I don’t do feelings, I’ll leave that to Barry Manilow. — Scott McNealy, CEO, Sun Microsystems

528. I don’t know what percentage of our time on any computer-based project is spent getting the equipment to work right, but if I had a gardener who spent as much of her time fixing her shovel as we spend fooling with our computers, I’d buy her a good shovel. — Erasmus Smums

529. I don’t think there’s anything unique about human intelligence. All the neurons in the brain that make up perceptions and emotions operate in a binary fashion. — Bill Gates

530. I enjoy…looking at charts about what sites are getting the most traffic. Everyone else always looks at the top of the chart. I always look at the bottom because the bottom is where the opportunity is. You’re not going to compete with Yahoo and Netscape at the top. It’s the bottom where the opportunity is. — Michael Robertson, CEO of MP3.com in an interview with CNET News.

531. I fear the new object-oriented systems may suffer the fate of LISP, in that they can do many things, but the complexity of the class hierarchies may cause them to collapse under their own weight. — Bill Joy

532. I find languages that support just one programming paradigm constraining. — Bjarne Stroustrup

533. I find sitting at a specially equipped desk in front of some pretty ugly plastics and staring at a little window is a very unnatural event. — Harold Hambrose

534. I find this a nice feature but it is not according to the documentation. Or is it a bug? Let’s call it an accidental feature. — Larry Wall

535. I get into the meanest, nastiest frame of mind I can manage, and I write the nastiest-testing code I can think of. Then I turn around and embed that in even nastier constructions that are nearly obscene. — Donald Knuth

536. I have a friend who told me that the very best computer system ever built by mankind was by the Druids at Stonehenge. Well, that’s an old story. But what I liked was that he felt the Druids didn’t die out, they just went bankrupt trying to debug the software. — J. Finke

537. I have an almost religious zeal.. not for technology per se, but for the Internet which is for me, the nervous system of mother Earth, which I see as a living creature, linking up. — Dan Millman

538. I have no comments on C# as a language. It will take a lot to persuade me that the world needs yet another proprietary language (YAPL). It will be especially hard to persuade me that it needs a language that is closely integrated with a specific proprietary operating system. If you want to write exclusively for the .Net platform, C# isn’t the worst alternative, but remember that C++ is a strongly supported — though less strongly hyped — alternative on that platform. — Bjarne Stroustrup

539. I have stopped reading Stephen King novels. Now I just read C code instead. — Richard O’Keefe

540. I have traveled the length and breadth of this country and talked with the best people, and I can assure you that data processing is a fad that won’t last out the year. — The editor in charge of business books for Prentice Hall, 1957

541. I invented the term “Object-Oriented,” and I can tell you I did not have C++ in mind. — Alan Kay

542. I just want to go on the record as being completely opposed to computer languages. Let them have their own language and soon they’ll be off in the corner plotting with each other! — Steven D. Majewski

543. I knew I’d hate COBOL the moment I saw they’d used “perform” instead of “do.” — Larry Wall

544. I like having a machine called “elvis” on the network because that way, I can say “ping elvis” and have it come back with “elvis is alive.” — Carl Shipley

545. I like to remind my team that ultimately we ship products, not specs and design documents, so we need to remember the end game. — Ron Soukup

546. I like writing code, more than I like writing text. Writing code provides instant gratification. There’s a feedback that you can’t get from writing text. And there’s more objective criteria. You can look at the size of the code, the speed of the code, the cleanliness of the code structure. It is really obvious. That’s great. — Bjarne Stroustrup

547. I liken starting one’s computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act. — Ken Pier

548. I looked up “standard” in the dictionary. There are eleven different definitions. — Dave Winer

549. I maintain that programming cannot be done in less than three-hour windows. It takes three hours to spin up to speed, gather your concentration, shift into “right brain mode,” and really focus on a problem. Effective programmers organize their day to have at least one three-hour window, and hopefully two or three. This is why good programmers often work late at night. They don’t get interrupted as much… — Ole Eichhorn

550. I prefer (all things being equal) regularity/orthogonality and logical syntax/semantics in a language because there is less to have to remember. (Of course I know all things are NEVER really equal!) — Guido van Rossum

551. I realized that my prior projects were just finger warm-ups. Now I have to tackle complexity itself. But it took long, before I had assembled the courage to do so. — Edsger W. Dijkstra

552. I regularly read Internet user groups filled with messages from people trying to solve software incompatibility problems that, in terms of complexity, make the U.S. Tax Code look like Dr. Seuss. — Dave Barry

553. I see design standards that don’t tell you how to come up with a good design — only how to write it down, employee evaluation standards that don’t help you build meaningful long-term relationships with staff, testing standards that don’t tell you how to invent a test that is worth running. — Tom DeMarco

554. I tell people to start implementing when they are pretty sure there aren’t more important stories out there. An iteration’s worth of data is worth months of speculation. — Kent Beck

555. I think all languages start as “firebrands” wielding their “simplicity” as weapons aganst the “horribly complex legacy languages.” Once reality sets in, the new languages mature by acquiring facilities and complexities equivalent to other successful languages. This has happened for every successful language…and for a few unsuccessful ones. — Bjarne Stroustrup

556. I think another good principle is separating presentation or user interface (UI) from the real essence of what your app is about. By following that principle I have gotten lucky with changes time and time again. So I think that’s a good principle to follow. — Martin Fowler

557. I think complexity is mostly sort of crummy stuff that is there because it’s too expensive to change the interface. — Jaron Lanier

558. I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We’ve created life in our own image. — Stephen W. Hawking

559. I think conventional languages are for the birds. They’re just extensions of the von Neumann computer, and they keep our noses in the dirt of dealing with individual words and computing addresses, and doing all kinds of silly things like that, things that we’ve picked up from programming for computers; we’ve built them into programming languages; we’ve built them into Fortran; we’ve built them in PL/1; we’ve built them into almost every language. — John Backus

560. I think it is inevitable that people program poorly. Training will not substantially help matters. We have to learn to live with it. — Alan Perlis

561. I think it would be pretty bizarre if OS/2 finds any popularity. — Bill Gates

562. I think it’s fair to say that personal computers have become the most empowering tool we’ve ever created. They’re tools of communication, they’re tools of creativity, and they can be shaped by their user. — Bill Gates

563. I think of software projects as journeys into the uncertain. As we begin we may not know exactly what we are to build, we may not know what is the most appropriate technology to build it with, and we are very unsure of how long a journey we will take. The odd thing is that many people are very certain of when we will be done. The deadline is very often set before the system is specified. — Tim Lister

564. I think that computer science in its middle age has become incestuous: people are trained by people who think one way. — Ken Thompson

565. I think that it’s extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don’t think we are. I think we’re responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. — Alan Perlis

566. I think that the most beautiful thing lately hasn’t been in hardware or software per se but collaboration — the idea behind Napster, which uses the distributed power of the Internet as its engine. — Steven Levy

567. I think the world is run by C students. — Al McGuire

568. I think there certainly was a milestone in the ’90s with regards to the Internet achieving critical mass. There were several magical factors that came together: the creation of HTML by Tim Berners-Lee, the drop in the price of communications, and all the PCs out there that you could put this software into. — Bill Gates

569. I thought when I went to college I would be a music major. I played saxophone, but then the tuba player got into an accident and I became a tuba player. I arranged a piece for band that combined all kinds of themes off TV shows — Dragnet, Howdy Doody Time, and Bryl Cream. I knew nothing about copyright law. — Donald Knuth

570. I took the classic approach to software development:

1. encounter a bug

2. blame the tool

3. post to the mailing list and complain about it

4. read the docs

5. find own mistake and crawl back into my corner — Ralph Scheuer

571. I used to program my IBM PC to make hideous noises to wake me up. I also made the conscious decision to hard-code the alarm time into the program, so as to make it more difficult for me to reset it. After I realised that I was routinely getting up, editing the source file, recompiling the program and rerunning it for 15 minutes extra sleep, before going back to bed, I gave up and made the alarm time a command-line option. — B. M. Buck

572. I view the landslide of C use in education as something of a calamity. — Nicklaus Wirth

573. I want to put a ding in the universe. — Steve Jobs

574. I was eventually persuaded of the need to design programming notations so as to maximize the number of errors which cannot be made, or if made, can be reliably detected at compile time. — Charles Anthony Richard Hoare

575. I would therefore like to posit that computing’s central challenge, “How not to make a mess of it,” has not been met. On the contrary, most of our systems are much more complicated than can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. — Edsger Dijkstra

576. IBMIt may be slow, but it’s hard to use. — Andrew Tannenbaum

577. I’d rather write programs to write programs than write programs. — Dick Sites, DEC

578. I’d say that of the world’s economies, there’s more that believe in intellectual property today than ever. There are fewer communists in the world today than there were. There are some new modern-day sort of communists who want to get rid of the incentive for musicians and moviemakers and software makers under various guises. They don’t think that those incentives should exist. — Bill Gates

579. I’d sit there and first I’d look through the comments, pick through the security holes, and then I’d see what the developer did to fix it because they’d always leave it well commented — thank you very much — and then I’d work back and figure out how I could write exploit code to exploit their vulnerabilities. — Kevin Mitnick

580. If 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself: “Dijkstra would not have liked this,” well that would be enough immortality for me. — Edsger Dijkstra

581. If a listener nods his head when you’re explaining your program, wake him up. — Alan Perlis

582. If a program manipulates a large amount of data, it does so in a small number of ways. — Alan Perlis

583. If buffer overflows are ever controlled, it won’t be due to mere crashes, but due to their making systems vulnerable to hackers. Software crashes due to mere incompetence apparently don’t raise any eyebrows, because no one wants to fault the incompetent programmer and his incompetent boss. — Henry Baker

584. If builders built houses the way programmers build programs, the first woodpecker that came along would destroy civilization. — Gerald M Weinberg

585. If C++ has taught me one thing, it’s this: Just because the system is consistent doesn’t mean it’s not the work of Satan. — Andrew Plotkin

586. If debugging is the process of removing bugs, then programming must be the process of putting them in. — Edsger Dijkstra

587. If I didn’t have my part-time performance art income to help pay the bills, I could never afford to support my programming lifestyle. — Jeff Bauer

588. If I don’t document something, it’s usually either for a good reason, or a bad reason. — Larry Wall

589. If I look into my foggy crystal ball at the future of computing science education, I overwhelmingly see the depressing picture of “business as usual.” The universities will continue to lack the courage to teach hard science; they will continue to misguide the students, and each next stage of the infantilization of the curriculum will be hailed as educational progress. — Edsger W. Dijkstra

590. If it’s there and you can see it — it’s real

591. If it’s not there and you can see it — it’s virtual

592. If it’s there and you can’t see it — it’s transparent

593. If it’s not there and you can’t see it — you erased it! — IBM poster explaining virtual memory 1978

594. If McDonalds were run like a software company, one out of every hundred Big Macs would give you food poisoning — and the response would be, “We’re sorry, here’s a coupon for two more”. — Mark Minasi

595. If moral behavior were simply following rules, we could program a computer to be moral. — Samuel P. Ginder

596. If our designs are failing due to the constant rain of changing requirements, it is our designs that are at fault. We must somehow find a way to make our designs resilient to such changes and protect them from rotting. — Robert C. Martin

597. If patterns of ones and zeros were like patterns of human lives and death, if everything about an individual could be represented in a computer record by a long string of ones and zeros, then what kind of creature would be represented by a long string of lives and deaths? — Thomas Pynchon

598. If programs had multiple ways to think, then they wouldn’t so often get stuck, because they could change their points of view. — Marvin Minsky

599. If QA is effective, the programmers learn from their mistakes and are given the means to correct previous bugs of the same kind and to prevent such bugs in the future. It follows that the techniques used to discover those bugs are no longer as effective because those kinds of bugs no longer exist. Monitoring bug type statistics is an important job for QA. If the statistics are stable (i.e., same kinds of bugs) over several releases, then the programmers aren’t learning or are haven’t been given the means to profit from what they’ve learned. Then, past bug statistics as a basis for test design is a good idea, but only because there’s a major process flaw. The faster the programmers learn and react to bug statistics, the worse a guide will past bug statistics be for test design. — Boris Beizer

600. If software is hard, then hardware should be impenetrable. — Rodolfo A. Frino

601. If software were as unreliable as economic theory, there wouldn’t be a plane made of anything other than paper that could get off the ground. — Jim Fawcette

602. If the code and the comments disagree, then both are probably wrong. — Norm Schryer

603. If the code is smarter than it looks, most people aren’t going to think it looks very smart. — Jeremy Hylton

604. If the cost of testing and analysis is far lower than the expected gain and if you have stable software and valid user profiles, then performance testing is an important part of the toolkit. Its use is widespread in telecommunications, embedded systems, and other system software. Given the heavy capital investment in a performance testing laboratory staffed by experts, this kind of testing can forestall the worst kinds of performance problems met in the field. If throughput issues are meaningful for your application, then you can’t afford not to do this testing. — Boris Beizer

605. If the date is missed, the schedule was wrong. It doesn’t matter why the date was missed. The purpose of the schedule was planning, not goal-setting. — Tom DeMarco

606. If the designers of X-Windows built cars, there would be no fewer than five steering wheels hidden about the cockpit, none of which followed the same principles — but you’d be able to shift gears with your car stereo. Useful feature, that. — Marcus J. Ranum

607. If the Internet is a superhighway, then AOL must be a fleet of farm equipment that straddles five lanes and pays no heed to “Keep Right Except to Pass” signs. — Marko Peric

608. If the network idea should prove to do for education what a few have envisioned, surely the boon to humankind would be beyond measure. Unemployment would disappear from the face of the earth forever, for consider the magnitude of the task of adapting the network’s software to all generations of computer, coming closer and closer upon the heels of their predecessors until the entire population of the world is caught up in an infinite crescendo of on-line interactive debugging. — J. C. R. Licklider in 1968

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

610. If the standard says that things depend on the phase of the moon, the programmer should be prepared to look out the window as necessary. — Chris Torek

611. If the user can’t use it, it doesn’t work. — Susan Dray

612. If there is a choice, test early, because more than 50% of all defects are usually introduced in the requirements stage alone. — Edward Kit

613. If there’s a “trick” to it, the UI is broken. — Douglas Anderson

614. If there’s one thing that computers do well, it’s to make the same mistake uncountable times at inhuman speed. — Peter Coffee

615. If two people write exactly the same program, each should be put into microcode and then they certainly won’t be the same. — Alan Perlis

616. If UNIX is the face of the future I wanna go back to quill pens. — Joseph Snipp

617. If we believe in data structures, we must believe in independent (hence simultaneous) processing. For why else would we collect items within a structure? Why do we tolerate languages that give us the one without the other? — Alan Perlis

618. If we can dispel the delusion that learning about computers should be an activity of fiddling with array indexes and worrying whether X is an integer or a real number, we can begin to focus on programming as a source of ideas. — Harold Abelson

619. If we wish to count lines of code, we should not regard them as lines produced but as lines spent. — Edsger Dijkstra

620. If you can imagine a society in which the computer-robot is the only menial, you can imagine anything. — Alan Perlis

621. If you cannot grok the overall structure of a program while taking a shower [e.g., with no external memory aids], you are not ready to code it. — Richard Pattis

622. If you don’t care about quality, you can meet any other requirement. — Gerald M. Weinberg

623. If you don’t get the unit bugs out during unit testing you’ll be finding and fixing them in system testing, or worse, in the field, where the cost will be orders of magnitude higher. — Boris Beizer

624. If you don’t think carefully, you might believe that programming is just typing statements in a programming language. — Ward Cunningham

625. If you don’t unit test then you aren’t a software engineer, you are a typist who understands a programming language. — Moses Jones

626. If you find that you’re spending almost all your time on theory, start turning some attention to practical things; it will improve your theories. If you find that you’re spending almost all your time on practice, start turning some attention to theoretical things; it will improve your practice. — Donald Knuth

627. If you make a small change to a program, it can result in an enormous change in what the program does. If nature worked that way, the universe would crash all the time. — Jaron Lanier

628. If you notice a lot of attention being given to process improvement, it’s a sure sign that all the smart employees have left the company and those who remain are desperately trying to find a “process” that is so simple that the boneheads who remain can handle it. — Scott Adams

629. If you optimize everything, you will always be unhappy. — Donald Knuth

630. If you put garbage in a computer nothing comes out but garbage. But this garbage, having passed through a very expensive machine, is somehow ennobled and none dare criticize it. — Pierre Marie Gallois

631. If you receive an e-mail with a subject of “Badtimes,” delete it immediately WITHOUT reading it! This is the most dangerous E-Mail virus yet. It will re-write your hard drive. Not only that, but it will recalibrate your refrigerator’s coolness setting so all your ice cream goes melty, drink all your beer, make you fall in love with a penguin, give you nightmares about circus midgets, leave the toilet seat up and kill your dog. — Badtimes Virus Alert

632. If you rely too much on the people in other countries and other companies, in a sense that’s your brain and you are outsourcing your brain. — Bill Gates

633. If you sat a monkey down in front of a keyboard, the first thing typed would be a UNIX command. — Bill Lye

634. If you show people the problems and you show people the solutions they will be moved to act. — Bill Gates

635. If you take the road less traveled, just make sure it isn’t on the critical path. — Elisabeth Hendrickson

636. If you think C+ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one? — Tom Cargil, C+ Journal

637. If you torture data sufficiently, it will confess to almost anything. — Fred Menger

638. If you use the system in a dirty environment, open it periodically and vacuum the boards and components with a small vacuum designed for this kind of work. Don’t loosen anything in the process — sucking all the chips off the system board with an industrial strength wet/dry vac is not covered by your warranty. — Gateway 2000 User Manual

639. If you want concurrency and have only objects, the best way is to commit suicide. — Christian Schulte

640. If you want to accomplish something in the world, idealism is not enough — you need to choose a method that works to achieve the goal. In other words, you need to be “pragmatic.” — Richard Stallman

641. If you want to achieve excellence, you can get there today. As of this second, quit doing less-than-excellent work. — Thomas J. Watson

642. If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea. — Antoine de Saint-Exupery

643. If you want to go somewhere, goto is the best way to get there. — Ken Thompson

644. If you want to increase your success rate, double your failure rate. — Thomas J. Watson

645. If you want to shoot yourself in the foot, Perl will give you ten bullets and a laser scope, then stand by and cheer you on. — Teodor Zlatanov

646. If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? — Seymour Cray, about clusters

647. If your application does not run correctly, do not blame the operating system. — Master Ninjei

648. If your code isn’t worth documenting then it isn’t worth keeping — Jonathan Nagler

649. If your computer speaks English it was probably made in Japan. — Alan Perlis

650. If your organization was forced to choose between making IT more business savvy or making business more IT savvy, I think you’d get much more bang for the buck by pursuing the latter. — Jeff Tash

651. If your plan is not in writing, you do not have a plan at all. Instead you have only a dream, a vision, or perhaps a nightmare. — Gerald Michaelson

652. If your program is very bad, do not try to debug it. Instead, throw it out and start over. — Walter Savitch

653. If your project doesn’t work, look for the part that you didn’t think was important. — Arthur Bloch

654. If your software works, thank a tester. — Harry Robinson

655. If your work isn’t predictable, management has no reason to trust you. — Watts Humphrey

656. If you’re going to use sophisticated test+design+automation tools then your people must be trained in those tools and given enough time to internalize the methodologies behind the tools. If you don’t figure that into the equation, your attempt at test design automation will fare worse than manual testing. You can’t expect a person who’s never flown an airplane to take off in an F-16 on the first day. — Boris Beizer

657. If you’re guessing, you’re bluffing, and the person with the most political power wins. — Watts Humphrey

658. If you’re not serving the customer, you’d better be serving someone who is. — Karl Albrecht and Ron Zembe

659. If you’re one in a million, there are 6,000 other people just like you — and 600 of them are on the Internet. — Hal Rubenstein

660. If you’re producing a public API, something for people to extend, you really should make everything final that doesn’t have a reason to be non-final: It’s a genie you can’t put back in the bottle — you can’t final something that wasn’t final when you first published your API, without risking making people’s subclasses uncompilable. You can un-final it if there’s a reasonable use-case for overriding a method that was final before. In short, not finaling methods in your API means you may box yourself in later — to the point of needing to do things like check if a subclass overrides a method or not and do something different depending on the result. — Tim Boudreau

661. If you’ve got a basket with 3 oranges in it and you take 5 out, then you have to put 2 oranges in again in order for it to be empty. — Peter Gutmann

662. I’m a “contents provider” not a website designer. I can use my time to improve the contents of+my+home+page or the looks, but not both. What looks “cool and modern” to someone is often considered bad taste by someone else, and fashions change fast. Also, very plain html downloads and displays faster than anything else, and many people still suffer from slow web connections. — Bjarne Stroustrup

663. I’m afraid as great as computers are, they cannot tell you about the quality of your product. The profitability, yes, but not the quality. The human eye, the human experience, is the one thing that can make quality better — or poorer. — Stanley Marcus

664. I’m always right. This time I’m just even more right than usual. — Linus Torvalds

665. I’m not saying we purposely introduced bugs or anything in+Sims, but this is kind of a natural result of any complexities of software… that you can’t fully test it. — Will Wright

666. I’m not schooled in the science of human factors, but I suspect surprise is not an element of a robust user interface. — Chip Rosenthal

667. I’m not suggesting that we stop protecting our software against outside inputs and user errors. Such protection is essential. Nor should we reduce protection against faulty inputs from networks or other systems. However, protecting the software from external abuse is not the same as protecting it from internal abuse and bugs. If you build-in self-protection from internal problems such as bugs, you are doing on-line debugging in the user’s shop and at the user’s expense. That’s no way to treat a user. — Boris Beizer

668. I’m reminded of the day my daughter came in, looked over my shoulder at some Perl 4 code, and said, ‘What is that, swearing? — Larry Wall

669. I’m skeptical of neural networks because people are writing the programs and designing the networks that are designing the programs. I wish we knew more about how we think. — Grace Murray Hopper

670. I’m sorry that we have to have a Washington presence. We thrived during our first 16 years without any of this. I never made a political visit to Washington and we had no people here. It wasn’t on our radar screen. We were just making great software. — Bill Gates

671. I’m struck by the insidious, computer-driven tendency to take things out of the domain of muscular activity and put them into the domain of mental activity. The transfer is not paying off. Sure, muscles are unreliable, but they represent several million years of accumulated finesse. — Brian Eno

672. I’m sure the problem is either the hardware or the software. — K. Rivalsi

673. I’m talking about configuration compatibility with other software that has no direct interface. For example, two supposedly independent SCSI controllers, or my fax program that must be loaded last, or a sorry backup program that can’t be installed from any drive but A: if there’s a CD-ROM on the system. Pick your favorites from the infinite list. Okay, so why not do configuration compatibility testing with the programs most likely to coexist. Say against the five most popular word processors, spreadsheets, graphics, etc. Several reasons. First, the list is big, not small. If you pick the “most popular” and attempt to get say, 98% coverage, you’ll be thinking in terms of cross-testing against several hundred packages rather a dozen. Second, if there’s a compatibility problem its not just what you are doing but what the other program is doing that causes the problem. That’s not just testing against static packages that just sit there, but dynamically. More precisely, it’s not just testing against several hundred packages but against several hundred packages (squared) each of which can be in any of several hundred states (squared). — Boris Beizer

674. Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. — Jeff Raskin

675. Imitating paper on a computer screen is like tearing the wings off a 747 and using it as a bus on the highway. — Ted Nelson

676. Improving the world one bug at a time. — Harry Robinson

677. In 1971 when I joined the staff of the MIT Artificial Intelligence lab, all of us who helped develop the operating system software, we called ourselves hackers. — Richard Stallman

678. In 1984 mainstream users were choosing VMS over UNIX. Ten years later they are choosing Windows over UNIX. What part of that message aren’t you getting? — Tom Payne

679. In a 5 year period we get one superb programming language. Only we can’t control when the 5 year period will begin. — Alan Perlis

680. In a lot of software, the application is dissociated from the user interface. I think this is an excellent idea. It’s the way things ought to be done. You can concentrate on the two aspects separately. — Bjarne Stroustrup

681. In a room full of top software designers, if two agree on the same thing, that’s a majority. — Robert Glass

682. In a software project team of 10, there are probably 3 people who produce enough defects to make them net negative producers. — Gordon Schulmeyer

683. In a way, staring into a computer screen is like staring into an eclipse. It’s brilliant and you don’t realize the damage until its too late. — Bruce Sterling

684. In academia, in industry, and in the commercial world, there is a widespread belief that computing science as such has been all but completed and that, consequently, computing has matured from a theoretical topic for the scientists to a practical issue for the engineers, the managers, and the entrepreneurs. I would therefore like to posit that computing’s central challenge, “How not to make a mess of it,” has not been met. On the contrary, most of our systems are much more complicated than can be considered healthy, and are too messy and chaotic to be used in comfort and confidence. The average customer of the computing industry has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. — Edsger W. Dijkstra

685. In an imperfect world, software can be an island of perfection. Software does exactly what the programmer tells it to do. — David Weinberger

686. In case you haven’t realized it, building computer systems is hard. — Martin Fowler

687. In case you’re not a computer person, I should probably point out that “Real Soon Now” is a technical term meaning “sometime before the heat-death of the universe, maybe.” — Scott Fahlman

688. In college I worked as a consultant. One day this grad student was having trouble with his Fortran program and brought the printout to me. He said he kept changing things but couldn’t get it to run correctly. His analysis: “I get the feeling that the computer just skips over all the comments.” — Samuel Stoddard

689. In college, they started all physics problems with “assume a frictionless surface.” The difference between college and industry is that in college you spend all your time on the formulas and in industry you spend all your time on friction. — Larry McVoy

690. In computer science, we stand on each other’s feet. — Brian K. Reid

691. In computing, invariants are ephemeral. — Alan Perlis

692. In computing, the mean time to failure keeps getting shorter. — Alan Perlis

693. In computing, turning the obvious into the useful is a living definition of the word “frustration.” — Alan Perlis

694. In considering any new subject, there is frequently a tendency, first, to overrate what we find to be already interesting or remarkable; and, secondly, by a sort of natural reaction, to undervalue the true state of the case, when we do discover that our notions have surpassed those that were really tenable. — Ada Lovelace

695. In contrast to people, computers double their ability every 18 months. There therefore exists the possibility that machines will develop intelligence and dominate the world. — Stephen Hawking

696. In Cyberspace, the First Amendment is a local ordinance. — John Perry Barlow

697. In English every word can be verbed. Would that it were so in our programming languages. — Alan Perlis

698. In fact what I would like to see is thousands of computer scientists let loose to do whatever they want. That’s what really advances the field. — Donald Knuth

699. In fact, you can throw away the last three syllables of “superhighway.” It’s a soup. Call it Information Soup and we’re getting somewhere. — Charles S. Murray

700. In general, my conclusion after doing numerical work for a while is that the desire to look at algorithms crucial to your research as black boxes is futile. In the end, I always had to dig into the details of the algorithms because they were either never black-boxable or the black-box versions didn’t do a good enough job. — David Ascher

701. In many cases, there’s far too much integration between the user interface and the application. In my opinion, that makes it harder to design the software. It makes software harder to change, harder to debug, and it makes it harder to take something from one environment and put it into another. — Bjarne Stroustrup

702. In My Egotistical Opinion, most people’s C programs should be indented six feet downward and covered with dirt. — Blair P. Houghton

703. In my personal experience, object-oriented design and object-oriented programming lead to better code than you get from more traditional procedural approaches — code that is more flexible, more extensible, and more maintainable without imposing significant performance overheads. — Bjarne Stroustrup

704. In pioneer days they used oxen for heavy pulling, and when one ox couldn’t budge a log, they didn’t try to grow a larger ox. We shouldn’t be trying for bigger computers, but for more systems of computers. — Rear Admiral Grace Hopper

705. In programming these days, cheaper isn’t about price, it’s about mental effort. — Jason Hunter

706. In programming, as in everything else, to be in error is to be reborn. — Alan Perlis

707. In programming, everything we do is a special case of something more general — and often we know it too quickly. — Alan Perlis

708. In programming, it’s often the buts in the specification that kill you. — Boris Beizer

709. In so far as virus-makers have any discernible motive, they presumably feel vaguely anarchistic. I appeal to them: do you really want to pave the way for a new fat-cat profession software+doctors? If not, stop playing at silly memes, and put your modest programming talents to better use. — Richard Dawkings

710. In software systems it is often the early bird that makes the worm. — Alan Perlis

711. In software, the chain isn’t as strong as its weakest link; it’s as weak as all the weak links multiplied together — Steve McConnell

712. In ten years, computers will just be bumps in cables. — Gordon Bell

713. In the 1990s, we learned to grok objects. The revolution in mainstream software development from structured programming to object-oriented programming was the greatest such change in the past 20 years, and arguably in the past 30 years. There have been other changes, including the most recent (and genuinely interesting) nascence of web services, but nothing that most of us have seen during our careers has been as fundamental and as far-reaching a change in the way we write software as the object revolution. Until now. Starting today, the performance lunch isn’t free any more. Sure, there will continue to be generally applicable performance gains that everyone can pick up, thanks mainly to cache size improvements. But if you want your application to benefit from the continued exponential throughput advances in new processors, it will need to be a well-written concurrent (usually multi-threaded) application. And thats easier said than done, because not all problems are inherently parallelizable and because concurrent programming is hard. — Herb Sutter

714. In the beginner’s mind there are many possibilities; in the expert’s mind there are few. — Shunryu Suzuki

715. In the development of the understanding of complex phenomena, the most powerful tool available to the human intellect is abstraction. Abstraction arises from the recognition of similarities between certain objects, situations, or processes in the real world and the decision to concentrate on these similarities and to ignore, for the time being, their differences. — Charles Anthony Richard Hoare

716. In the end, the answer to “Could computers think?” is that it doesn’t matter whether they think. What matters is whether we think they think. In the decades ahead, as we learn ever more about how we ourselves work, and as our computers become ever more complex and competent, the words computer and think will continue to warp, until they’re so different from their 1940s meanings that the question will lose relevance — and, then, meaning. In time, the boundaries between the born and the made, the grown and the built, the living and the dead, the evolved and the programmed, the biological and the artificial, will evaporate. They’re already melting like candles in a firestorm. — Paul Valery

717. In the long run, every program becomes rococo, and then rubble. — Alan Perlis

718. In the malleable world of cyberspace, today’s breakthrough is tomorrow’s anachronism; events move at speeds dictated by processor power and the human imagination, creating technological wunderkinder whose half-lives are measured in weeks, if not days. — Paul Gilster

719. In the next century, when art will be packaged as virtual reality software, realistic paintings will sell the way Shaker furniture does now. Shaker furniture will sell the way Van Gogh paintings do. And teddy bears owned by Elvis will come to auction only occasionally. — Brad Holland

720. In the twenty-first century, whoever controls the screen controls consciousness, information and thought. — Timothy Leary

721. In the world of systems design, programs and data are the scissor blades working together to form the broader class — software. Lacking either blade, computers couldn’t cut through problems — yet for many people, software is synonymous with programs. — Tom Gilb

722. In their capacity as a tool, computers will be but a ripple on the surface of our culture. In their capacity as an intellectual challenge, they are without precedent in the cultural history of mankind. — Edsger Dijkstra

723. In this business, by the time you realize you’re in trouble, it’s too late to save yourself. Unless you’re running scared all the time, you’re gone. — Bill Gates

724. In total desperation, I called over to the engineering building, and I said, “Please cut off a nanosecond and send it over to me.” — Rear Admiral Grace Murray Hopper

725. In trying to understand the Linux phenomenon, then, we have to look not at a single innovator but to a sort of bizarre Trinity: Linus Torvalds, Richard Stallman, and Bill Gates. Take away any of these three and Linux would not exist. — Neal Stephenson

726. In view of all the deadly computer viruses that have been spreading lately, Weekend Update Saturday+Night+Live would like to remind you: when you link up to another computer, you’re linking up to every computer that that computer has ever linked up to. — Dennis Miller

727. In XP, we don’t divide and conquer. We conquer and divide. First we make something that works, then we bust that up and solve the little parts. — Kent Beck

728. Increasingly, people seem to misinterpret complexity as sophistication, which is baffling — the incomprehensible should cause suspicion rather than admiration. Possibly this trend results from a mistaken belief that using a somewhat mysterious device confers an aura of power on the user. — Niklaus Wirth

729. Indeed, when I design my killer language, the identifiers “foo” and “bar” will be reserved words, never used, and not even mentioned in the reference manual. Any program using one will simply dump core without comment. Multitudes will rejoice. — Tim Peters

730. Indirection is the right direction. — Andy Glew

731. Industry executives and analysts often mistakenly talk about strategy as if it were some kind of chess match. But in chess, you have just two opponents, each with identical resources, and with luck playing a minimal role. The real world is much more like a poker game, with multiple players trying to make the best of whatever hand fortune has dealt them. In our industry, Bill Gates owns the table until someone proves otherwise. — David Moschella

732. Information Superhighway is really an acronym for “Interactive Network For Organizing, Retrieving, Manipulating, Accessing And Transferring Information On National Systems, Unleashing Practically Every Rebellious Human Intelligence, Gratifying Hackers, Wiseacres, And Yahoos.” — Keven Kwaku

733. Information technology and business are becoming inextricably interwoven. I don’t think anybody can talk meaningfully about one without the talking about the other. — Bill Gates

734. Information wants to be free. Information also wants to be expensive. Information wants to be free because it has become so cheap to distribute, copy, and recombine — too cheap to meter. It wants to be expensive because it can be immeasurably valuable to the recipient. That tension will not go away. It leads to endless wrenching debate about price, copyright, “intellectual property,” the moral rightness of casual distribution, because each round of new devices makes the tension worse, not better. — Stewart Brand, although Peter Samson may have quoted Brand before he said it

735. Informational tools are symbolic metaphors that amplify the intellect rather than the muscle of their users. — Bill Gates

736. Innovation is the process of turning ideas into manufacturable and marketable form. — Watts Humprey

737. Inside every well-written large program is a well-written small program. — Charles Anthony Richard Hoare

738. Inspection is by far the most effective way to remove bugs. — Capers Jones

739. Interestingly, most UNIX utilities have a command line option which will cause the system to rip the user’s legs off and beat them to death with the soggy ends. This is often the default behavior. — Bruce Murphy

740. Interfaces keep things tidy, but don’t accelerate growth: Functions do. — Alan Perlis

741. INTERVIEWERTell us how you came to be drawn into the world of pragmas. COMPILER WRITER: Well, it started off with little things. Just a few boolean flags, a way to turn asserts on and off, debug output, that sort of thing. I thought, what harm can it do? It’s not like I’m doing anything you couldn’t do with command line switches, right? Then it got a little bit heavier, integer values for optimization levels, even the odd string or two. Before I knew it I was doing the real hard stuff, constant expressions, conditionals, the whole shooting box. Then one day when I put in a hook for making arbitrary calls into the interpreter, that was when I finally realised I had a problem… — Greg Ewing

742. Invariably, if something is so complex that it requires the addition of multiple preferences or customization choices, it is probably too complex to use. — Don Norman

743. Investing in putting bad requirements into management tools is a lot like rearranging the deck chairs on the Titanic. — Ivy Hooks

744. Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble? — Alan Perlis

745. It the+computer is a medium that can dynamically simulate the details of any other medium, including media that cannot exist physically. It is not a tool, although it can act like many tools. — Alan Kay

746. It goes against the grain of modern education to teach students to program. What fun is there to making plans, acquiring discipline, organizing thoughts, devoting attention to detail, and learning to be self critical. — Alan Perlis

747. It has been discovered that C++ provides a remarkable facility for concealing the trival details of a program — such as where its bugs are. — David Keppel

748. It is a tremendous responsibility for us to have all the eyes focused on what we do and give people exactly what they need when they ask for it. — Larry Page, Google

749. It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. — Alan Perlis

750. It is characteristic of all deep human problems that they are not to be approached without some humor and some bewilderment. — Freeman Dyson

751. It is easier to change the specification to fit the program than vice versa. — Alan Perlis

752. It is easier to write an incorrect program than understand a correct one. — Alan Perlis

753. It is not a language’s weaknesses but its strengths that control the gradient of its change: Alas, a language never escapes its embryonic sac. — Alan Perlis

754. It is only when they go wrong that machines remind you how powerful they are. — Clive James

755. It is practically impossible to teach good programming style to students that have had prior exposure to BASIC. As potential programmers they are mentally mutilated beyond hope of regeneration. — Edsger W. Dijkstra

756. It is quite amazing — and a bit saddening — how gullible and desperate are willing to expect salvation from the next gadget. I remember how TV was promoted by the theory that a daily dose of Shakespeare in every living room would elevate the culturally deprived to unfathomed heights, thus curing all ills of society, etc. And what did we get? Soap operas and quizzes. I remember how, with the advent of terminals, interactive debugging was supposed to solve all our programming problems, and how, with the advent of color screens, “algorithm animation” was supposed to do the same. And what did we get? Commercial software with a disclaimer that explicitly states that you are a fool if you rely on what you just bought. And now we have the multimedia/communication hype: the best bits are those that just arrived from far away, and if you are not “on line,” “on the Net,” you just don’t count, you are not of this world (which is virtual anyhow…). Apart from a change in vocabulary, it is the same hype, the same snake oil over and over again, and you can do me a favor by not getting excited by all the time you are supposed to save by switching to “home banking.” — Edsger Dijkstra

757. It is the users who should parameterize procedures, not their creators. — Alan Perlis

758. It is vain to do with more that which can be done with less. — William of Occam

759. It is…fruitless to question and debate early design decisions; better solutions are often quite obvious in hindsight. Perhaps the most important point was that someone did make decisions, in spite of uncertainties. — Niklaus Wirth

760. It may not always be profitable at first for businesses to be online, but it is certainly going to be unprofitable not to be online. — Esther Dyson

761. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler. — Paul Graham

762. It occurred to me this morning that many system design flaws can be traced to unwarrantedly anthropomorphizing the user. — Steven Maker

763. It seems reasonable to examine past testing methods and to concentrate on those that have been most cost- effective at finding bugs in the past. This would be okay but for the pesticide paradox. The techniques wear out. Programmers aren’t fools and they’re not about to let themselves be hit over and over again by the same test methods. They will adopt design practices and designs that eliminate the bugs found by your favorite, most cost-effective method. The consequence of not recognizing this is false confidence. — Boris Beizer

764. It should be noted that no ethically-trained software engineer would ever consent to write a “DestroyBaghdad” procedure. Basic professional ethics would instead require him to write a “DestroyCity” procedure, to which “Baghdad” could be given as a parameter. — Nathaniel S. Borenstein

765. It shouldn’t be too much of a surprise that the Internet has evolved into a force strong enough to reflect the greatest hopes and fears of those who use it. After all, it was designed to withstand nuclear war, not just the puny huffs and puffs of politicians and religious fanatics. — Denise Caruso

766. It took us three years to build the NeXT computer. If we’d given customers what they said they wanted, we’d have built a computer they’d have been happy with a year after we spoke to them — not something they’d want now. — Steve Jobs

767. It would appear that we have reached the limits of what it is possible to achieve with computer technology, although one should be careful with such statements, as they tend to sound pretty silly in 5 years. — John Von Neumann, 1949

768. It would be very discouraging if somewhere down the line you could ask a computer if the Riemann hypothesis is correct and it said, “Yes, it is true, but you won’t be able to understand the proof.” — John Horgan

769. It would be wonderful if we could just tuck in a few loose ends and change a handful of details of present systems to have them work properly. Unfortunately, we have learned that the GUI concept has fundamental flaws that cannot be corrected by small changes. These flaws have to do with incompatibilities between the designs of both GUIs and command-line interfaces and the way our brains are wired. As we cannot change the way our minds work, we must change the interface design. — Jef Raskin

770. [Programming’s] the only job I can think of where I get to be both an engineer and an artist. There’s an incredible, rigorous, technical element to it, which I like because you have to do very precise thinking. On the other hand, it has a wildly creative side where the boundaries of imagination are the only real limitation. — Andy Hertzfeld

771. It’s a pity the universe doesn’t use segmented architecture with a protected mode. — Rich Cook

772. It’s a well known fact that computing devices such as the abacus were invented thousands of years ago. But it’s not well known that the first use of a common computer protocol occured in the Old Testament. This, of course, was when Moses aborted the Egyptians’ process with a control-sea. — Tom Galloway

773. It’s difficult to extract sense from strings, but they’re the only communication coin we can count on. — Alan Perlis

774. It’s easy to cry “bug” when the truth is that you’ve got a complex system and sometimes it takes a while to get all the components to coexist peacefully. — Doug Vargas

775. It’s hard enough to find an error in your code when you’re looking for it; it’s even harder when you’ve assumed your code is error-free. — Steve McConnell

776. It’s hard to create highly reusable frameworks. They become complex, hard to learn, and even harder to maintain. I was on both the framework consumer and the framework producer side, and it can be hard from either perspective. A key challenge in framework development is how to preserve stability over time. The more miles a framework gets the better you understand how you should have built it in the first place. Therefore you would like to tweak and improve it. However, since your framework is heavily used you are highly constrained in what you can change. At this point it is crucial to have well defined APIs and to make it clear to the clients what is published API and what internal code is. For published APIs you should commit to stability and for internal code you have the freedom to change it. — Erich Gamma

777. It’s harder than you might think to squander millions of dollars, but a flawed software development process is a tool well suited to the job. — Alan Cooper

778. It’s hardware that makes a machine fast. It’s software that makes a fast machine slow. — Craig Bruce

779. It’s impossible to maintain a large C++ software module if you didn’t actually write it. — Bjarne Stroustrup

780. It’s no coincidence that the most popular PC books go by names like “Windows for Dummies”. Detroit doesn’t sell books like “Oldsmobiles for Idiots” or “A Foul-Up’s Guide to Fords”. — Patrick L Anderson

781. It’s not computer literacy that we should be working on, but sort of human-literacy. Computers have to become human-literate. — Nicholas P. Negroponte

782. It’s not know-how that counts, it’s know-when. — Jerry Weinberg

783. It’s not the prevention of bugs but the recovery — the ability to gracefully exterminate them — that counts. — Victoria Livschitz

784. It’s not the technology, folks, it’s the people. When we trace the+errors back, it’s always human error. — Bob Herbold, Microsoft

785. It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it. — Steve McConnell

786. It’s ridiculous to live 100 years and only be able to remember 30 million bytes. You know less than a compact disc. The human condition is really becoming more obsolete every minute. — Marvin Minsky

787. It’s the day of optimizing compilers folks. Optimizers, like John Henry’s steam drills, beat humans every time. Trying to beat the optimizer in a modern system means that you can second guess the highly secretive optimization algorithms, the operating system, and the caching hardware and firmware. That’s a blissfully arrogant wish. Code level attempts at optimization are usually counterproductive because they result in strange code that the optimizer can’t handle well. — Boris Beizer

788. It’s time to reappreciate the original software: paper. — Dale Dauten

789. I’ve found, by and large, that doing the right thing is often the right thing to do. — Jerry Pournelle

790. I’ve never met a human being who would want to read 17,000 pages of documentation, and if there was, I’d kill him to get him out of the gene pool. — Joseph Costello

791. I’ve never met anyone responsible for C language code maintenance who speaks well of the C Language. Anyone out there who LIKES to maintain C code ? — Ted Dennison

792. Java is, in many ways, C++ — . — Michael Feldman

793. Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as online control equipment in hazardous environments […] in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage. — Microsoft IIS license

794. Java, the best argument for Smalltalk since C++. — Frank Winkler

795. Java’s a drug you rub on venture capitalists to make them crazy. — John Doerr

796. Java Script is the duct tape of the Internet. — Charlie Campbell

797. JCL is a crazed assembly language programmer’s idea of what a command language should look like: verbose, tedious and error-prone. AND UPPER CASE. — Geoff Collyer

798. John von Neumann draws attention to what seemed to him a contrast. He remarked that for simple mechanisms, it is often easier to describe how they work than what they do, while for more complicated mechanisms, it is usually the other way around. — Edsger Dijkstra

799. Just because the standard provides a cliff in front of you, you are not necessarily required to jump off it. — Norman Diamond

800. Just because you don’t know a technology, doesn’t mean you won’t be called upon to work with it. — Mike Bongiovanni

801. Just remember: you’re not a “dummy,” no matter what those computer books claim. The real dummies are the people who, though technically expert, couldn’t design hardware and software that’s usable by normal consumers if their lives depended upon it. — Walter Mossberg

802. Know thy user, and you are not thy user. — Arnie Lund

803. Language designers are not intellectuals. They’re not as interested in thinking as you might hope. They just want to get a language done and start using it. — Dave Moon

804. Languages shouldn’t hinder progress by outliving their usefulness. — Alan Kay

805. Learn the rules so you know how to break them properly. — The Dali Lama

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

807. Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. — Donald Knuth

808. Let’s say the docs present a simplified view of reality… — Larry Wall

809. Life is a process which may be abstracted from other media. — John Von Neumann

810. Life is just a class. Override it. Choices in life are just IF statements. Based on that, your whole life may crash or run to completion. — Assaad Chalhoub

811. Life is too short for manual testing. — Harry Robinson

812. Life was simple before World War II. After that, we had systems. — Rear Admiral Grace Hopper

813. Life would be so much easier if we could just look at the source code. — Dave Olson

814. Like almost everyone who uses e-mail, I receive a ton of spam every day. Much of it offers to help me get out of debt or get rich quick. It would be funny if it weren’t so irritating. — Bill Gates

815. Like any tyrant, a word-processing program both threatens and comforts. Obey its arbitrary inflexible rules, and it rewards you with tireless service in rearranging, removing, even correcting your words. Disobey its rules, and it responds either by issuing a warning beep and a terse instruction or by dissolving months of labor into scattered electrons. In millions of offices, the computer fulfills the tyrant’s dream: it forbids everything that it does not permit. — Edward Mendelson

816. Like punning, programming is a play on words. — Alan Perlis

817. Like the creators of sitcoms or junk food or package tours, Java’s designers were consciously designing a product for people not as smart as them. — Paul Graham

818. Linux is just a file system and a file manager. — Steve Ballmer

819. Linux is only free if your time is worthless. — Jamie Zawinski

820. LISP programmers know the value of everything and the cost of nothing. — Alan Perlis

821. Live TV died in the late 1950s, electronic bulletin boards came along in the mid-1980s; meaning there was about a 25-year gap when it was difficult to put your foot in your mouth and have people all across the country know about it. — Michael Meissner

822. Look for places where the program does the same conceptual thing, in different ways — say, by iterating versus by recursion, or by columns versus by rows, doing steps in different orders, etc. Pick what seems the cleanest way, and change all the other places to use it. Doing the same thing the same way several times, is clearer than doing the same thing different ways multiple times. — Steven J. DeRose

823. Look for things to fix and fix them. — Alan Page

824. Looking at the proliferation of personal web pages on the net, it looks like very soon everyone on earth will have 15 Megabytes of fame. — M. G. Siriam

825. Los Angeles County officials have asked that manufacturers, suppliers and contractors stop using the terms “master” and “slave” regarding computer hard drives, saying such terms are unacceptable and offensive. Additionally, the term “e-mail” will now be called “e-person letter”, “dumb terminals” will now be “CPU-challenged monitors” and “Unix” will be referred to as “sexually dysfunctional operating system.” Obviously, “fingering” is now banned entirely. — Kevin Fizz

826. Machines are simple: a hammer, a door hinge, a steak knife. Systems are much more complicated; they have components, feedback loops, mean times between failure, infrastructure. Digital systems are daedal; even a simple computer program has hundreds of thousands of lines of computer code doing all sorts of different things. A complex computer program has thousands of components, each of which has to work by itself and in interaction with all the other components. This is why object-oriented programming was developed: to deal with the complexity of digital systems…systems have bugs. A bug is a particular kind of failure…It’s different from a malfunction. When something malfunctions, it no longer works properly. When something has a bug, it misbehaves in a particular way, possibly unrepeatable, and possibly unexplainable. Bugs are unique to systems. Machines can break, or fail, or not work, but only a system can have a bug. — Bruce Schneier

827. Machines are worshipped because they are beautiful, and valued because they confer power; they are hated because they are hideous, and loathed because they impose slavery. — Bertrand Arthur William Russell

828. Make no mistake about it: Computers process numbers — not symbols. We measure our understanding (and control) by the extent to which we can arithmetize an activity. — Alan Perlis

829. Making duplicate copies and computer printouts of things no one wanted even one of in the first place is giving America a new sense of purpose. — Andy Rooney

830. Making something variable is easy. Controlling duration of constancy is the trick. — Alan Perlis

831. Man can hardly be defined… as an animal who makes tools; ants and beavers and many other animals make tools, in the sense that they make an apparatus. Man can be defined as an animal that makes dogmas. — Gilbert K. Chesterton

832. Man is not a machine. Although man most certainly processes information, he does not necessarily process it in the way computers do. Computers and men are not species of the same genus. However much intelligence computers may attain, now or in the future, theirs must always be an intelligence alien to genuine human problems and concerns. — Joseph Weizenbaum

833. Man is still the most extraordinary computer of all. — John F. Kennedy

834. Man is the best computer we can put aboard a spacecraft, and the only one that can be mass-produced with unskilled labor. — Wernher von Braun

835. Management Speak: Individual Contributor. Translation: Employee who does real work. — Juergen Rudnick

836. Manual testing is the pits — not only that, it doesn’t work very well because the test execution error rate is about 50% or worse. Testing is not about monkeys pounding keys. Today, with automated test drivers and capture/playback tools widely available, there’s no difficulty in achieving a high degree of test execution automation — in the high 95% range for most applications. The biggest advantage to test execution automation can’t be reaped unless you intend to run the tests many times. However, most organizations under-estimate the number of times tests will be run. While they think in terms of once or twice, the actual number is likelier to be closer to forty or fifty times over the life of the software. If you accept test execution automation as a capital investment in testware, no less important than software, then you’ll see a truly remarkable long-term return on investment that beats all other software development tools. — Boris Beizer

837. Manuals just slow you down and make you feel stupid. The directions are too slow, too detailed, and use too much abstract, arcane or academic language — like boot up instead of turn on the red switch in the back. — Neil Fiore

838. Many C++ design decisions have their roots in my dislike for forcing people to do things in some particular way. — Bjarne Stroustrup

839. Many companies that have made themselves dependent on IBM-equipment (and in doing so have sold their soul to the devil) will collapse under the sheer weight of the unmastered complexity of their data processing systems. — Edsger Dijkstra

840. Many of the great ideas are not precipitated by the customer. While the customer knows what he wants, he doesn’t always know what’s possible. And that first dawned on me in my earliest days in business. When I was new at IBM, working in sales and taking a management training program in Sleepy Hollow, New York, I came back to my room grumbling about the lack of speed and reliability of the tape drives, and wondered why the engineers couldn’t do something about it. My roommate stared at me with a look of total exasperation. “Boy, you guys in sales are all the same,” he said. “You remind me of the farmer in 1850. If you asked him what he wanted, he would say he wanted a horse that was half as big and ate half as many oats and was twice as strong. And there would be no discussion of a tractor.” — David Kearns, former CEO of Xerox

841. Many of you have gone through the trauma of tool chaos in which every department or project buys or builds their own tools independently of any other group. Besides being confusing, you pay more for site licenses, training, and all the rest. It seems reasonable to minimize tool chaos by standardizing on a few basic tools. That’s okay if you’re not too serious about it and don’t expect too much in the long run. — Boris Beizer

842. Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy. It is maintained for commercial reasons only. Object-oriented programming solidly rests on the principles and concepts of traditional procedural programming. OOP has not added a single novel concept. — Niklaus Wirth

843. Many spend their time berating practitioners for not applying their method. We all need to disseminate our ideas, but most of our time should be spent applying and improving our methods, not selling them. The best way to sell a mouse trap is to display some trapped mice. — David Parnas

844. May your experiences with new software be dull, dull, dull. — Boris Beizer

845. Measuring programming progress by lines of code is like measuring aircraft building progress by weight. — Bill Gates

846. Meetings are a great trap. Soon you find yourself trying to get agreement and then the people who disagree come to think they have a right to be persuaded. However, they are indispensable when you don’t want to do anything. — John Kenneth Galbraith

847. Memo to the folks in Silicon Valley: You will have good jobs for 20 more years. By 2020, though, computer chips will be cheaper than bubble-gum wrappers, and PCs will be in museums. — Michio Kaku, Professor of Theoretical Physics at City College of New York

848. Memory is like an orgasm. It’s a lot better if you don’t have to fake it. — Seymour Cray

849. Men are like computers: I don’t understand them, I just use them for my amusement. — Holly Waits

850. Methods for predicting the future: 1) read horoscopes, tea leaves, tarot cards, or crystal balls… collectively known as “nutty methods;” 2) put well-researched facts into sophisticated computer… commonly referred to as “a complete waste of time.” — Scott Adams

851. Microsoft knows that reliable software is not cost effective. According to studies, 90% to 95% of all bugs are harmless. They’re never discovered by users, and they don’t affect performance. It’s much cheaper to release buggy software and fix the 5% to 10% of bugs people find and complain about. — Bruce Schneier

852. Microsoft programs are generally bug-free. If you visit the Microsoft hotline, you’ll literally have to wait weeks if not months until someone calls in with a bug in one of our programs. 99.99% of calls turn out to be user mistakes. — Benedikt Heinen

853. Microsoft’s only factory asset is the human imagination. — Bill Gates

854. millihelen, n.: The amount of beauty required to launch one ship. — Tom Weller, “Science Made Stupid”

855. Millions for compilers, but hardly a penny for understanding human programming language use. Now, programming languages are obviously symmetrical, the computer on one side, the human on the other. In an appropriate science of computer languages, one would expect that half the effort would be on the computer side, understanding how to translate the languages into executable form, and half on the human side, understanding how to design languages that are easy or productive to use. Yet, we do not even have an enumeration of all the psychologicial functions programing languages serve for the user. Of course, there is lots of programming language design, but it comes from computer scientists. And though technical papers on languages contain many appeals to ease of use and learning, they patently contain almost no psychologicial evidence nor any appeal to psychological science. — Allen Newell and Stuart Card

856. More bad software has been wrought in the name of performance than any other reason. While the operating system and the software’s system’s architecture and algorithms can have a profound effect on performance, today, there’s almost nothing that the individual programmer can do at the coding level to improve performance. In fact, most attempts to improve performance by coding tricks reduces rather than enhances performance. — Boris Beizer

857. More bugs have been introduced into programs through premature optimization than any other cause, including pure stupidity. (sometimes quoted as, “More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason including blind stupidity.”) — Bill Wulf

858. More good code has been written in languages denounced as bad than in languages proclaimed wonderful — much more. — Bjarne Stroustrup

859. More heresy? Doesn’t he Beizer believe in user involvement? Sure I do; but would you let the users design the software? They’re not competent. Nor are they competent to design all but a small part of the tests. — Boris Beizer

860. More than anything else, the greatest danger to good computer science research today may be excessive relevance. Evidence for the worldwide fascination with computers is everywhere, from the articles on the financial, and even the front pages of the newspapers, to the difficulties that even the most prestigious universities experience in finding and keeping faculty in computer science. The best professors, instead of teaching bright students, join start-up companies, and often discover that their brightest students have preceded them. Computer science is in the limelight, especially those aspects, such as systems, languages, and machine architecture, that may have immediate commercial applications. The attention is flattering, but it can work to the detriment of good research. — Dennis M. Richie

861. More than the act of testing, the act of designing tests is one of the best bug preventers known. The thinking that must be done to create a useful test can discover and eliminate bugs before they are coded — indeed, test-design thinking can discover and eliminate bugs at every stage in the creation of software, from conception to specification, to design, coding and the rest. — Boris Beizer

862. Most computer technologists don’t like to discuss it, but the importance of beauty is a consistent (if sometimes inconspicuous) thread in the software literature. Beauty is more important in computing than anywhere else in technology. Beauty is important in engineering terms because software is so complicated. Beauty is our most reliable guide to achieving software’s ultimate goal: to break free of the computer, to break free conceptually. Software is stuff unlike any other. Software’s goal is to escape this gravity field, and every key step in software history has been a step away from the computer, toward forgetting about the machine and its physical structure and limitations — forgetting that it can hold only so many bytes, that its memory is made of fixed size cells, that you refer to each cell by a numerical address. Software needn’t accept those rules and limitations. But as we throw off the limits, what guides us? How do we know where to head? Beauty is the best guide we have. — David Gelernter

863. Most of the brain consists of “wires;” a single unit may have thousands of connections with other units and with itself. That is not the case in a standard computer, where a chip usually has less than six connections. Moreover, neurons are much, much slower than the switching elements of the computer. It seems likely that the brain can accomplish its complex feats of perception and thought by means of millions of connections acting in parallel. The connections as a whole define the information content of the system. In this way a vast amount of knowledge can be brought to bear on a decision all at once. The brain seems to be able to perform as many as two hundred trillion operations in a second; not serially, but simultaneously. — Jeremy Campbell

864. Most of you are familiar with the virtues of a programmer. There are three, of course: laziness, impatience, and hubris. — Larry Wall

865. Most people find the concept of programming obvious, but the doing impossible. — Alan Perlis

866. Most production software bugs are soft: they go away when you look at them. — Jim Gray

867. Most programs have numerical inputs and/or numerical configuration parameters. These parameters have minimum and maximum values. It is a testing truism that tests that probe values at or around (just less, just more) these extreme values are productive. That truth hasn’t changed. The question is not what we do for single numerical values but for combinations of numerical values. If a single parameter has two extremes (minimum and maximum) and we test these extremes properly, we’ll have six test cases to run (min-, min, min+, max-, max, max+). For two parameters, that’s 6 x 6 or 36 cases to try and for n parameters, that 6n. That’s an exponential test growth. That’s over 60 million test cases for ten parameters. These are easy test cases to generate automatically, but even so, at one- hundred test per second, that’s 168 hours of testing. And 10 parameters isn’t a lot. I’m sure you have many routines or programs in which the parameter count is in the 50–100 range. That works out to 2 x 1068 years or about 2x1058 times longer than the estimated age of the universe. Even automation won’t crack that nut. And if you only did the extreme (min and max) that’s just 2n and a mere 2 x 1011 universe lifetimes. — Boris Beizer

868. Most software is used in a business context, so most victims of bad interaction are paid for their suffering. Their job forces them to use software, so they cannot choose not to use it — they can only tolerate it as well as they can. — Alan Cooper

869. Most software needs to be spanked. — Alan Cooper

870. Most technology has the shelf life of a banana. — Scott McNealy

871. Mostly, when you see programmers, they aren’t doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they’re sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. — Charles M. Strauss

872. Motor vehicles have to be safe, and there are rules and regulations governing their development and production which, by and large, keep the roads safe from exploding cars. It does not stop accidents caused by driver error or poor maintenance, but it does make us safer. And if a group of people build their own cars then they have to follow those same rules in order to be allowed to use public roads, even if they gave their cars away. It should be the same for software, especially in our networked world where other people’s insecure computers host spambots and other malware that can cause damage to all network users. — Bill Thompson

873. Much of the Web is like an anthill built by ants on LSD. — Jakob Nielsen

874. Multimedia? As far as I’m concerned, it’s reading with the radio on! — Rory Bremner

875. Mutually consenting classes may of course do whatever they like with each other, but even that doesn’t necessarily make it right. — Programming Perl, 2nd ed.

876. My adult and professional life has been spent trying to make computers easier to use, starting as far back as 1965. In those early days, people thought only sissies needed graphics. In 1972, when we devoted 256K to storing images, most people wrote it off as just another indecency and MIT arrogance. Why would anybody in their right mind commit so much memory to the icing, not the cake? Three decades later, we find a generation of kids who count memory not in Ks, but in Ms (and soon Gs). This is actually quite wonderful, but look at what we are using it for. The interface hasn’t fundamentally changed since the introduction of the Macintosh more than a decade ago. It’s just harder to use and obscenely obese. Someone needs a wake-up call. — Nicholas Negroponte

877. My basic idea is that programming is the most powerful medium of developing the sophisticated and rigorous thinking needed for mathematics, for grammar, for physics, for statistics, for all the “hard” subjects… In short, I believe more than ever that programming should be a key part of the intellectual development of people growing up. — Seymour Papert

878. My computer beat me at checkers, but I sure beat it at kickboxing. — Emo Phillips

879. My favorite thing about the Internet is that you get to go into the private world of real creeps without having to smell them. — Penn Jillette

880. My favorite way of avoiding breaking user code by changing base classes is simply to make major interfaces abstract classes. That way, the implementation details are in the derived classes and there is no private data to cause recompilation after change. The public interface can be kept relatively stable. — Bjarne Stroustrup

881. My feeling is that when we prepare a program, the experience can be just like composing poetry or music; as Andrei Ershov has said, programming can give us both intellectual and emotional satisfaction, because it is a real achievement to master complexity and to establish a system of consistent rules. — Donald Knuth

882. My idea is that, inasmuch as certain cognitive tasks and principles are tied to nature’s laws, these tasks and principles are indifferent to language, culture, gender, or the particular mode of information that is provided. I believe that there are some universal cognitive tasks that are deep and profound — indeed, so deep and profound that it is worthwhile to understand them in order to design our displays in accord with those tasks. Cognitive tasks should be turned into design principles. I think it is important for software to avoiding imposing a cognitive style on workers and their work. — Edward Tufte

883. My impression was and is that many programming languages and tools represent solutions looking for problems, and I was determined that my work should not fall into that category. Thus, I follow the literature on programming languages and the debates about programming languages primarily looking for ideas for solutions to problems my colleagues and I have encountered in real applications. Other programming languages constitute a mountain of ideas and inspiration. But it has to be mined carefully to avoid featurism and inconsistencies. — Bjarne Stroustrup

884. My message to the serious programmer is: spend a part of your working day examining and refining your own methods. Even though programmers are always struggling to meet some future or past deadline, methodological abstraction is a wise long-term investment. To the teacher of programming, even more, I say: identify the paradigms you use, as fully as you can, then teach them explicitly. They will serve your students when Fortran has replaced Latin and Sanskrit as the archetypal dead language. — Robert W. Floyd

885. Naturally we feel that mentally ill people are not what we are looking for when we hire programmers — although there is no empirical data to support or contradict that view… Is it appropriate to give tests for mental illness to anyone applying for any kind of job? — Gerald Weinberg

886. Nearly everybody is convinced that every programming style but their own is ugly and unreadable. Leave out the “but their own” and they’re probably right. — Jerry Coffin

887. Never allow the same bug to bite you twice. — Steve Maguire

888. Never apply a Star Trek solution to a Babylon 5 problem. — Nicholas C. Weaver

889. Never assume anything for sure. Computers and programs are “living things.” — Tom Venetianer

890. NEVER EVER mess with a PCB jumper you don’t understand, even if it’s labeled “SEX AND FREE BEER” — Dave Haynie

891. Never forget the story of famous email user Oliver North. Ollie, you’ll remember, was a great devotee of the White House email system, PROFS. He diligently deleted all incriminating notes he sent or received. What he didn’t realize was that, somewhere else in the White House, computer room staff were equally diligently backing up the mainframe where his messages were stored. — Virginia Shea

892. Never put off until run time what you can do at compile time. — David Gries

893. Never trust a computer you can’t throw out a window. — Steve Wozniak

894. Never, ever, ever let systems-level engineers do human interaction design unless they have displayed a proven secondary talent in that area. Their opinion of what represents good human-computer interaction tends to be a bit off-track. — Bruce Tognazzini

895. Niklaus Wirth has lamented that, whereas Europeans pronounce his name correctly (Ni-klows Virt), Americans invariably mangle it into (Nick-les Worth). Which is to say that Europeans call him by name, but Americans call him by value. — unknown

896. No amount of source-level verification or scrutiny will protect you from using untrusted code. — Ken Thompson

897. No computer has ever been designed that is ever aware of what it’s doing; but most of the time, we aren’t either. — Marvin Minsky

898. No matter how complex the situation, good systems engineering involves putting value measurements on the important parameters of desired goals and performance of pertinent data, and of the specifications of the people and equipment and other components of the system. — Simon Ramo and Robin St. Clair

899. No matter what the problem is, it’s a people problem. — Jerry Weinberg

900. No printing is permitted on this book. This book cannot be given to someone else. This book cannot be read aloud. — License terms for Adobe ebooks

901. Not having a schedule is okay if it’s your PhD and you plan to spend 14 years on the thing, or if you’re a programmer working on the next Duke Nukem and we’ll ship when we’re good and ready. But for almost any kind of real business, you just have to know how long things are going to take, because developing a product costs money. — Joel Spolsky

902. Not that I have anything much against redundancy. But I said that already. — Larry Wall

903. Not too many years ago, a child’s experience was limited by how far he or she could ride a bicycle or by the physical boundaries that parents set. Today, the real boundaries of a child’s life are set more by the number of available cable channels and videotapes, by the simulated reality of videogames, by the number of megabytes of memory in the home computer. Now kids can go anywhere, as long as they stay inside the electronic bubble. — Richard Louv

904. Now for the converse. Should the programmers know what the testers have in store for them? It is possible for a dishonest programmer to cheat and fake test results. But dishonesty will manifest itself no matter what safeguards you impose. All testing is based on the “competent programmer” hypothesis. This hypothesis states that we’re dealing with “natural bugs” rather than sabotage. Similarly, though never stated, we also assume that the programmer is honest in addition to being competent. If a programmer is honest, competent, and given the time and resources needed, then if we give them detailed information on the tests we’ve planned, they have the opportunity to examine their software in that light and will often make design changes that avoid the potential problems for which our tests were fishing. Isn’t that what we want to accomplish? To find and fix the bug before it’s written in? Just as more software knowledge means better tests, more test knowledge means better software. And if the programmers “cheat” by avoiding all the traps we’ve laid for them, then as testers it is our responsibility to escalate the game (and the software’s quality) by thinking of even subtler conditions and corresponding tests. — Boris Beizer

905. Now how about independent test groups? Do we really want to do away with that? Lets now distinguish between independent testing and independent test groups. Independent test groups are wasteful because it means that two different sets of people must learn the software. Such groups are wasteful because the very independence means that much testing will be redundant. I believe in independent testing but not in independent test groups. Independent testing means taking a different look at the software than taken by the software’ originator. That different look can be taken by a different person or by a different group, or by a different organization (e.g., an independent test group). In mature organizations with programmers that don’t have their ego written all over the software, individual programmers and members of the same programming group can provide that independent look. It’s more efficient and need not compromise software quality or testing effectiveness. — Boris Beizer

906. Now please, don’t misunderstand me. Programs should interact with other programs in a predictable way. If your software has direct interfaces with other programs (such as export and import, communications, data structures, backup, etc.) then you must test those interfaces. You’d be a fool not to. I’m not talking about direct interfaces or interfaces with virtual processors such as the operating system, network managers, etc. Test the direct interfaces, test them often, and test them well. — Boris Beizer

907. Now that we have all this useful information, it would be nice to be able to do something with it. Actually, it can be emotionally fulfilling just to get information. This is usually only true, however, if you have the social life of a kumquat. — UNIX Programmer’s Manual

908. Object-oriented programming is an exceptionally bad idea which could only have originated in California — Edsger Dijkstra

909. Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelet, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices — wait or eat it raw. Software customers have had the same choices. — Frederick P. Brooks

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

911. Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet — something to make software costs drop as rapidly as computer hardware costs do. — Fred Brooks

912. Of course, Linus didn’t sit down in a vacuum and suddenly type in the Linux source code. He had my book. But the code was his. The proof of this is that he messed the design up. — Andrew Tanenbaum

913. Of course, the best way to get accurate information on Usenet is to post something wrong and wait for corrections. — Matthew Austern

914. Often program density and comprehensibility are inversely related. Its always funny to talk to people who are real Perl freaks, because they love to make these magic pieces of Perl code, and theres no detectable flaws or anything in there, its just randomly assembled characters, or it looks pretty random. Its a sort of write once, never look at it again. — James Gosling

915. Old hardware becomes obsolete; old software goes into production every night. — Robert Glass

916. Old testers never die, they just regress. — Jeremy Sloan

917. On two occasions I have been asked by+members+of+Parliament, “Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. — Charles Babbage

918. Once a person has understood the way variables are used in programming, he or she has understood the quintessence of programming. — Edsger Dijkstra

919. Once the business data have been centralized and integrated, the value of the database is greater than the sum of the preexisting parts. — Larry Ellison

920. Once the product’s task is known, design the interface first; then implement to the interface design.

921. Users do not care about what is inside the box, as long as the box does what they need done. — Jef Raskin

922. Once upon a time, it was the job of programmers to invent sort algorithms. These days almost all programmers use sort algorithms and a few experts spend their lives improving on the state of the art for particular purposes. We need to make concurrency implicit in a similar way so that the average programmer will not have to do complicated concurrency operations. If concurrency is internal to a class, to an object, it becomes much easier to handle. My feeling is that a lot of concurrency can be packaged so that the end user has only the vaguest idea of how it’s really done. — Bjarne Stroustrup

923. Once you succeed in writing the programs for these complicated algorithms, they usually run extremely fast. The computer doesn’t need to understand the algorithm, its task is only to run the programs. — Robert Tarjan

924. Once you understand how to write a program get someone else to write it. — Alan Perlis

925. One day I got a call toward the end of the day from a sales rep in Chicago who couldn’t get his computer to boot up. We went round and round for about two hours — nothing worked. I was ready to pull my hair out, but I don’t like losing. To lighten the tension of the moment, I started chitchatting with him as we’re waiting to see if the machine will restart. He has an IBM ThinkPad, and I told him how much I like mine. He said, “Yeah, they’re okay, but I travel a lot, and I got tired of the darn thing being so heavy, so I installed Windows CE to make it lighter.” — Samuel Stoddard

926. One day, when I timed an annoying (computer) delay and found it constituted all of 10 seconds, I had what I would call a “monk moment,” a quick slap that told me, Pay attention — watch yourself. I had let technology and its attendant idol, efficiency, make a fool of me. — Kathleen Norris

927. One difference between humans and computers lies in the relative strengths in their respective abilities to understand symbolic relationships and to learn facts. A computer can remember billions of facts with extreme precision, whereas we are hard pressed to remember more than a handful of phone numbers. On the other hand, we can read a novel and understand and manipulate the subtle relationships between the characters: something that computers have yet to demonstrate an ability to do. Computers have been weak in their ability to understand and process information that contains abstractions and complex webs of relationships, but they are improving. — Raymond Kurzweil

928. One man’s constant is another man’s variable. — Alan Perlis

929. One of Linus Torvald’s earlier projects was a program that would switch between printing AAAA and BBBB. This later evolved to Linux. — Larry Greenfield, The Linux Users’ Guide Beta Version 1

930. One of my first big programming assignments as a student of computer science was a source formatter for Pascal. The assignment was designed to show us the real-life difficulties of group programming projects. It succeeded perhaps too well. For a long time, I was convinced that source code formatters were a total waste of time, and decided to write beautiful code that no automatic formatter could improve upon. In fact, I would intentionally write code that formatters could only make worse. — Guido van Rossum

931. One of my most productive days was throwing away 1000 lines of code. — Ken Thompson

932. One of the best things to come out of the home computer revolution could be the general and widespread understanding of how severely limited logic really is. — Frank Herbert

933. One of the big bugaboos of current software is the configuration compatibility problem and how to test for it. How, using PC software as an example (because that’s where the problem is most acute), should we test to assure that this software will work in every possible hardware and software configuration that it might face in the present or in the future and how do we determine by testing that this software can coexist with every other piece of software or application package with which it may cohabit? — Boris Beizer

934. One of the great enemies of design is when systems or objects become more complex than a person — or even a team of people — can keep in their heads. This is why software is generally beneath contempt. — Bran Ferren

935. One of the great inventions of the twentieth century was the studied, methodical engineering of myth for political ends. — Caryl Rivers

936. One of the great skills in using any language is knowing what not to use, what not to say. There’s that simplicity thing again. — Ron Jeffries

937. One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. — Robert Firth

938. One of the most dangerous (and evil) things ever injected into the project world is the notion of process maturity. Process maturity is for replicable manufacturing contexts. Projects are one-time shots. Replicability is never the primary issue on one-time shots. More evil than good has come from the notion that we should stick to the methodology. This is a recipe for non-adaptive death. I’d rather die by commission. — David Schmaltz

939. One of the problems the internet has introduced is that in the electronic village all the village-idiots have internet access. — Peter Nelson

940. One of the things that tools can do is to help bad designers create ghastly designs much more quickly than they ever could in the past. — Grady Booch

941. One person’s data is another person’s program. — Guy L. Steele, Jr., Tartan Labs

942. One test is worth a thousand expert opinions. — Bill Nye

943. One user — a regular caller of ours — got herself into some serious computer trouble when she set about cleaning up her system. She had been exploring the hard drive in the file manager and discovered hundreds of files in the Windows directory with all different file extensions. Being of an orderly mind, and with several hours of free time, she had created a TXT folder, a COM folder, a DLL folder, and so forth, and moved all the files into these subdirectories. — Samuel Stoddard

944. Onedemonstrations always crash. And two: the probability of them crashing goes up exponentially with the number of people watching. — Steve Jobs

945. Operating systems are like underwear — nobody really wants to look at them. — Bill Joy

946. Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught. — Larry Wall

947. Other advanced languages, such as assembler and C, were not terribly complex in themselves, but the environments in which applications were developed were downright weird, with mines scattered about everywhere, ready to blow the inattentive programmer out of the water. — Bruce Tognazzini

948. Our ability to imagine complex applications will always exceed our ability to develop them. — Grady Booch

949. Our basic ideas about what are better or worse practices are strongly influenced by people we perceive as knowing how to make software — James Bach

950. Our democracy, our constitutional framework is really a kind of software for harnessing the creativity and political imagination for all of our people. The American democratic system was an early political version of Napster. — Al Gore

951. Our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible. — Edsger Dijkstra

952. Our studies support the claim that knowledge of programming plans and rules of programming discourse can have a significant impact on program comprehension…. programmers have strong expectations that other programmers will follow these discourse rules. If the rules are violated, then the utility afforded by the expectations that programmers have built up over time is effectively nullified. — Greg Kroah-Hartman

953. Over the last year online banking has attracted 6.3 million users, but a massive 3.1 million of those have closed their accounts already due to poor website design and inefficient service. — Internet Money, Issue 4

954. Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. — Isaac Asimov

955. Part of the reason so many companies continue to develop software using variations of waterfall is the misconception that the analysis phase of waterfall completes the design and the rest of the process is just non-creative execution of programming skills. — Steven Gordon

956. Pattern recognition and association make up the core of our thought. These activities involve millions of operations carried out in parallel, outside the field of our consciousness. If AI appeared to hit a brick wall after a few quick victories, it did so owing to its inability to emulate these processes. — Daniel Crevier

957. Pay attention to what users do, not what they say. — Jakob Nielsen

958. PCMCIA — People can’t memorize computer industry acronyms. — Andy Grove

959. People get a message stating, “There are a lot of interesting things on this disk, but I seem to have misplaced my glasses, so I can’t read it right now. Would you like me to utterly destroy all your work for the last year?” Oh, I’m sorry. That’s not actually what it says. It says, “Disk damaged. Initialize?” Anyone writing messages like this needs to be initialized. — Bruce Tognazzini

960. People get annoyed when you try to debug them. — Larry Wall

961. People have always been quick to announce “the next software development revolution,” usually about their own brand-new technology. Dont believe it. New technologies are often genuinely interesting and sometimes beneficial, but the biggest revolutions in the way we write software generally come from technologies that have already been around for some years and have already experienced gradual growth before they transition to explosive growth. This is necessary: You can only base a software development revolution on a technology that’s mature enough to build on (including having solid vendor and tool support), and it generally takes any new software technology at least seven years before it’s solid enough to be broadly usable without performance cliffs and other gotchas. As a result, true software development revolutions like OO happen around technologies that have already been undergoing refinement for years, often decades. — Herb Sutter

962. People seem to misinterpret complexity as sophistication. — Niklaus Wirth

963. People should mentally separate programming into building libraries and using them. Today you write a supporting library, and tomorrow you use it. Far too many times people try and build their systems as one big conglomerate. I have a tendency to build the specific case first if I haven’t tried something several times before, because it is pretty fundamental that we understand the concrete solution better than the abstract. That approach contrasts with the approach taken by people who start generalizing before they’ve tried it once — they sit trying to design a general solution to a problem that they have no experience with. — Bjarne Stroustrup

964. People think that computer science is the art of geniuses but the actual reality is the opposite, just many people doing things that build on each other, like a wall of mini stones. — Donald Knuth

965. People who deal with bits should expect to get bitten. — Jon Bentley

966. People who don’t take risks generally make about two big mistakes a year. People who do take risks generally make about two big mistakes a year. — Peter F. Drucker

967. Perhaps if we wrote programs from childhood on, as adults we’d be able to read them. — Alan Perlis

968. Perhaps the very best question that you can memorize and repeat, over and over, is, “What is the most valuable use of my time right now?” — Brian Tracy

969. Perl — The only language that looks the same before and after RSA encryption. — Keith Bostic

970. Perl has grown from being a very good scripting language into something like a cross between a universal solvent and an open-ended Mandarin where new ideograms are invented hourly. — Jeffrey Davis

971. Perl is a car with an autopilot designed by insane aliens. — Jeff Smith

972. Perl is like vise grips. You can do anything with it but it is the wrong tool for every job. — Bruce Eckel

973. Personal Web pages are the ’90s equivalent of home video, except that you don’t have to visit someone else’s house to fall asleep — you can do so in the comfort of your own home. — Ray Valdes

974. Personalizationthe automatic tailoring of sites and messages to the individuals viewing them so that we can feel that somewhere there’s a piece of software that loves us for who we are. — David Weinberger

975. Pertempto ergo sum I test, therefore I am. — Harry Robinson

976. Pessimists, we’re told, look at a glass containing 50% air and 50% water and see it as half empty. Optimists, in contrast, see it as half full. Engineers, of course, understand the glass is twice as big as it needs to be. — Bob Lewis

977. Pesticide Paradox: Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. — Boris Beizer

978. pixel, n.: A mischievous, magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology: Witness the sprites in computer graphics, the demons in artificial intelligence, and the trolls in the marketing department. — Jeff Meyer

979. PL/I and Ada started out with all the bloat, were very daunting languages, and got bad reputations — deservedly. C++ has shown that if you slowly bloat up a language over a period of years, people don’t seem to mind as much. — James Hague

980. Please don’t fall into the trap of believing that I am terribly dogmatical about the+goto+statement. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline! — Edsger Dijkstra

981. Pointers are like jumps, leading wildly from one part of the data structure to another. Their introduction into high-level languages has been a step backwards from which we may never recover. — Charles Anthony Richard Hoare

982. Poor management can increase software costs more rapidly than any other factor. — Barry Boehm

983. Portability is for people who cannot write new programs. — Linus Torvalds

984. Premature optimization is the root of all evil. — Donald E. Knuth

985. Presumably, we’re all fully qualified computer nerds here, so we are allowed to use “access” as a verb. Be advised, however, that the practice in common usage drives English-language purists to scowling fidgets. — Erik Strom

986. Problems cannot be solved at the same level of awareness that created them. — Albert Einstein

987. Problems look mighty small from 150 miles up. — Roger B. Chaffee

988. Problems worthy of attack prove their worth by fighting back. — Paul Erdos

989. Product quality has almost nothing to do with defects or their lack. — Tom DeMarco

990. Program — A set of instructions, given to the computer, describing the sequence of steps the computer performs in order to accomplish a specific task. The task must be specific, such as balancing your checkbook or editing your text. A general task, such as working for world peace, is something we can all do, but not something we can currently write programs to do. — From Unix User’s Manual, Supplementary Documents, p. 14–3:

991. Programmers are like artists. Writing software that just gets put away feels like intellectual masturbation. — Bruce Perens

992. Programmers are not to be measured by their ingenuity and their logic but by the completeness of their case analysis. — Alan Perlis

993. Programmers can get a lot of benefit from reading source code. You can’t simply tell people how to be good programmers. You can offer them some principles of good programming. You can describe some good design experiences you’ve had. But you can’t give them a real knowledge of how to be a good programmer. I believe the best way for that knowledge to be obtained is by reading code. Writing code can certainly help people become good programmers, but reading good code is much better. — Yukihiro Matsumoto

994. Programmers regard themselves as artists. As such they consider keeping accurate records of their handiwork on par with washing an ash tray. — Otis Port

995. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of non-critical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. — Donald E. Knuth

996. Programmerspeople who struggle to fix the bugs they create; Analyst/Programmers: people who analyze existing strategies to fix the bugs they create; Developers: people who develop new strategies to fix the bugs they create; Computer Scientists: people who analyze and develop scientific strategies to fix the bugs they create. — Rodolfo A. Frino

997. Programming can be fun, so can cryptography; however they should not be combined. — Kreitzberg and Shneiderman

998. Programming is an unnatural act. — Alan Perlis

999. Programming is just another name for the lost art of thinking. — Aaron Hsu

1000. Programming is like sex; one mistake and you have to support it for the rest of your life. — Michael Sinz

1001. Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians. — Edsger Dijkstra

1002. Programming is similar to a game of golf. The point is not getting the ball in the hole but how many strokes it takes. — Harlan Mills

1003. Programming is the art of picking a needle out of a hay heap. — Rodolfo A. Frino

1004. Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. — from Revised 4 Report on the Algorithmic Language Scheme

1005. Programming languages, like pizzas, come in only too sizes; too big and too small. — Richard Pattis

1006. Programming software is like creating a maze and going through it at the same time. Only you know the exact route you’ve taken, and anyone else is likely to get lost or screw it up entirely. — Lyndsey Hayward

1007. Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. — Rich Cook

1008. Programming without an overall architecture or design in mind is like exploring a cave with only a flashlight: You don’t know where you’ve been, you don’t know where you’re going, and you don’t know quite where you are. — Danny Thorpe

1009. Programs must be written for people to read, and only incidentally for machines to execute. — Harold Abelson and Gerald Sussman

1010. Progress in software and organizational design is like progress in the Kama Sutra: we’ve tried all of the positions, some more than once, some we enjoy and some hurt because we aren’t flexible enough, and yet we keep the book open next to the night light. — Claude Bullard

1011. Progress is possible only if we train ourselves to think about programs without thinking of them as pieces of executable code. — Edsger Dijkstra

1012. Projects promoting programming in natural language are intrinsically doomed to fail. — Edsger Dijkstra

1013. Prolonged contact with the computer turns mathematicians into clerks and vice versa. — Alan Perlis

1014. Purely applicative languages are poorly applicable. — Alan Perlis

1015. Puzzle Principle: We can program a computer to solve any problem by trial and error, without knowing how to solve it in advance, provided only that we can have a way to recognize when the problem is solved. — Marvin Minsky

1016. Python is a truly wonderful language. When somebody comes up with a good idea it takes about 1 minute and five lines to program something that almost does what you want. Then it takes only an hour to extend the script to 300 lines, after which it still does almost what you want. — Jack Jansen

1017. Python’s syntax succeeds in combining the mistakes of Lisp and Fortran. I do not construe that as progress. — Larry Wall

1018. Q: What is the single greatest software development sin a software company can commit?

1019. A: Deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug-prone and is bloated and needs to be completely rethought and rebuilt from ground zero. — Joel Spolsky

1020. Quality is free, but only to those who are willing to pay heavily for it. — Lister and DeMarco

1021. Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives. — William A. Foster

1022. Quality isn’t something you lay on top of subjects and objects like tinsel on a Christmas tree. — Robert Pirsig

1023. Quality means doing it right when no one is looking. — Henry Ford

1024. Reading computer manuals without the software is as frustrating as reading sex manuals without the hardware. — Arthur C. Clarke

1025. Real men don’t use backups, they post their stuff on a public ftp server and let the rest of the world make copies. — Linus Torvalds

1026. Real programmers always confuse Christmas and Halloween because Oct31 == Dec25. — Andrew Rutherford

1027. Real programmers can write assembly code in any language. — Larry Wall

1028. Real quality is far more a matter of what a product does for you and how it changes you than whether it is perfectly free of flaws. — Tom DeMarco

1029. Realism in testing (for objective 1) is a hang-up that gets in the way of good testing. In some software-driven electromechanical systems, for example, the only way to force timing problems is to remove the hardware and to test the software in a simulator that allows gears and things to “move” several times faster than the speed of light. Realism also gets in the way of test automation. Remember, we’re testing software, not the larger system in which the software may be embedded. Testing realism might mean building complicated robots that punch keys, turn dials, pour blood into test tubes, etc. These aren’t needed to test software. A false limitation of software testing to realistic hardware and/or system constraints, can for an embedded system, eliminate 50%-85% of all the tests that should be run. — Boris Beizer

1030. Realism in testing is a hang-up that gets in the way of good testing. In some software-driven electromechanical systems, for example, the only way to force timing problems is to remove the hardware and to test the software in a simulator that allows gears and things to “move” several times faster than the speed of light. Realism also gets in the way of test automation. Remember, we’re testing software, not the larger system in which the software may be embedded. Testing realism might mean building complicated robots that punch keys, turn dials, pour blood into test tubes, etc. — Boris Beizer

1031. Recursion is the root of computation since it trades description for time. — Alan Perlis

1032. Refactoring provides enough energy to a system for it to relax into a new and more comfortable state, a new local minimum. The effect of refactoring commonality is to tame the complexity of your system. — Keith Henney

1033. Reflection is like refactoring. If you can measure how much you are doing, you aren’t doing enough. — Ron Jeffries

1034. Reliability testing under a statistically valid user profile has been established for many applications as an effective method to determine when enough testing has been done to warrant using the product. Where its applicability has been confirmed, it is an accepted part of the testing tool kit. — Boris Beizer

1035. Remember that programming languages are not primarily a form for finished programs, but someting that programs have to be developed in. — Paul Graham

1036. Replicating assemblers and thinking machines pose basic threats to people and to life on Earth. Among the cognoscenti of nanotechnology, this threat has become known as the gray goo problem. — Eric Drexler

1037. Requirements are not architecture. Requirements are not design, nor are they the user interface. Requirements are need. — Andrew Hunt and David Thomas

1038. Requirements engineering is asking the right question, of the right person, at the right time. Easy, isn’t it? — Neil Maiden

1039. Requirements engineering is the branch of software engineering concerned with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families. — Pamela Zave

1040. Reusing pieces of code is like picking off sentences from other people’s stories and trying to make a magazine article. — Bob Frankston

1041. Right now you are a prisoner of each application you use. — Theodor Holm “Ted” Nelson

1042. Right now, computers, which are supposed to be our servants, are oppressing us. — Jef Raskin

1043. Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong. — Eric Raymond

1044. Rule#1: Don’t sweat the small stuff. Rule#2: It’s all small stuff. — Michael Mantell

1045. Rule”You shouldn’t have to open up a black box and take it apart to find out you’ve been pushing the wrong buttons!”Corollary”Every black box should have at least TWO blinking lights: “Paper Jam” and “Service Required (or equivalent).” — Steven D. Majewski

1046. Run a contest asking your customers to write the best manual for your product or service. Youll have a handful of good manuals, and you’ll uncover some evangelists. — Guy Kawasaki

1047. Save a tree — disband an ISO working group today. — Jason Zions

1048. Science is what we understand well enough to explain to a computer. Art is everything else we do. — Donald Knuth

1049. See, no matter how clever your automation systems might be, it all falls apart if your human wetware isn’t up to the job. — Andrew Orlowski

1050. See, you not only have to be a good coder to create a system like Linux, you have to be a sneaky bastard, too. — Linus Torvalds

1051. Serving the users’ needs doesn’t mean doing things the way the user expects us to. The users’ needs are ill-served by the programmer who takes design and architectural instructions from a non-programming user. Similarly, the users’ quality needs are ill served by the tester who strives to please by organizing tests along the users’ naive, preconceived ideas of how testing should be organized. — Boris Beizer

1052. Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration. — S. Kelly-Bootle

1053. Should the programmers know what the testers have in store for them? All testing is based on the “competent programmer” hypothesis. This hypothesis states that we’re dealing with “natural bugs” rather than sabotage. If a programmer is honest, competent, and given the time and resources needed, then if we give them detailed information on the tests we’ve planned, they have the opportunity to examine their software in that light and will often make design changes that avoid the potential problems for which our tests were fishing. Isn’t that what we want to accomplish? To find and fix the bug before it’s written in? Just as more software knowledge means better tests, more test knowledge means better software. And if the programmers “cheat” by avoiding all the traps we’ve laid for them, then as testers it is our responsibility to escalate the game (and the software’s quality) by thinking of even subtler conditions and corresponding tests. — Boris Beizer

1054. Simple things should be simple and complex things should be possible. — Alan Kay

1055. Simplicity does not precede complexity, but follows it. — Alan Perlis

1056. Simplicity is prerequisite for reliability. — Edsger Dijkstra

1057. Simplifications have had a much greater long-range scientific impact than individual feats of ingenuity. The opportunity for simplification is very encouraging, because in all examples that come to mind the simple and elegant systems tend to be easier and faster to design and get right, more efficient in execution, and much more reliable than the more contrived contraptions that have to be debugged into some degree of acceptability….Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated. — Edsger Dijkstra

1058. Since human beings themselves are not fully debugged yet, there will be bugs in your code no matter what you do. — Chris Mason

1059. Since humans don’t have decryption systems built into their anatomy, information must be deciphered before we experience it. The only way to make music that cannot be copied is to make music that cannot be heard. The only way to make movies that cannot be copied is to make movies that cannot be viewed. — Gene Kan

1060. Since when has the world of computer software design been about what people want? This is a simple question of evolution. The day is quickly coming when every knee will bow down to a silicon fist, and you will all beg your binary gods for mercy. — Bill Gates

1061. Sixty percent of software’s dollar is spent on maintenance, and sixty percent of that maintenance is enhancement. — Robert Glass

1062. Smart data structures and dumb code works alot better than the other way around. — Eric S. Raymond

1063. So many good ideas are never heard from again once they embark in a voyage on the semantic gulf. — Alan Perlis

1064. So-called “natural language” is wonderful for the purposes it was created for, such as to be rude in, to tell jokes in, to cheat or to make love in (and Theorists of Literary Criticism can even be content-free in it), but it is hopelessly inadequate when we have to deal unambiguously with situations of great intricacy, situations which unavoidably arise in such activities as legislation, arbitration, mathematics or programming. — Edsger Dijkstra

1065. Software and software development continue their rapid evolution — as do testing and QA technologies. Some of the best testing methods of the past are three decades old. They emerged in the mainframe days of batch processing, expensive computation, and minuscule memories. As a community devoted to quality, it would be blindly arrogant of us to think and act as if the profound changes of just the past decade had no effect on our methodologies. Commit to a continual quantitative evaluation of your paradigms so that when the world and technology changes, your methods change to match. — Boris Beizer

1066. Software comes from heaven when you have good hardware. — Ken Olsen

1067. Software development is a social activity. — David West

1068. Software development is like riding a surfboard — there is no process that will assure a successful ride, nor is there any process that will assure that you will interact propitiously with the other surfers sharing the same wave. Published processes, like published methods, provide observational data from which you can learn and thereby improve your innate abilities — just as observation of master surfers enables you to improve yourself. — David West

1069. Software economics has often been misconceived as the means of estimating the cost of programming projects. But economics is primarily a science of choice, and software economics should provide methods and models for analyzing the choices that software projects must make. — Leon Levy

1070. Software engineering has accepted as its charter “How to program if you cannot.” — Edsger Dijkstra

1071. Software engineering is fundamentally a contact sport. In software engineering as in rugby, no amount of theory about how to succeed in a scrum is going to come close to real experience in the middle of a few scrums. — Barry Boehm

1072. Software Engineering is that part of Computer Science which is too difficult for the Computer Scientist. — F. L. Bauer

1073. Software engineering: computer science for people who can’t program. — Edsger Dijkstra

1074. Software gets slower faster than hardware gets faster. — Nicklaus Wirth

1075. Software is a gas; it expands to fill its container. — Nathan Myhrvold

1076. Software is a great combination between artistry and engineering. When you finally get done and get to appreciate what you have done it is like a part of yourself that you’ve put together. I think a lot of the people here feel that way. — Bill Gates

1077. Software is a time bomb. — Michael Feathers

1078. Software is best understood as a branch of movie making. — Ted Nelson

1079. Software is like entropy. It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics; i.e. it always increases. — Norman R. Augustine

1080. Software is like sex: It’s better when it’s free. — Linus Torvalds

1081. Software is released for use, not when it is known to be correct, but when the rate of discovering errors slows down to one that management considers acceptable. — David West

1082. Software is the soul to the lifeless body of the hardware. — Ong Lee Shyh

1083. Software is to computers as yeast is to dough. — Chuck Bradshaw

1084. Software is under a constant tension. Being symbolic it is arbitrarily perfectible; but also it is arbitrarily changeable. — Alan Perlis

1085. Software is written by humans and therefore has bugs. — John Jacobs

1086. Software people would never drive to the office if building engineers and automotive engineers were as cavalier about buildings and autos as the software “engineer” is about his software. — Henry Baker

1087. Software suppliers are trying to make their software packages more user-friendly. Their best approach, so far, has been to take all the old brochures, and stamp the words, “user-friendly” on the cover. — Bill Gates

1088. Software Testing can be viewed as asking questions of the system under test. — Alan Richardson

1089. Software testing is a second childhood: You broke it, and I’m telling. — Sara Ford

1090. Software testing is like fishing, but you get paid. — Harry Robinson

1091. Software Testing: The bugs stop here. — Harry Robinson

1092. Software Testing: Where failure is always an option. — Harry Robinson

1093. Software without documentation is like a ship without a compass. — Assaad Chalhoub

1094. Software, by being comprehensive, can save costs by avoiding add-on pieces of software. We can save money in terms of speed of development or by being able to run on less expensive hardware. — Bill Gates

1095. Some people become so immersed in technology that they risk losing their own identity — a syndrome called technosis. You are a victim of technosis if you answer “yes” to questions such as: “Do you feel out of touch when you haven’t checked your answering machine or voice mail in the last 12 hours?” Symptoms of technosis include overdoing work and never feeling finished, believing faster is better, and not knowing how to function successfully without technology. — Michelle M. Weil and Larry D. Rosen, TechnoStress, 1999

1096. Some people have told me they don’t think a fat penguin really embodies the grace of Linux, which just tells me they have never seen an angry penguin charging at them in excess of 100mph. They’d be a lot more careful about what they say if they had. — Linus Torvalds

1097. Some people seem to believe that a programming language can or at least should solve most of their problems with system building. They are condemned to search forever for the perfect programming language and become repeatedly disappointed. — Bjarne Stroustrup

1098. Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. — Jamie Zawinski

1099. Some places it is better not to be. Some things it is better not to do. Life is too short to be engaged in activities that make one wish it were shorter. — Stanley Bing

1100. Some problems are so complex that you have to be highly intelligent and well-informed just to be undecided about them. — Laurence J. Peter

1101. Some programming languages manage to absorb change, but withstand progress. — Alan Perlis

1102. Some say Google is God. Others say Google is Satan. But if they think Google is too powerful, remember that with search engines unlike other companies, all it takes is a single click to go to another search engine. — Sergey Brin

1103. Some users, because they don’t know testing technology, or even that there is a such a thing as testing technology, mistakenly believe that they know something about testing. That’s the trouble: they know a thing or two when what they need to know to do effective testing are ten-thousand things. We’ve must keep plugging away on this one and educate the user that testing is a technical discipline as rigorous as programming and that if they’re not competent to do programming, they’re not competent to do testing. — Boris Beizer

1104. Sometimes I think the only universal in the computing field is the fetch-execute-cycle. — Alan Perlis

1105. Stakeholders seldom understand their requirements fully at the beginning of a project. They often lack a clear vision of what the system should do and change their minds during development. In general, stakeholders only become more sure about what they want when they see a system that does not exhibit the necessary features. — Annie Anton and Colin Potts

1106. Standards are always out of date. That’s what makes them standards. — Alan Bennett

1107. Structured Programming supports the law of the excluded muddle. — Alan Perlis

1108. Students in my software+testing classes often have a very difficult time thinking of bad ways to do things. Cultivate the skill of choosing poorly. It will be invaluable in evaluating others’ ideas. — Lee Copeland

1109. Success is a lousy teacher. It seduces smart people into thinking they can’t lose. — Bill Gates

1110. Successful computer entertainments in language have tended to be about the way something quite small and unitary — the chip, the microelectronic impulse, the bytes, the little gray box on one’s desk — opens up into something very large and elaborate. This opening up, the discovery of much in little, seems to be a fundamental resonance of human intelligence. — Robert Pinsky

1111. Suffusing the+technology culture is the belief among programmers and engineers that they’re working on the Next Big Thing — projects that change the world, not just deliver a more absorbent diaper or crunchier breakfast cereal. — Joseph Menn

1112. Suppose that we had n computers instead of just one. How much can we speed up what kinds of calculations? For some, we can surely gain a factor of n. But these are rare. For others, we can gain log n, but it is hard to find any or to prove what are their properties. And for most, I think, we can gain hardly anything; this is the case in which there are many highly branched conditionals, so that look-ahead on possible branches will usually be wasted. We know almost nothing about this; most people think, with surely incorrect optimism, that parallelism is usually a profitable way to speed up most computations. — Marvin Minsky

1113. Surveying the shifts of interest among computer scientists and the ever-expanding family of those who depend on computers in their work, one cannot help being struck by the power of the computer to bind together, in a genuine community of interests, people whose motivations differ widely. For what keeps us together is not some abstraction, such as Turing machines, or information, but the actual hardware that we work with everyday. — Maurice V. Wilkes

1114. Swallow a toad in the morning and you will encounter nothing more disgusting the rest of the day. — Nicolas de Chamfort

1115. Symmetry is a complexity-reducing concept (co-routines include subroutines); seek it everywhere. — Alan Perlis

1116. Symmetry is overrated. Overrated is symmetry. — Larry Wall

1117. Syntax, my lad. It has been restored to the highest place in the republic. — John Steinbeck

1118. System debugging, like astronomy, has always been done chiefly at night. — Frederick P. Brooks, Jr.

1119. System programmers and machine designers who produce the systems that the rest of us must work with. Please, give us tools that are a pleasure to use, especially for our routine assignments, instead of providing something we have to fight with. Please, give us tools that encourage us to write better programs, by enhancing our pleasure when we do so. It’s very hard for me now to convince college freshmen that programming is beautiful. — Donald E. Knuth

1120. Systems and structures are secondary to values, which in themselves are a powerful source of control that reduces the need for formal systems. — Joseph Badaracco, Jr. and Richard Ellsworth

1121. Systems have bugs. A bug is a particular kind of failure. It’s different from a malfunction. When something malfunctions, it no longer works properly. When something has a bug, it misbehaves in a particular way, possibly unrepeatable, and possibly unexplainable. Bugs are unique to systems. Machines can break, or fail, or not work, but only a system can have a bug. — Bruce Schneier

1122. Systems have sub-systems and sub-systems have sub-systems and so on ad finitum — which is why we’re always starting over. — Alan Perlis

1123. Tabs are good, spaces are bad and mixing the two just means that your motives are confused and that you don’t use enough functions. — John J. Lehmann

1124. Talk is cheap. Show me the code. — Linus Torvalds

1125. Teaching to unsuspecting youngsters the effective use of formal methods is one of the joys of life because it so extremely rewarding. Within a few months, they find their way into a new world with a justified degree of confidence that is radically novel for them; within a few months, their concept of intellectual culture has acquired a radically new dimension. To my taste and style, that is what education is about. — Edsger W. Dijkstra

1126. Technical people are better off not looking at patents. If somebody sues you, you change the algorithm or you just hire a hit-man to whack the stupid git. — Linus Torvalds

1127. Technology is like fish. The longer it stays on the shelf, the less desirable it becomes. — Andrew Heller

1128. Technology presumes there’s just one right way to do things and there never is. — Robert M. Pirsig

1129. Technology, like art, is a soaring exercise of the human imagination. — Daniel Bell

1130. Telling the future by looking at the past assumes that conditions remain constant. This is like driving a car by looking in the rear view mirror. — Herb Brody

1131. Test Design Automation: This is where the action is on the leading edge of testing. Instead of writing individual tests you create formal models such as finite-state machine models, regular expressions, domain specifications, constraint sets, or formal specifications. The tool then automatically generates a covering set of tests from the model. The focus of testing then shifts from designing individual test cases to creating models that faithfully express the requirements. — Boris Beizer

1132. Test early. Test often. Test enough. We favor an iterative development process: analyze a little, design a little, code a little, test what you can. — John McGregor and David Sykes

1133. Test everything. Hold on to that which is good. — 1 Thessalonians 5:21 (NIV)

1134. Test time can’t be predicted. — Watts Humphrey

1135. Testers can’t do a good job unless they know something about how the software is built. The specifics of the design often dictates what technique to use and what technique is unlikely to be productive at finding bugs. For example, domain testing is not a very effective bug catcher if the programmers have made all domain boundary parameters table-driven. Similarly, syntax testing will rarely find bugs if attempted against a generated parser. Testers should not be so weak-willed that knowledge will corrupt them or make them less effective. The more they know about the software, the more effective their tests will be at exposing bugs. — Boris Beizer

1136. Testers do it over and over. — Barb Newman

1137. Testers don’t like to break things; they like to dispel the illusion that things work. — Cem Kaner, James Bach, and Bret Pettichord

1138. Testers, as programmers, should have organized minds and should keep the user’s needs foremost. It seems natural, therefore, to group tests according the functionality that the users sees. It may seem natural but it can be, and often is, counterproductive; leading to excessive testing effort and therefore, buggier software. — Boris Beizer

1139. Testing a product is a learning process. — Brian Marick

1140. Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better. — Steve McConnell

1141. Testing delayed is testing denied. — Yogita Sahoo

1142. Testing is a key ingredient to self-esteem and pride of craftsmanship. A machinist who does not check her work with a micrometer is either a thief or a fool. A programmer who depends on the subsequent actions of others to catch his bugs has no pride, except, perhaps, the fleeting pride of cranking out vast quantities of untested and buggy software in a short time. — Boris Beizer

1143. Testing is a skill. While this may come as a surprise to some people it is a simple fact. — Mark Fewster and Dorothy Graham

1144. 0Testing is like playing pool. There’s real pool and there’s kiddie pool. In kiddie pool you hit the balls, and whatever pocket they fall into you claim as the intended pocket… There’s real testing and there’s kiddie testing. In real testing the outcome is predicted and documented before the test is run. — Boris Beizer

1145. Testing is never finished, only abandoned. — Encyclopedia of Software Engineering

1146. Testing is organized skepticism. — James Bach

1147. Testing is the process of comparing the invisible to the ambiguous, so as to avoid the unthinkable happening to the anonymous. — James Bach

1148. Testing only to end-user perceived requirements is like inspecting a building based on the work done by the interior decorator at the expense of the foundations, girders, and plumbing. — Boris Beizer

1149. Testing proves a programmer’s failure. Debugging is the programmer’s vindication. — Boris Beizer

1150. Testing resources should be allocated proportionately to the size and complexity of the code under test. Consequently, most testing effort is apportioned not to the functionality of the package (the stuff that usually works) but to that other 75% indirect stuff. The first consequence of a functionally meaningful organization to the tests is that 75% or more of the tests are constrained to an essentially arbitrary structure that cuts across too many components. A consequence of that is that you won’t be able to begin testing until almost all of the software is integrated and working. — Boris Beizer

1151. Testing starts at the beginning of the project, not at the end of the coding. We apply tests to assure the quality of the requirements. — Suzanne Robertson

1152. Testing to a 100% statement (also branch and predicate) coverage standard is a mandatory, minimum testing requirement because only by so doing can we assure that all the code has been tested at least once in its life. We must assure that because if we don’t we are guaranteed not to find the bugs that may be in the untested code. Not only is this common sense, but it is a fundamental axiom of testing — if you don’t test it, you won’t find the bugs in it. — Boris Beizer

1153. Testing to make statistically valid inferences about the software’s fitness for use in the field must be based on realistic tests. It is well known that tests designed to find bugs can not be used to make statistically valid inference about the software’s probability of failure in use. To do that we must have user behavioral data (called user profiles) and embed the software package in a simulator and drive that simulator with properly generated random events that statistically matches the user’s behavior. Such testing is realistic (in a statistical sense) but usually entails only 5% to 15% of the kind of tests we run to find bugs. — Boris Beizer

1154. Testing’s main purpose of is to discover bugs. In every test method there is an implicit assumption about the kinds of bugs you’re likely to find. If for example, you have lots of domain bugs, then domain testing is implied. Similarly, a weak front-end for command-driven software implies syntax testing. It would seem, therefore, reasonable to use the history of past bugs as a basis for selecting testing methods. It is, up to a point. — Boris Beizer

1155. Tests must be designed and tested: designed by a process no less rigourous and no less controlled than that used for code. — Boris Beizer

1156. That’s our advantage at Microsoft; we set the standards and we can change them. — Karen Hargrove, Microsoft (quoted in the Feb 1993 Unix Review editorial)

1157. That’s the thing about people who think they hate computers. What they really hate is lousy programmers. — Larry Niven and Jerry Pournelle

1158. That’s what’s cool about working with computers. They don’t argue, they remember everything and they don’t drink all your beer. — Paul Leary

1159. The (Analytical) Engine will always reject a wrong card by continually ringing a loud bell and stopping itself until supplied with the precise intellectual food it demands. — Charles Babbage

1160. The 11th commandment was “Thou Shalt Compute” or “Thou Shalt Not Compute” — I forget which. — Alan Perlis

1161. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor’s house. — Ken Thompson

1162. The act of focusing our mightiest intellectual resources on the elusive goal of goto-less programs has helped us get our minds off all those really tough and possibly unresolvable problems and issues with which today’s professional programmer would otherwise have to grapple. — John Brown

1163. The addition of any function not visualized in the original design will inevitably degenerate structure. Repairs also, will tend to cause deviation from structural regularity since, except under conditions of the strictest control, any repair or patch will be made in the simplest and quickest way. No search will be made for a fix that maintains structural integrity. — Belady and Lehman

1164. The adoption of programming languages has very often been somewhat accidental, and the emphasis has very often been on how easy it is to implement the programming language rather than on its actual merits and features. For instance, BASIC would never have surfaced because there was always a language better than BASIC for that purpose. That language was Joss, which predated BASIC and was beautiful. But BASIC happened to be on a GE timesharing system that was done by Dartmouth, and when GE decided to franchise that, it started spreading BASIC around just because it was there, not because it had any intrinsic merits whatsoever. This happens over and over again. The languages of Niklaus Wirth have spread wildly and widely because he has been one of the most conscientious documenters of languages and one of the earlier ones to do algorithmic languages using p-codes (pseudocodes) — the same kinds of things that we use. — Alan Kay

1165. The advance of technology is based on making it fit in so that you don’t really even notice it, so it’s part of everyday life. — Bill Gates

1166. The Analytical Engine weaves Algebraical patterns just as the Jacquard loom weaves flowers and leaves. — Ada Augusta, Countess of Lovelace, on Babbage’s Analytical Engine

1167. The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch. — Michael Armstrong

1168. The architect without the stonemason is not designing cathedrals, but castles in the air. — Gerald Weinberg

1169. The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos. — Edsger Dijkstra

1170. The average customer of the computing industry has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. — Edsger Dijkstra

1171. The beauty of mechanical problems is that they are often visible to the naked and untrained eye. If white smoke is rising from a disk drive, that is probably where the problem lies (unless your disk drive has just elected the new Pope). — John Bear

1172. The belief is still widespread in the computing community that C and its derivatives are programming languages — languages intended for people to write programs in. This is a regrettable misunderstanding. — Bertrand Meyer

1173. The best book on programming for the layman is “Alice in Wonderland.” But that’s because it’s the best book on anything for the layman. — Alan Perlis

1174. The best programmers are up to 28 times better than the worst programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field. — Robert L. Glass

1175. The best programmers write only easy programs. — Michael A. Jackson

1176. The best way to be ready for the future is to invent it. — John Sculley

1177. The best way to prepare to+be+a+programmer is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and fished out listings of their operating systems. — Bill Gates

1178. The better I get to know men, the more I find myself loving dogs. — Charles de Gaulle

1179. The big lie of computer security is that security improves by imposing complex passwords on users. In real life, people write down anything they can’t remember. Security is increased by designing for the way humans actually behave. — Jakob Nielsen

1180. The BLINK tag in HTML was a joke, okay? If we thought it would actually be used, we wouldn’t have written it! — Mark Andreessen

1181. The business of believing only what you have a right to believe is called risk management. — Tom de Marco and Timothy Lister

1182. The cell phone has transformed public places into giant phone-a-thons in which callers exist within narcissistic cocoons of private conversations. Like faxes, computer modems and other modern gadgets that have clogged out lives with phony urgency, cell phones represent the 20th Century’s escalation of imaginary need. We didn’t need cell phones until we had them. Clearly, cell phones cause not only a breakdown of courtesy, but the atrophy of basic skills. — Mary Schmich

1183. The cheapest, fastest, and most reliable components of a computer system are those that aren’t there. — Gordon Bell

1184. The city’s central computer told you? R2D2, you know better than to trust a strange computer! — C3PO

1185. The code done yesterday should be as good as you could make it yesterday. The fact that you know more today, and are more capable today, is good news about today, not bad news about yesterday. — Ron Jeffries

1186. The code for a computer system provides the ecology in which code is born, matures, and dies. A well-designed habitat allows for the successful evolution of all the components needed in a computer system. — Richard Pattis

1187. The code says what the program is doing, the remarks (comments) say what it is supposed to be doing. Debugging is reconciling the differences. — Tony Amico

1188. The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. — Edsger Dijkstra

1189. The computer can’t tell you the emotional story. It can give you the exact mathematical design, but what’s missing is the eyebrows. — Frank Zappa

1190. The computer is a moron. — Peter F. Drucker

1191. The computer is a powerful new metaphor for helping us to understand many aspects of the world. But, it enslaves the mind that has no other metaphors and few other resources to call on. The world is many things, and no single framework is large enough to contain them all, neither that of man’s science nor that of his poetry, neither that of calculating reason nor that of pure intuition. — Joseph Weizenbaum

1192. The computer is only a fast idiot, it has no imagination; it cannot originate action. It is, and will remain, only a tool to man. — Sign on the Univac computer exhibited at the 1964 New York World’s Fair

1193. The computer is the first metamedium, and as such it has degrees of freedom for representation and expression never before encountered and as yet barely investigated. — Alan Kay

1194. The computer is the ultimate polluter. Its feces are indistinguishable from the food it produces. — Alan Perlis

1195. The computer programmer is a creator of universes for which he alone is the lawgiver, universes of virtually unlimited complexity can be created in the form of computer programs. Moreover systems so formulated and elaborated act out their programmed scripts. They compliantly obey their laws and vividly exhibit their obedient behavior. No playwright, no stage director, no emperor, however powerful, has ever exercised such absolute authority to arrange a stage or a field of battle and to command such unswervingly dutiful actors or troops. — Joseph Weizenbaum

1196. The computer reminds me of Lon Chaney — it is the machine of a thousand faces. — Alan Perlis

1197. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology — the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. — H. Abelson and G. Sussman

1198. The computer should be doing the hard work. That’s what it’s paid to do, after all. — Larry Wall

1199. The computer world is like an intellectual Wild West, in which you can shoot anyone you wish with your ideas, if you’re willing to risk the consequences. — Paul Graham

1200. The computing field is always in need of new cliches. — Alan Perlis

1201. The Creation of the Universe was made possible by a grant from Texas Instruments. — PBS

1202. The cybernetic exchange between man, computer and algorithm is like a game of musical chairs: The frantic search for balance always leaves one of the three standing ill at ease. — Alan Perlis

1203. The danger from computers is not that they will eventually get as smart as men, but that we will meanwhile agree to meet them halfway. — Bernard Avishai

1204. The danger of standard process is that people will miss chances to take important shortcuts. — Tom DeMarco

1205. The deep paradox uncovered by AI research: the only way to deal efficiently with very complex problems is to move away from pure logic. Most of the time, reaching the right decision requires little reasoning. Expert systems are, thus, not about reasoning: they are about knowing Reasoning takes time, so we try to do it as seldom as possible. Instead we store the results of our reasoning for later reference. — Daniel Crevier

1206. The designer of a new kind of system must participate fully in the implementation. — Donald Knuth

1207. The designer of a new system must not only be the implementer and the first large-scale user; the designer should also write the first user manual. If I had not participated fully in all these activities, literally hundreds of improvements would never have been made, because I would never have thought of them or perceived why they were important. — Donald Knuth

1208. The difference between e-mail and regular mail is that computers handle e-mail, and computers never decide to come to work one day and shoot all the other computers. — Jamais Cascio

1209. The discipline of programming is most like sorcery. Both use precise language to instruct inanimate objects to do our bidding. Small mistakes in programs or spells can lead to completely unforseen behavior: e.g., see the story, “The Sorcerer’s Apprentice.” Neither study is easy: “…her [Galinda’s] early appetite for sorcery had waned once she’d heard what a grind it was to learn spells and, worse, to understand them.” — Richard Pattis

1210. The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under any representation. It is nonetheless highly precise and richly detailed. — Frederick P. Brooks, Jr.

1211. The essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. — Phil Wadler

1212. The evolution of languages: FORTRAN is a non-typed language. C is a weakly typed language. Ada is a strongly typed language. C++ is a strongly hyped language. — Ron Sercely

1213. The false confidence comes from running tens of thousands of tests, most of which won’t find bugs. Like it or not, we tend to be impressed by test quantities rather than quality. Even experienced testers get impressed. You can’t test for 1068 years, so you knock off a few billion tests over the next several months. But the tests you ran represent a statistically insignificant portion of the input space and no confidence, statistical or otherwise, is warranted. — Boris Beizer

1214. The fantastic element that explains the appeal of dungeon-clearing games to many programmers is neither the fire-breathing monsters nor the milkyskinned, semi-clad sirens; it is the experience of carrying out a task from start to finish without user requirements changing. — Thomas L. Holaday

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

1216. The fathers of the field had been pretty confusing: John von Neumann speculated about computers and the human brain in analogies sufficiently wild to be worthy of a medieval thinker, and Alan Turing thought about criteria to settle the question of whether machines can think, a question of which we now know that it is about as relevant as the question of whether submarines can swim. — Edsger Dijkstra

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

1218. The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. — Bill Gates

1219. The generation of random numbers is too important to be left to chance. — Robert Coveyou

1220. The global village is not created by the motor car or even by the airplane. It’s created by instant electronic information movement. — Marshall Mcluhan

1221. The great strength of computers is that they can reliably manipulate vast amounts of data very quickly. Their great weakness is that they don’t have a clue as to what any of that data actually means. — Stephen Cass

1222. The great thing about a computer notebook is that no matter how much you stuff into it, it doesn’t get bigger or heavier. — Bill Gates

1223. The greatest challenge for the Information Age manager is to create an organization that can share knowledge — Thomas A. Steward

1224. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification. — Frederick P. Brooks

1225. The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements… No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later. — Fred Brooks

1226. The hardest thing is to go to sleep at night, when there are so many urgent things needing to be done. A huge gap exists between what we know is possible with today’s machines and what we have so far been able to finish. — Donald Knuth

1227. The honest truth is that having a lot of people staring at the code does not find the really nasty bugs. The really nasty bugs are found by a couple of really smart people who just kill themselves. — Bill Joy

1228. The idea that a single method should govern even two different projects is highly suspect: the differences between projects are much more important than the similarities. — Tom DeMarco

1229. The illusion of progress can be achieved by simply rearranging the terms of description so that new acronyms are created. — Scott Smith

1230. The important point is that the cost of adding a feature isn’t just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web. The trick is to pick the features that don’t fight each other. — J. Carmack

1231. The inherent complexity of a software system is related to the problem it is trying to solve. The actual complexity is related to the size and structure of the software system as actually built. The difference is a measure of the inability to match the solution to the problem. — Kevlin Henney

1232. The inside of a computer is as dumb as hell but it goes like mad! — Richard Feynman

1233. The Internet is a telephone system that’s gotten uppity. — Clifford Stoll

1234. The Internet is like a giant jellyfish. You can’t step on it. You can’t go around it. You’ve got to get through it. — John Evans

1235. The Internet is so big, so powerful and pointless that for some people it is a complete substitute for life. — Andrew Brown

1236. The Internet is the Viagra of big business. — Jack Welch

1237. The Internet is the world’s largest library. It’s just that all the books are on the floor. — John Allen Paulos

1238. The Internet treats censorship as a malfunction and routes around it. — John Perry Barlow

1239. The job of the average manager requires a shift in focus every few minutes. The job of the average software developer requires that the developer not shift focus more often than every few hours. — Steve C. McConnell

1240. The key role of middle management is reinvention. — Tom DeMarco

1241. The key to understanding recursion is to begin by understanding recursion. The rest is easy. — Koenig and Moo

1242. The last project generated a ton of paper and it was still a disaster, so this project will have to generate two tons. — Lister and DeMarco

1243. The less you know about computers the more you want Microsoft! — 1996 Microsoft ad campaign

1244. The lifeblood of our business is our R&D spend. There’s nothing that flows through a pipe or down a wire or anything else. We have to continuously create new innovation that lets people do something they didn’t think they could do the day before. — Steve Ballmer

1245. The Linux philosophy is “Laugh in the face of danger.” Oops. Wrong One. “Do it yourself.” Yes, that’s it. — Linus Torvalds

1246. The Lord’s Prayer is 66 words, the Gettysburg Address is 286 words, there are 1,322 words in the Declaration of Independence, but US government regulations on the sale of cabbage total 26,911 words. — the National Review

1247. The lowest common denominator in being digital is not your operating system, modem, or model of computer. It’s a tiny piece of plastic, designed decades ago by Bell Labs’ Charles Krumreich, Edwin Hardesty, and company, who thought they were making an inconspicuous plug for a few telephone handsets. Not in their wildest dreams was Registered Jack 11 — a modular connector more commonly know as the RJ-11 — meant to be plugged and unplugged so many times, by so many people, for so many reasons, all over the world. How many RJ-11 clips have you broken? I am astonished that something that probably costs less than a penny separates me from the Net so often. Mind you, this is caused not just by normal wear and tear, but by a design that causes the small plastic clip on the male connector to catch on various articles when you pull the cord out of a briefcase. The half-life of an RJ-11 plug on the road must be less than a month. — Nicholas Negroponte

1248. The Macintosh uses an experimental pointing device called a “mouse.” There is no evidence that people want to use these things. What businessman knows about point sizes on typefaces or the value of variable point sizes ? Who out there in the general marketplace even knows what a “font” is ? The whole concept and attitude towards icons and hieroglyphs is actually counterrevolutionary — it’s a language that is hardly “user friendly.” This type of machine was developed by hardware hackers working out of Xerox’s Palo Alto Research Center. It has yet to find popular success. There seems to be some mysterious user resistance to this type of machine. — John C. Dvorak on why the Macintosh would fail, San Francisco Examiner, 2/19/1984

1249. The main purpose of testing is to expose bugs and only secondarily to demonstrate that the software works (to the extent that such a demonstration is theoretically and/or practically possible). Users have very little understanding of the software’s internals and as a consequence, most of their “tests” are very gentle and grossly repetitive. Users don’t want a test, they want a demo. A good demo is at most 15% of the tests we should run. The user should be invited to exercise (but not test) a prototype so that we know that what we build is really what was wanted. But exercising a prototype is hardly the same as testing software. — Boris Beizer

1250. The majority of programmers aren’t really looking for flexibility. Most languages that enjoy huge success seem to do so not because they’re flexible, but because they do one particular thing extremely well. Like Fortran for fast number-crunching in its day, or Perl for regexps, or C++ for compatibility with C, or C for … well, C’s the exception that proves the rule. — Tim Peters

1251. The memory management on the PowerPC can be used to frighten small children. — Linus Torvalds

1252. The modern view is to code in the cleanest, simplest, most straightforward manner you can. You then measure the software’s actual behavior using statistically valid user profiles, find the hot spots, if any, and then tweak the few lines of code that may be causing problems. Trying to tweak code blindly is an out-of-date habit that should be discarded. — Boris Beizer

1253. The most damaging phrase in the language is, “It’s always been done that way.” — Rear Admiral Grace Hopper

1254. The most important computer is the one that rages in our skulls and ever seeks that satisfactory external emulator. The standardization of real computers would be a disaster — and so it probably won’t happen. — Alan Perlis

1255. The most important factor in software work is not the tools and techniques used by the programmers but rather the quality of the programmers themselves. — Robert L. Glass

1256. The most important single aspect of software development is to be clear about what you are trying to build. — Bjarne Stroustrup

1257. The most important thing in the programming language is the name. A language will not succeed without a good name. I have recently invented a very good name and now I am looking for a suitable language. — Donald Knuth

1258. In God we trust; everyone else must write unit tests — Henning Troelsen (via Tracy Monteith)

1259. The difference between craft and engineering is the difference between the questions “does this feature work?” and “how often will this feature work?” If you are systematically asking the second question, then you are practicing engineering. — Corey L

1260. Infinite performance requires infinite investment. — Corey L

1261. The scaffolding is not the building. — Corey L

1262. A Feature Factory of Lean Design For Six Sigma teams would be an unstoppable industrial juggernaut. — Corey L

1263. Means never, ever, have any intrinsic value. We do things because we value the result. — Corey L

1264. Our challenge with the EEH is to strike a balance between what’d we’d like people to adopt, and what they’re likely to adopt. — Corey L

1265. The difference between theory and practice is that in theory they are the same, but in practice they are different. — Christopher Crammond

— — — — — — — — — — — — — — — — — — — — — — — — — — — —