RR27vBEp

1%
2Simple things should be simple, complex things should be possible.
3  The Wiki Way: Quick Collaboration on the Web, Bo Leuf, Ward
4  Cunningham
5%
6Simplicity is the soul of efficiency.
7  Austin Freeman
8%
9I have yet to see any problem, however complicated, which, when you
10looked at it in the right way, did not become still more complicated.
11  Poul Anderson
12%
13... with proper design, the features come cheaply. This approach
14is arduous, but continues to succeed.
15  Dennis Ritchie
16%
17It's hard enough to find an error in your code when you're looking
18for it; it's even harder when you've assumed your code is error-free.
19  Steve McConnell
20%
21You're bound to be unhappy if you optimize everything.
22  Donald Knuth
23%
24Computers are good at following instructions, but not at reading
25your mind.
26  Donald Knuth
27%
28A good way to stay flexible is to write less code.
29  Pragmatic Programmer
30%
31Measuring programming progress by lines of code is like measuring
32aircraft building progress by weight.
33  Bill Gates
34%
35But in our enthusiasm, we could not resist a radical overhaul of
36the system, in which all of its major weaknesses have been exposed,
37analyzed, and replaced with new weaknesses.
38  Bruce Leverett
39%
40How does a project get to be a year late?... One day at a time.
41  Fred Brooks
42%
43The best performance improvement is the transition from the
44nonworking state to the working state.
45  John Ousterhout
46%
47If the code and the comments disagree, then both are probably
48wrong.
49  attributed to Norm Schryer
50%
51... nearly everybody is convinced that every style but their own
52is ugly and unreadable. Leave out the but their own and they're
53probably right...
54  Jerry Coffin (on indentation)
55%
56Ugly programs are like ugly suspension bridges: they're much
57more liable to collapse than pretty ones, because the way humans
58(especially engineer-humans) perceive beauty is intimately related
59to our ability to process and understand complexity.
60  Eric S. Raymond
61%
62Just another day writing tomorrow's legacy code.  % Coding for
63a living is learning for a living.
64  Paul Robinson
65%
66If you can't write clearly, you probably don't think nearly as
67well as you think.
68  Kurt Vonnegut
69%
70It is imperative in science to doubt. It is absolutely necessary,
71for progress in science, to have uncertainty as a fundamental part
72of your inner nature. To make progress in understanding, we must
73remain modest and allow that we do not know.
74  Richard Feynman
75%
76You never actually find a perfect answer to a problem. You just
77find the answer that has the fewest problems.
78  James Gosling
79%
80A good programmer is someone who always looks both ways before
81crossing a one-way street.
82  Doug Linder
83%
84A good scientist is a person with original ideas. A good engineer
85is a person who makes a design that works with as few original
86ideas as possible.
87  Freeman Dyson
88%
89The hardest problem in computer science is not begin an opinionated
90jerk about everything.
91  Nick Takayama
92%
93Making hackers work in a noisy, distracting environment is like
94having a paint factory where the air is full of soot.
95  Paul Graham
96%
97In carpentry, you measure twice and cut once. In software
98development, you never measure and make cuts until you run out
99of time.
100  Adam Morse
101%
102A Fallacy of Software: If it works, and we don't change anything,
103it will keep working.
104  Jessica Kerr
105%
106Writing software as if we are the only person that ever has to
107comprehend it is one of the biggest mistakes and false assumptions
108that can be made.
109  Karolina Szczur
110%
111Your code has two users: the computer, and every other person
112who has to work with what you wrote.
113  Sam Morgan
114%
115In a complex system you don't get to change just one thing - ever.
116  Michael Feathers
117%
118A distributed system is one in which the failure of a computer
119you didn’t even know existed can render your own computer unusable.
120  Leslie Lamport
121%
122Make sure you know what's inside the box before trying to think
123outside of it.
124%
125The cure for boredom is curiosity. There is no
126cure for curiosity.
127  Dorothy Parker
128%
129Simplicity is prerequisite for reliability
130  Edsger W.Dijkstra
131%
132Rules of Optimization:
133 Rule 1: Don't do it.  Rule 2 (for experts only): Don't do it yet.
134  M.A. Jackson
135%
136More computing sins are committed in the name of efficiency
137(without necessarily achieving it) than for any other single reason -
138including blind stupidity.
139  W.A. Wulf
140%
141The competent programmer is fully aware of the strictly limited
142size of his own skull; therefore he approaches the programming task
143in full humility, and among other things he avoids clever tricks
144like the plague.
145  Edsger Dijkstra
146%
147Correctness is clearly the prime quality. If a system does
148not do what it is supposed to do, then everything else about it
149matters little.
150  Bertrand Meyer
151%
152 An API that isn't comprehensible isn't usable.
153  James Gosling
154%
155The bearing of a child takes nine months, no matter how many
156women are assigned. Many software tasks have this characteristic
157because of the sequential nature of debugging.
158   Fred Brooks
159%
160Hofstadter's Law: It always takes longer than you expect, even
161when you take into account Hofstadter's Law.
162%
163Copy and paste is a design error.
164  David Parnas
165%
166One principle problem of educating software engineers is that
167they will not use a new method until they believe it works and,
168more importantly, that they will not believe the method will work
169until they see it for themselves.
170  Humphrey, W.S., "The Personal Software Process"
171%
172Eagleson's law: Any code of your own that you haven't looked at for
173six or more months might as well have been written by someone else.
174%
175Any fool can use a computer. Many do.
176  Ted Nelson
177%
178Incorrect documentation is often worse than no documentation.
179  Bertrand Meyer
180%
181Debugging is twice as hard as writing the code in the first place.
182Therefore, if you write the code as cleverly as possible, you are,
183by definition, not smart enough to debug it.
184  Brian W. Kernighan
185%
186It's not at all important to get it right the first time. It's
187vitally important to get it right the last time.
188  Andrew Hunt and David Thomas
189%
190Make everything as simple as possible, but not simpler.
191  Albert Einstein
192%
193First, solve the problem. Then, write the code.
194  John Johnson
195%
196Plan to throw one (implementation) away; you will, anyhow.
197  Fred Brooks
198%
199Remember that there is no code faster than no code.
200   Taligent's Guide to Designing Programs
201%
202More good code has been written in languages denounced as bad
203than in languages proclaimed wonderful.
204   Bjarne Stroustrup, The Design and Evolution of C++ (1994)
205%
206Smart data structures and dumb code works a lot better than the
207other way around.
208   Eric S. Raymond, The Cathedral and the Bazaar
209%
210It's hard to read through a book on the principles of magic
211without glancing at the cover periodically to make sure it isn't
212a book on software design.
213   Bruce Tognazzini
214%
215A language that doesn't have everything is actually easier to
216program in than some that do.
217   Dennis Ritchie
218%
219... the purpose of abstraction is not to be vague, but to create
220a new semantic level in which one can be absolutely precise.
221   Edsger W. Dijkstra, "The Humble Programmer" (1972)
222%
223... the cost of adding a feature isn't just the time it takes
224to code it. The cost also includes the addition of an obstacle to
225future expansion.  ...The trick is to pick the features that don't
226fight each other.
227   John Carmack
228%
229Increasingly, people seem to misinterpret complexity as
230sophistication, which is baffling   - the incomprehensible should
231cause suspicion rather than admiration.
232   Niklaus Wirth
233%
234One of the most dangerous (and evil) things ever injected into
235the project world is the notion of process maturity. Process
236maturity is for replicable manufacturing contexts. Projects
237are one-time shots. Replicability is never the primary issue on
238one-time shots. More evil than good has come from the notion that we
239should stick to the methodology. This is a recipe for non-adaptive
240death. I'd rather die by commission.
241   David Schmaltz
242%
243The fundamental problem with program maintenance is that fixing
244a defect has a substantial (20-50 percent) chance of introducing
245another. So the whole process is two steps forward and one step
246back..
247     Fred Brooks
248%
249The difference between a good and a poor architect is that the poor
250architect succumbs to every temptation and the good one resists it.
251   Ludwig Wittgenstein
252%
253Refactoring provides enough energy to a system for it to relax
254into a new and more comfortable state, a new local minimum.
255   Kevlin Henney, "The Imperial Clothing Crisis" (2002)
256%
257Beauty is more important in computing than anywhere else in
258technology because software is so complicated. Beauty is the ultimate
259defense against complexity.
260   David Gelernter, Machine Beauty, Basic Books (1998)
261%
262Fools ignore complexity; pragmatists suffer it; experts avoid it;
263geniuses remove it.
264   Alan Perlis
265%
266...Simplifications have had a much greater long-range scientific
267impact than individual feats of ingenuity. .... Simplicity and
268elegance are unpopular because they require hard work and discipline
269to achieve and education to be appreciated.
270   Edsger W. Dijkstra
271%
272Any intelligent fool can make things bigger, more complex, and
273more violent. It takes a touch of genius - and a lot of courage -
274to move in the opposite direction.
275   Albert Einstein
276%
277The structure of a system reflects the structure of the
278organization that built it.
279   Mel Conway
280%
281The unavoidable price of reliability is simplicity.
282   C.A.R. Hoare
283%
284Controlling complexity is the essence of computer programming.
285   Brian Kernighan
286%
287Complexity is a sign of technical immaturity. Simplicity of use
288is the real sign of a well design product whether it is an ATM or
289a Patriot missile.
290   Daniel T. Ling
291%
292Every good work of software starts by scratching a developer's
293personal itch.  %
294Simplicity does not precede complexity, but
295follows it.
296   Alan J. Perlis
297%
298Computer Science is the first engineering discipline in which the
299complexity of the objects created is limited solely by the skill
300of the creator, and not by the strength of raw materials.
301   B. Reid
302%
303Technical skill is mastery of complexity, while creativity is
304mastery of simplicity.
305   E. Christopher Zeeman
306%
307Architect: Someone who knows the difference between that which
308could be done and that which should be done.
309   Larry McVoy
310%
311If the automobile had followed the same development cycle as the
312computer, a Rolls-Royce would today cost $100, get a million miles
313per gallon, and explode once a year, killing everyone inside.
314   Robert X. Cringely
315%
316There's an old story about the person who wished his computer
317were as easy to use as his telephone. That wish has come true,
318since I no longer know how to use my telephone.
319   Bjarne Stroustrup
320%
321A common mistake that people make when trying to design something
322completely foolproof was to underestimate the ingenuity of complete
323fools.
324   Douglas Adams
325%
326If our designs are failing due to the constant rain of changing
327requirements, it is our designs that are at fault. We must somehow
328find a way to make our designs resilient to such changes and protect
329them from rotting.
330   Robert C. Martin
331%
332If you cannot grok the overall structure of a program while taking
333a shower, you are not ready to code it.
334   Richard Pattis
335%
336How good the design is doesn't matter near as much as whether the
337design is getting better or worse. If it is getting better, day by
338day, I can live with it forever. If it is getting worse, I will die.
339   Kent Beck
340%
341 Good programmers know what to write. Great ones know what to rewrite
342 (and reuse).
343%
344Nothing resolves design issues like an implementation.
345   J. D. Horton
346%
347By the time [the Leaning Tower of Pisa] was ten percent built,
348everyone knew it would be a total disaster. But the investment was
349so big they felt compelled to go on. Since its completion, it cost
350a fortune to maintain and is still in danger of collapsing. There
351are no plans to replace it, since it was never needed in the first
352place. I expect every installation has its own pet software which
353is analogous to the above.
354   Ken Iverson
355%
356In theory, there is no difference between theory and practice. But,
357in practice, there is.
358   Jan L. A. van de Snepscheut
359%
360If you lie to the compiler, it will get its revenge.
361  Henry Spencer
362%
363Trying to outsmart a compiler defeats much of the purpose of
364using one.
365  Kernighan and Plauger, The Elements of Programming Style
366%
367Once a new technology starts rolling, if you're not part of the
368steamroller, you're part of the road.
369  Stewart Brand
370%
371Get into a rut early: Do the same process the same way. Accumulate
372idioms. Standardize. The only difference(!) between Shakespeare and
373you was the size of his idiom list - not the size of his vocabulary.
374%
375Just because the standard provides a cliff in front of you,
376you are not necessarily required to jump off it.
377  Norman Diamond
378%
379If you have a procedure with ten parameters, you probably
380missed some.  %
381There are two ways to write error-free programs;
382only the third works.
383  Alan J. Perlis
384%
385Should array indices start at 0 or 1? My compromise of 0.5 was
386rejected without, I thought, proper consideration.
387  Stan Kelly-Bootle
388%
389Good engineering is not primarily making good decisions, it's
390seeking good feedback which lets you quickly discard bad decisions.
391  Kent Beck
392%
393Point of view is worth 80 IQ points.
394  Alan Kay
395%
396We just have to accept that developer skill is a far more
397significant variable than language choice or methodological nuances.
398  Michael Feathers
399%
400Testing does not cost, it pays, both during development and over
401the system’s lifecycle.
402  Mary Poppendieck
403%
404If your tests look cumbersome and complex, it reflects on the
405design of your system.
406  Jez Humble and Dave Farley
407%
408 Perfection (in design) is achieved not when there is nothing more
409 to add, but rather when there is nothing more to take away.
410    Antoine de Saint-Exupery
411%
412I did say something along the lines of C makes it easy to shoot
413yourself in the foot; C++ makes it harder, but when you do, it
414blows your whole leg off.
415  Bjarne Stroustrup
416%
417UNIX is simple. It just takes a genius to understand its
418simplicity.
419  Dennis Ritchie
420%
421When someone says, I want a programming language in which I need
422only say what I want done, give him a lollipop.
423  Alan Perlis
424%
425You can't have great software without a great team, and most
426software teams behave like dysfunctional families.
427  Jim McCarthy
428%
429That's the thing about people who think they hate computers.
430What they really hate is lousy programmers.
431  Larry Niven and Jerry Pournelle Oath of Fealty
432%
433Einstein argued that there must be simplified explanations of
434nature, because God is not capricious or arbitrary. No such faith
435comforts the software engineer.
436  Fred Brooks, Jr.
437%
438As we said in the preface to the first edition, C wears well
439as one's experience with it grows. With a decade more experience,
440we still feel that way.
441  Brian Kernighan and Dennis Ritchie
442%
443Optimization hinders evolution.  % C++ tries to guard against
444Murphy, not Machiavelli.
445  Damian Conway
446%
447I have always found that plans are useless, but planning is
448indispensable.
449  Dwight Eisenhower
450%
451 Any fool can write code that a computer can understand. Good
452 programmers write code that humans can understand.
453    Martin Fowler
454%
455Perl is another example of filling a tiny, short-term need,
456and then being a real problem in the longer term.
457  Alan Kay
458%
459It is practically impossible to teach good programming style
460to students that have had prior exposure to Basic; as potential
461programmers they are mentally mutilated beyond hope of regeneration.
462  Edsger Dijkstra
463%
464Comparing to another activity is useful if it helps you formulate
465questions, it's dangerous when you use it to justify answers.
466  Martin Fowler
467%
468There will always be things we wish to say in our programs that in
469all known languages can only be said poorly.
470%
471Every program is a part of some other program and rarely fits.
472%
473Style distinguishes excellence from accomplishment.
474  James Coplien
475%
476Every program has (at least) two purposes: the one for which it
477was written, and another for which it wasn't.
478  Alan J. Perlis
479%
480The most amazing achievement of the computer software industry
481is its continuing cancellation of the steady and staggering gains
482made by the computer hardware industry.
483  Henry Petroski
484%
485Technology is dominated by two types of people: Those who
486understand what they do not manage. Those who manage what they do
487not understand.
488  Putt's Law
489%
490The perfect project plan is possible if one first documents a
491list of all the unknowns.
492  Bill Langley
493%
494Program testing can be used to show the presence of bugs, but
495never to show their absence!
496    Edsger Dijkstra
497%
498There's no obfuscated Perl contest because it's pointless.
499  Jeff Polk
500%
501Software and cathedrals are much the same - first we build them,
502then we pray.
503  Anonymous
504%
505If debugging is the process of removing bugs, then programming
506must be the process of putting them in.
507  Edsger Dijkstra
508%
509No matter how slick the demo is in rehearsal, when you do it in
510front of a live audience the probability of a flawless presentation
511is inversely proportional to the number of people watching, raised
512to the power of the amount of money involved.
513  Mark Gibbs
514%
515It is easier to write an incorrect program than understand a
516correct one.  %
517If you need more than 3 levels of indentation,
518you're screwed anyway, and should fix your program.
519  Linux 1.3.53 Coding Style documentation
520%
521A Perl program is correct if it gets the job done before your
522boss fires you.
523  Larry Wall
524%
525I have a pretty major problem with a language where one of the
526most common variables has the name $_
527  Brian Hook, about PERL
528%
529Testing is the process of comparing the invisible to the ambiguous,
530so as to avoid the unthinkable happening to the anonymous.
531    James Bach
532%
533The programmer, like the poet, works only slightly removed from
534pure thought-stuff. He builds his castles in the air, from air,
535creating by exertion of the imagination. Few media of creation are
536so flexible, so easy to polish and rework, so readily capable of
537realizing grand conceptual structures. (This very tractability has
538its own problems.)
539  Fred Brooks
540%
541The evolution of languages: FORTRAN is a non-typed language. C
542is a weakly typed language. Ada is a strongly typed language. C++
543is a strongly hyped language.
544  Ron Sercely
545%
546He who hasn't hacked assembly language as a youth has no heart. He
547who does as an adult has no brain.
548  John Moore
549%
550BASIC - A programming language. Related to certain social diseases
551in that those who have it will not admit it in polite company.
552  Anonymous
553%
554With enough eyes, all bugs are shallow.
555  Eric S. Raymond
556%
557The camel has evolved to be relatively self-sufficient. On
558the other hand, the camel has not evolved to smell good. Neither
559has Perl.
560  Larry Wall
561%
562Don't get suckered in by the comments ... they can be terribly
563misleading.
564  Dave Storer
565%
566We know about as much about software quality problems as they
567knew about the Black Plague in the 1600s. We've seen the victims'
568agonies and helped burn the corpses. We don't know what causes it;
569we don't really know if there is only one disease. We just suffer
570and keep pouring our sewage into our water supply.
571   Tom Van Vleck
572%
573If something is worth doing once, it's worth building a tool
574to do it.  %
575If you think good architecture is expensive, try bad
576architecture.
577   Brian Foote and Joseph Yoder
578%
579When we use a language, we should commit ourselves to knowing it,
580being able to read it, and writing it idiomatically.
581  Ron Jeffries
582%
583 Beware of bugs in the above code; I have only proved it correct,
584 not tried it.
585  Donald Knuth
586%
587The ideal engineer is a composite ... he is not a scientist,
588he is not a mathematician, he is not a sociologist, or a writer;
589but he may use the knowledge and techniques of any or all of these
590disciplines in solving engineering problems.
591  N. W. Dougherty
592%
593One of the great skills in using any language is knowing what
594not to use, what not to say. ... There's that simplicity thing again.
595  Ron Jeffries
596%
597Good engineering is characterized by gradual, stepwise refinement
598of products that yields increased performance under given constraints
599and with given resources.
600  Niklaus Wirth
601%
602Programming languages should be designed not by piling feature
603on top of feature, but by removing the weaknesses and restrictions
604that make additional features appear necessary.
605   Revised Report on the Algorithmic Language Scheme
606%
607A designer can mull over complicated designs for months. Then
608suddenly the simple, elegant, beautiful solution occurs to him. When
609it happens to you, it feels as if God is talking! And maybe He is.
610  Leo Frankowski (in The Cross-Time Engineer)
611%
612It should be noted that no ethically-trained software engineer
613would ever consent to write a DestroyBaghdad procedure. Basic
614professional ethics would instead require him to write a DestroyCity
615procedure, to which Baghdad could be given as a parameter.
616  Nathaniel S. Borenstein
617%
618The problem with using C++ ... is that there's already a strong
619tendency in the language to require you to know everything before
620you can do anything.
621  Larry Wall
622%
623Unix was not designed to stop people from doing stupid things,
624because that would also stop them from doing clever things.
625  Doug Gwyn
626%
627We try to solve the problem by rushing through the design process
628so that enough time is left at the end of the project to uncover the
629errors that were made because we rushed through the design process.
630    Glenford Myers
631%
632First you listen to the users; then you ignore them.
633  Ken Arnold
634%
635The hardest part of design ... is keeping features out.
636  Donald Norman
637%
638Computers are high-speed idiots, programmed by low-speed idiots.
639%
640You know you're on the right track with code changes when you
641spend the majority of your time deleting code.
642%
643The key to understanding recursion is to begin by understanding
644recursion. The rest is easy.
645   Koenig/Moo, Accelerated C++
646%
647Always code as if the person who ends up maintaining your code will
648be a violent psychopath who knows where you live.
649%
650Programs should
651be written and polished until they acquire publication quality.
652  Niklaus Wirth
653%
654... programming requires more concentration than other
655activities. It's the reason programmers get upset about 'quick
656interruptions' - such interruptions are tantamount to asking a
657juggler to keep three balls in the air and hold your groceries
658at the same time."   Steve McConnell, Code Complete %
659Avoiding
660complexity reduces bugs.
661  Linus Torvalds
662%
663In a room full of top software designers, if two agree on the
664same thing, that's a majority.
665  Bill Curtis
666%
667If at first you don't succeed, call it version 1.0.
668  Pat Rice
669%
670It's harder than you might think to squander millions of dollars,
671but a flawed software development process is a tool well suited to
672the job.
673  Alan Cooper
674%
675One: demonstrations always crash. And two: the probability of them
676crashing goes up exponentially with the number of people watching.
677  Steve Jobs
678%
679About 90 percent of the downtime comes from, at most, 10 percent
680of the defects.   Barry Boehm %
681Time pressure gradually corrupts an
682engineer's standard of quality and perfection. It has a detrimental
683effect on people as well as products.
684   Niklaus Wirth
685%
686In a software project team of 10, there are probably 3 people
687who produce enough defects to make them net negative producers.
688   Gordon Schul
689%
690It's not the prevention of bugs but the recovery the ability to
691gracefully exterminate them -- that counts.
692  Victoria Livschitz
693%
694When debugging, novices insert corrective code; experts remove
695defective code.   Richard Pattis %
696Product quality has almost
697nothing to do with defects or their lack.
698  Tom DeMarco
699%
700Every big computing disaster has come from taking too many ideas
701and putting them in one place.
702   Gordon Bell
703%
704There has never been an unexpectedly short debugging period in
705the history of computers.
706   Steven Levy
707%
708It has been discovered that C++ provides a remarkable facility
709for concealing the trival details of a program such as where its
710bugs are.
711  David Keppel
712%
713Whoever thought of putting coders in noise-transparent cubicles
714needs to be beaten with a cluebat.
715  Anonymous Slashdotter
716%
717 Using Unix is the computing equivalent of listening only to music
718 by David Cassidy.
719  Rob Pike
720%
721Conceptual integrity is the most important consideration in
722system design.
723  Fred Brooks, "The Mythical Man-Month"
724%
725The belief that complex systems require armies of designers
726and programmers is wrong. A system that is not understood in its
727entirety, or at least to a significant degree of detail by a single
728individual, should probably not be built.
729  Niklaus Wirth
730%
731Experience doesn't necessarily teach anything.
732  Gerald M. Weinberg, "Understanding the Professional Programmer"
733%
734No matter what the problem is, it's always a people problem.
735  Gerald M. Weinberg
736%
737I think there is a world market for maybe five computers
738  Thomas Watson, Chairman of IBM, 1943
739%
740There is no reason why anyone would want a computer in the home.
741  Ken Olson, Present, Chairman and founder of Digital Equipment
742  Corporation, 1977
743%
744But what... is it good for?
745  Engineer at the Advanced Computing Systems division of IBM,
746  commenting on the microchip, 1968
747%
748I have traveled the length and breadth of this country and talked
749with the best people, and I can assure you that data processing is
750a fad that won't last out the year.
751  Editor in charge of business books for Prentice Hall, 1957
752%
753While a calculator on the ENIAC is equipped with 10000 vacuum
754tubes and weighs 30 tons, computers of the future may have only
7551000 vacuum tubes and weigh only 1.5 tons.
756  Popular mechanics, 1949
757%
758Hiring people to write code to sell is not the same as hiring
759people to design and build durable, usable, dependable software.
760  Larry Constantine
761%
762If we play genie and grant client wishes, we are apt to construct
763castles of code in the air.
764  Larry Constantine
765%
766In fast moving markets, adaptation is significantly more important
767than optimization.
768  Larry Constantine
769%
770A primary cause of complexity is that software vendors uncritically
771adopt almost any feature that users want.
772  Niklaus Wirth
773%
774The best meetings get real work done. When your people learn that
775your meetings actually accomplish something, they will stop making
776excuses to be elsewhere.
777  Larry Constantine
778%
779A dynamic duo who work well together can be worth any three people
780working in isolation.
781  Larry Constantine
782%
783Prolific programmers contribute to certain disaster.
784  Niklaus Wirth
785%
786Wirth's law: Software gets slower faster than hardware gets faster.
787  Niklaus Wirth
788%
789If builders built buildings the way programmers wrote programs,
790then the first woodpecker that came along would destroy civilisation.
791  Gerald Weinberg
792%
793Documentation is the castor oil of programming. Managers think
794it is good for programmers and programmers hate it!
795  Gerald Weinberg
796%
797The best way to get a project done faster is to start sooner.
798  Jim Highsmith
799%
800Managers often form a [programming] team which by any reasonable
801judgment cannot perform the designated task in the allotted
802time. Inevitably the team is given an extension when the time
803limit is reached and the reality must be faced. Had it been faced
804earlier, the work could probably have been organized differently -
805in recognition of the longer schedule - and thus produced, in the
806end, more quickly.
807  Gerald Weinberg
808%
809Programming can be fun, so can cryptography; however they should
810not be combined.
811  Kreitzberg and Shneiderman
812%
813Let us change our traditional attitude to the construction of
814programs. Instead of imagining that our main task is to instruct
815a computer what to to, let us concentrate rather on explaining to
816human beings what we want a computer to do.
817  Donald Knuth
818%
819Good code is its own best documentation. As you're about to add
820a comment, ask yourself, How can I improve the code so that this
821comment isn't needed?' Improve the code and then document it to
822make it even clearer.
823  Steve McConnell
824%
825The job of the average manager requires a shift in focus every
826few minutes. The job of the average software developer requires
827that the developer not shift focus more often than every few hours.
828  Steve McConnell
829%
830It's OK to figure out murder mysteries, but you shouldn't need
831to figure out code. You should be able to read it.
832  Steve McConnell
833%
834Testing by itself does not improve software quality. Test results
835are an indicator of quality, but in and of themselves, they don't
836improve it. Trying to improve software quality by increasing the
837amount of testing is like trying to lose weight by weighing yourself
838more often. What you eat before you step onto the scale determines
839how much you will weigh, and the software development techniques
840you use determine how many errors testing will find. If you want
841to lose weight, don't buy a new scale; change your diet. If you
842want to improve your software, don't test more; develop better.
843  Steve McConnell
844%
845A brute force solution that works is better than an elegant
846solution that doesn't work.
847  Steve McConnell
848%
849Good visual layout shows the logical structure of a program.
850  Steve McConnell
851%
852Even when you have skilled, motivated, hard-working people,
853the wrong team structure can undercut their efforts instead of
854catapulting them to success.  A poor team structure can increase
855development time, reduce quality, damage morale, increase turnover,
856and ultimately lead to project cancellation.
857  Steve McConnell
858%
859Brooks Law: Adding manpower to a late software project makes it
860later!
861%
862It's better to wait for a productive programmer to become
863available than it is to wait for the first available programmer to
864become productive.
865  Steve McConnell
866%
867Software projects fail for one of two general reasons: the
868project team lacks the knowledge to conduct a software project
869successfully, or the project team lacks the resolve to conduct a
870project effectively.
871  Steve McConnell
872%
873In software, the chain isn't as strong as its weakest link;
874it's as weak as all the weak links multiplied together.
875  Steve McConnell
876%
877... the designer of a new system must not only be the implementor
878and the first large-scale user; the designer should also write the
879first user manual. ...If I had not participated fully in all these
880activities, literally hundreds of improvements would never have
881been made, because I would never have thought of them or perceived
882why they were important.
883  Donald Knuth
884%
885An organization that treats its programmers as morons will soon
886have programmers that are willing and able to act like morons only.
887  Bjarne Stroustrup
888%
889Design and programming are human activities; forget that and all
890is lost.
891  Bjarne Stroustrup
892%
893Before software can be reusable it first has to be usable.
894  Ralph Johnson
895%
896If you think your management doesn't know what it's doing or
897that your organisation turns out low-quality software crap that
898embarrasses you, then leave.
899  Edward Yourdon
900%
901The most important single aspect of software development is to
902be clear about what you are trying to build.
903  Bjarne Stroustrup
904%
905Most of you are familiar with the virtues of a programmer. There
906are three, of course: laziness, impatience, and hubris.
907  Larry Wall
908%
909We must not forget that the wheel is reinvented so often because it
910is a very good idea; I've learned to worry more about the soundness
911of ideas that were invented only once.
912  David L. Parnas (Why Software Jewels are Rare, IEEE Computer, 2/96)
913%
914Real programmers can write assembly code in any language.
915  Larry Wall
916%
917We all agree on the necessity of compromise. We just can't agree
918on when it's necessary to compromise.
919  Larry Wall
920%
921I think it's a new feature. Don't tell anyone it was an accident.
922  Larry Wall
923%
924Theory is when you know something, but it doesn't work. Practice
925is when something works, but you don't know why. Programmers combine
926theory and practice: Nothing works and they don't know why.
927  Unknown
928%
929The process of preparing programs for a digital computer is
930especially attractive, not only because it can be economically and
931scientifically rewarding, but also because it can be an aesthetic
932experience much like composing poetry or music.
933  Donald Knuth
934%
935For every complex problem there is an answer that is clear,
936simple, and wrong.
937  H. L. Mencken
938%
939Good programmers use their brains, but good guidelines save us
940having to think out every case.
941  Francis Glassborow
942%
943Up to a point, it is better to just let the snags [bugs] be there
944than to spend such time in design that there are none.
945  Alan M. Turing
946%
947Don't document bad code--rewrite it.
948    Kernighan and Plauger
949%
950The price of reliability is the pursuit of the utmost
951simplicity. It is a price which the very rich may find hard to pay.
952  C.A.R. Hoare
953%
954Programmer's Drinking Song (sung to the tune of 100 Bottles of
955Beer'') 99 little bugs in the code, 99 bugs in the code, fix one
956bug, compile it again, 101 little bugs in the code.  101 little
957bugs in the code....  (Repeat until BUGS = 0)
958  Anonymous
959%
960There are two ways of constructing a software design: One way
961is to make it so simple that there are obviously no deficiencies,
962and the other way is to make it so complicated that there are no
963obvious deficiencies. The first method is far more difficult.
964  C.A.R. Hoare
965%
966Premature optimization is the root of all evil in programming.
967  C.A.R. Hoare
968%
969You cannot teach beginners top-down programming, because they
970don't know which end is up.
971  C.A.R. Hoare
972%
973The key to performance is elegance, not battalions of special
974cases.
975  Jon Bentley and Doug McIlroy
976%
977A complex system that works is invariably found to have evolved
978from a simple system that works.
979  John Gall
980%
981Adding last-minute features, whether in response to competitive
982pressure, as a developer's pet feature, or on the whim of management,
983causes more bugs in software than almost anything else.
984  John Robbins
985%
986Inside every large program, there is a small program trying to
987get out.
988  C.A.R. Hoare
989%
990Programs must be written for people to read, and only incidentally
991for machines to execute.
992  Abelson and Sussman
993%
994The software isn't finished until the last user is dead.
995  Anonymous
996%
997It is better to have 100 functions operate on one data structure
998than 10 functions on 10 data structures.  %
999Brian Russell's Laws
1000of Software Relativity (cf. Belady and Lehman's Laws of Software
1001Evolution)
1002  * As a software project approaches release, its mass increases.
1003  *The energy required to release a software project is inversely
1004  proportional to the time before a scheduled release.  *It takes
1005  infinite energy to release a finished product on time; therefore,
1006  all software projects are both incomplete and late.  *Time is
1007  relative to the observer of a software project. The last month of
1008  development appears to an outside observer to take a year.  *If a
1009  software project becomes too large, it will collapse into a black
1010  hole.  Time and money are absorbed but nothing ever comes out.
1011    Usenet post
1012%
1013The bitterness of poor quality remains long after the sweetness
1014of meeting the schedule has been forgotten.
1015  Anonymous
1016%
1017Why do we never have time to do it right, but always have time
1018to do it over?
1019  Anonymous
1020%
1021The goal of product management is customer satisfaction. The
1022product management role is positioned to achieve this by acting
1023as the customer advocate to the team and as the team advocate to
1024the customer. It is important to distinguish between the customer
1025and the end user--the customer is the one who pays for the product
1026while the end user is the one who uses the product.
1027  Anonymous
1028%
1029The goal of Computer Science is to build something that will last
1030at least until we've finished building it.
1031  Anonymous
1032%
1033Re-use before you buy before you build.
1034  Anonymous
1035%
1036Better train people and risk they leave - than do nothing and
1037risk they stay.
1038  Anonymous
1039%
1040There is not now, and never will be, a language in which it is
1041the least bit difficult to write bad programs.
1042  Anonymous
1043%
1044Building large applications is still really difficult. Making
1045them serve an organisation well for many years is almost impossible.
1046  Malcolm P Atkinson
1047%
1048We have to stop optimizing for programmers and start optimizing
1049for users.
1050  Jeff Atwood
1051%
1052A program is never less than 90% complete, and never more than
105395%
1054complete.
1055  Terry Baker
1056%
1057Programming today is a race between software engineers striving to
1058build bigger and better idiot-proof programs, and the Universe trying
1059to produce bigger and better idiots. So far, the Universe is winning.
1060  Rich Cook
1061%
1062Optimism is an occupational hazard of programming: feedback is
1063the treatment.
1064  Kent Beck
1065%
1066A good threat is worth a thousand tests.
1067  Boris Beizer, about publicizing test cases to programmers
1068%
1069More than the act of testing, the act of designing tests is one
1070of the best bug preventers known. The thinking that must be done
1071to create a useful test can discover and eliminate bugs before they
1072are coded - indeed, test-design thinking can discover and eliminate
1073bugs at every stage in the creation of software, from conception
1074to specification, to design, coding and the rest.
1075  Boris Beizer
1076%
1077If you can't test it, don't build it. If you don't test it,
1078rip it out.
1079  Boris Beizer
1080%
1081Bugs lurk in corners and congregate at boundaries.
1082  Boris Beizer
1083%
1084Walking on water and developing software from a specification
1085are easy if both are frozen.
1086  Edward V. Berard
1087%
1088Agile methods derive much of their agility by relying on the tacit
1089knowledge embodied in the team, rather than writing the knowleadge
1090down in plans.
1091  Barry Boehm
1092%
1093Poor management can increase software costs more rapidly than
1094any other factor.
1095  Barry Boehm
1096%
1097Just because you don't know a technology, doesn't mean you won't
1098be called upon to work with it.
1099  Mike Bongiovanni
1100%
1101The most likely way for the world to be destroyed, most experts
1102agree, is by accident. That's where we come in; we're computer
1103professionals. We cause accidents.
1104  Nathaniel S. Borenstein
1105%
1106The first 90 percent of the code accounts for the first 90 percent
1107of the development time...The remaining 10 percent of the code
1108accounts for the other 90 percent of the development time.
1109   Tom Cargill
1110%
1111Documentation is like sex; when it's good, it's very, very good,
1112and when it's bad, it's better than nothing.
1113  Dick Brandon
1114%
1115The hardest part of the software task is arriving at a complete
1116and consistent specification, and much of the essence of building
1117a program is in fact the debugging of the specification.
1118  Fred Brooks
1119%
1120A little retrospection shows that although many fine, useful
1121software systems have been designed by committees and built as part
1122of multipart projects, those software systems that have excited
1123passionate fans are those that are the products of one or a few
1124designing minds, great designers.
1125  Fred Brooks
1126%
1127Good judgment comes from experience, and experience comes from
1128bad judgment.
1129  Fred Brooks
1130%
1131Any sufficiently advanced bug is indistinguishable from a feature.
1132  Bruce Brown
1133%
1134Analysis occurs only when the domain expert is in the room
1135(otherwise it is pseudo-analysis)
1136  Brad Kain
1137%
1138The only new software development projects undertaken are those
1139that haven't been done before or those whose predecessors are not
1140publicly available. This business reality, more than any other
1141factor, is what makes software development so hard and risky,
1142which makes attention to process so important.
1143  Sam Guckenheimer and Juan Perez, in Software Engineering with
1144  Microsoft
1145Visual Studio Team System %
1146I find that writing unit tests actually
1147increases my programming speed.
1148  Martin Fowler
1149%
1150When to use iterative development? You should use iterative
1151development only on projects that you want to succeed.
1152  Martin Fowler
1153%
1154All programming is maintenance programming, because you are rarely
1155writing original code.
1156  Dave Thomas
1157%
1158Even the best planning is not so omniscient as to get it right
1159the first time.
1160  Fred Brooks