30 active users    
365 visitors today    
683 pages today    
 
Last Modified: AUGUST-21-2010    
 
 Index of Sources
 
 
"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

"There are features that should not be used.
There are concepts that should not be exploited.
There are problems that should not be solved.
There are programs that should not be written."

- Richard Harter

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process. "
- Glenford J. Myers, Code Complete: A Practical Handbook of Software Construction by Steve C McConnell , ISBN: 1556154844 , Page: 143
This book is available from Amazon.com
Send the Quote in Email  

"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 the same way twice."
- Christopher Alexander

"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."
- Anonymous - IEEE Grid newsmagazine

"Voluminous documentation is part of the problem, not part of the solution."
- Tom DeMarco

"When I am working on a problem, I never think about beauty. I think only of how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong."
- R Buckminster Fuller

"Debugging is an art that needs much further study. The most effective debugging techniques seem to be those which are designed and built in to the program itself. 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 E. Knuth - From The Art of Computer Programming, volume 1.

"No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in tar pits. In the mind's eye one sees dinosaurs, mammoths, and saberteeth tigers struggling against the grip of the tar. The fiercer the struggle, the more entangling the tar, and no beast is so strong or so skillful but that he ultimately sinks. Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with working systems - few have met goals, schedules, and budgets. Large and small, massive or wiry, team after team has become entangled in the tar. No one thing seems to cause the difficulty - any particular paw can be pulled away. But the accumulation of simultaneous and interacting factors brings slower and slower motion. Everyone seems to have been surprised by the stickiness of the problem, and it is hard to discern the nature of it. But we must try to understand it if we are to solve it. "
- Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks , ISBN: 0201835959
This book is available from Amazon.com
Send the Quote in Email  
Tags: 

"In programming, the hard part isn't solving problems, but deciding what problems to solve. "
- Paul Graham - From his Oscon 2004 address, printed at http://www.paulgraham.com/gh.html

"One of the most effective guidelines is not to get stuck on a single approach. If writing the program in PDL isn't working, make a picture. Write it in English. Write a short test program. Try a completely different approach. Think of a brute-force solution. Keep outlining and sketching with your pencil, and your brain will follow. If all else fails, walk away from the problem. Literally go for a walk, or think about something else before returning to the problem. If you've given it your best and are getting nowhere, putting it out of your mind for a time often produces results more quickly than sheer persistence can. "
- Steve C McConnell, Code Complete: A Practical Handbook of Software Construction by Steve C McConnell , ISBN: 1556154844
This book is available from Amazon.com
Send the Quote in Email  

"Consulting: If you're not part of the solution, there's money to be made by prolonging the problem. "
- Anonymous - Programming Proverb From wikiquote.org.

"Any simple problem can be made insoluble if enough meetings are held to discuss it. "
- Anonymous - Mitchell's Law of Committees
Send the Quote in Email  
Tags: 

"When you break the problem into parts you've determined its structure, and the work that will be done around it, forever. "
- Anonymous - Mark Miller's Law of Irrevocable Subdivision As quoted in Computer Lib, 1987 printing, page 40.
Send the Quote in Email  
Tags: 

"Your problem is another's solution; Your solution will be his problem."
- Anonymous
Send the Quote in Email  
Tags: 

"The beginning of wisdom for a programmer is to recognize the difference between getting his program to work and getting it right. A program which does not work is undoubtedly wrong; but a program which does work is not necessarily right. It may still be wrong because it is hard to understand; or because it is hard to maintain as the problem requirements change; or because its structure is different from the structure of the problem; or because we cannot be sure that it does indeed work"
- Michael A. Jackson - Principles of Program Design", Academic Press, 1975

"Some people, when confronted with a problem, think "I know, I’ll use regular expressions." Now they have two problems."
- Jamie Zawinski

"I think test-driven design is great. But you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution."
- Peter Norvig

 
  
Contact Us   |   Add Quotes   |   Advertise  |   Home  |     
 Search Quotes
 
 Free Newsletter!
 
 Tell a Friend!
Recommend this site
to your friend