To have no errors 
Would be life without meaning 
Historical note (from the Jargon File): 
	Admiral Grace Hopper (an early computing pioneer better known 
	for inventing COBOL) liked to tell a story in which a technician solved a glitch 
	in the Harvard Mark II machine by pulling an actual insect out from between 
	the contacts of one of its relays, and she subsequently promulgated bug in its 
	hackish sense as a joke about the incident (though, as she was careful to admit, 
	she was not there when it happened). For many years the logbook associated with 
	the incident and the actual bug in question (a moth) sat in a display case at 
	the Naval Surface Warfare Center (NSWC). The entire story, with a picture of 
	the logbook and the moth taped into it, is recorded in the Annals of the History 
	of Computing, Vol. 3, No. 3 (July 1981), pp. 285-286. 
To its credit, the jargon dictionary mentions several obscure 
forms of debugging. "Organic debugging" was the practice of setting a plant 
on a program listing; the idea was that bugs would crawl out of the code 
and into the plant. "Wave a dead chicken over it" was the term for a last, 
forlorn effort at diagnosing a problem, when the effort is more ritual than 
reality. There was also a description of hardware running in "casters-up 
mode. 
 
	For the first bug of Christmas, my manager said to me
	
	See if they can do it again.
	
	For the second bug of Christmas, my manager said to me
	
	Ask them how they did it and
	See if they can do it again.
	
	For the third bug of Christmas, my manager said to me
	
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the fourth bug of Christmas, my manager said to me
	
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the fifth bug of Christmas, my manager said to me
	
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the sixth bug of Christmas, my manager said to me
	
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the seventh bug of Christmas, my manager said to me
	
	Say they need an upgrade
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the eighth bug of Christmas, my manager said to me
	
	Find a way around it
	Say they need an upgrade
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the ninth bug of Christmas, my manager said to me
	
	Blame it on the hardware
	Find a way around it
	Say they need an upgrade
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the tenth bug of Christmas, my manager said to me
	
	Change the documentation
	Blame it on the hardware
	Find a way around it
	Say they need an upgrade
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the eleventh bug of Christmas, my manager said to me
	
	Say it's not supported
	Change the documentation
	Blame it on the hardware
	Find a way around it
	Say they need an upgrade
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	For the twelfth bug of Christmas, my manager said to me
	
	Tell them it's a feature
	Say it's not supported
	Change the documentation
	Blame it on the hardware
	Find a way around it
	Say they need an upgrade
	Reinstall the software
	Ask for a dump
	Run with the debugger
	Try to reproduce it
	Ask them how they did it and
	See if they can do it again.
	
	
	
	
	
	
	
	
	
 
Brian Kernighan Law of Debugging Difficulty
	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 Kernighan 
This page contains a number of important programming 
truths that every budding programmer should know about. These truths are 
self-evident, and need no explanations. 
   - If it compiles, it works.
 
   - If it compiles, it's correct.
 
   - If it runs, it doesn't have any bugs.
 
   - If it doesn't have any immediately obvious bugs, it's perfect.
 
   - If a bug doesn't show, it doesn't exist.
 
   - If it seems to work, it works.
 
   - Doing something right is easy. Avoiding errors only takes a 
		bit of concentration.
 
   - The shorter the source code, the faster the program.
 
   - It's obvious how to optimize a program.
 
   - Prorammers don't make mistakes.
 
   - Run-time errors don't occur.
 
   - Users don't make mistakes.
 
   - I don't make mistakes.
 
   - Errors of any kind are rare.
 
   - Error handling can be done in version 2.
 
   - It's OK to crash on bad input.
 
   - It's OK to give incorrect output on bad input.
 
   - Portability isn't useful.
 
   - All the world's a VAX. Or, these days, an MS-DOS box
 
   - The length of the feature list is important.
 
   - Speed is good, features are better.
 
   - Slowness can be fixed in hardware.
 
   - The bigger a program is, the better it is.
 
   - Random changes to a program fix bugs.
 
   - Testing takes only a short while.
 
   - Finding bugs is easy. Fixing bugs is trivial.
 
   - Bug-fixes don't need to be tested.
 
   - Trivial changes of any kind don't need to be tested.
 
   - The first approach, idea, or version is always the best.
 
   - A 1% crash rate is actually pretty darn good.
 
   - Code is self-evident. Comments aren't needed.
 
   - Comments are meant for people other than the original author 
		of the code.
 
   - Undocumented features are fun and useful.
 
   - It can always be fixed in the next version.
 
   - Surprised users are happy users.
 
   - Demonstrating for clients is the best debugging method.
 
The Bug Count 
Also Rises by John Browne (Imitation Hemingway Contest Winner). 
This work is licensed under 
a
Creative Commons Attribution - NonCommercial - NoDerivs 2.5 License.
   
      In the fall of that year the 
			rains fell as usual and washed the leaves of the dust and dripped 
			from the leaves onto the ground. The shuttles drove through 
			the rainy streets and took the people to meetings, then later 
			brought them back, their tires spraying the mist into the air.
			
      Many days he stood for a long 
			time and watched the rain and the shuttles and drank his double-tall 
			mochas. With the mochas he was strong. 
      Hernando who worked down the 
			hall and who was large with microbrews came to him and told 
			him that the ship day was upon them but the bugs were not yet 
			out. The bugs which were always there even when you were in 
			Cafes late at night sipping a Redhook or a double-tall mocha 
			and you thought you were safe but they were there and although 
			Enrico kept the floor swept clean and the mochas were hot the 
			bugs were there and they ate at you. 
      When Hernando told him this he 
			asked how many bugs. "The RAID is huge with bugs," Hernando 
			said. "The bugs are infinite." 
      "Why do you ask me? You know 
			I cannot do this thing anymore with the bugs." 
      "Once you were great with the 
			bugs," Hernando said. "No one was greater," he said again. "Even 
			Prado." 
      "Prado? What of Prado? Let Prado 
			fix the bugs." 
      Hernando shrugged. "Prado is 
			finished. He was gored by three Sev 2's on Chicago. All he does 
			now is drink herb tea and play with his screensavers."
			
      "Herb tea?" 
      "It is true, my friend." Hernando 
			shrugged again. Later he went to his office and sat in the dark 
			for a long time. Then he sent e-mail to Michaels. 
      Michaels came to him while he 
			was sipping a mocha. They sat silently for awhile, then he asked 
			Michaels, "I need you to triage for me." 
      Michaels looked down. "I don't 
			do that anymore," he said. 
      "This is different. The bugs 
			are enormous. There are an infinity of bugs." 
      "I'm finished with that," Michaels 
			said again. "I just want to live quietly." 
      "Have you heard Prado is finished? 
			He was badly gored. Now he can only drink herb tea." 
      "Herb tea?" Michaels said.
			
      "It is true," he said sorrowfully.
			
      Michaels stood up. "Then I will 
			do it, my friend," he said formally. "I will do it for Prado, 
			who was once great with the bugs. I will do it for the time 
			we filled Prado's office with bouncy balls, and for the time 
			Prado wore his nerf weapons in the marketing hall and slew all 
			of them with no fear and only a great joy at the combat. I will 
			do it for all the pizza we ate and the bottles of Coke we drank."
			
      Together they walked slowly back, 
			knowing it would be good. As they walked the rain dripped softly 
			from the leaves, and the shuttles carried the bodies back from 
			the meetings. 
   
 
	Half a Mb, half a Mb,
Half a Mb farther.
Churning out code, fixing bugs:
        The six coders.
"Forward, the Code Brigade,
Aim for the ship date," he said.
Churning out code, fixing bugs:
        The six coders.
"Forward, the Code Brigade!"
Was their a one dismayed?
Well though the coders knew
        Some bits were rotten.
Theirs not to feel surprise,
Theirs not to close their eyes,
Theirs but to see sunrise.
Churning out code, fixing bugs:
        The six coders.
        
Bugs to right of them,
Bugs to left of them,
Bugs in front of them,
        Crashes and freezes!
Stack traces so bizarre,
Pointers to near and far,
Zero dereferenced there,
Heap scrambled, frantic now.
Churning out code, fixing bugs:
        The six coders.
Softpanorama collection of debugging quotes: 
	- Any sufficiently advanced bug 
	is indistinguishable from a feature.
 
	- 
	
If debugging is the process of removing 
	software bugs, then programming must be the process of putting them 
	in. 
	 
	- Do not meddle in the affairs of Unix, for it 
	is subtle and quick to core dump.
 
	- To err is human but to really foul things up 
	requires a computer.
 
	- On the eight day, God started debugging
 
	- 
	
Sometimes it pays to stay in bed 
	on Monday, rather than spending the rest of the week debugging Monday's 
	code. 
	 
	- 
	
Debugging of a complex program is 
	like watching news on TV. Same shit; just different day. 
	 
	- 
	
You start coding. Then somebody will 
	start debugging and go find out what you wanted to accomplish...
	 
	- 
	
Works on my machine.
	 
	- 
	
3 Biggest Software Lies:
	
		- 
		
The program's fully tested and 
		bug-free.
		 
		- 
		
We will finish debugging the 
		next week.
		 
		- 
		
Of course we can modify it.
		 
	
	 
	- 
	
A bug is what a programmer gets when 
	he gets tired of thinking. 
	 
	- 
	
Only when you debugging somebody 
	else program you understand that 90% of the programmers are below average.
	
	 
	- 
	
If a program is useful, it will have 
	to be changed. If a program is useless, it will have to be documented
	
	 
	- 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.
 
	- Bright young men of disheveled appearance, often 
	with sunken glowing eyes, can be seen sitting at computer consoles, 
	their arms tensed and waiting to fire their fingers, already poised 
	to strike, at the buttons and keys on which their attention seems to 
	be riveted as a gambler's on the rolling dice. When not so transfixed 
	they often sit at tables strewn with computer printouts over which they 
	pore like possessed students of a cabalistic text. They work until they 
	nearly drop, twenty, thirty hours at a time. Their food, if they arrange 
	it, is brought to them: coffee, Cokes, sandwiches. If possible they 
	sleep on cots near the printouts. Their rumpled clothes, their unwashed 
	and unshaven faces, and their uncombed hair all testify that they are 
	oblivious to their bodies and to the world in which they move. These 
	are computer bums, compulsive programmers.... -- Weizenbaum, Joseph
 
	- 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. -- Wilkes, Maurice
 
	I recall a "debugging session" 
	with a user who had an interesting problem.
	It seems that he was having a great deal of trouble with his PPP
	connection under Chameleon. He was able to connect just fine with a 
	PPP 
	session, but he had a great deal of trouble communicating with other 
	sites.
	It was like it would "go to sleep" for a while, then come back.
	
	I pulled out my trusty "ping" utility to check his connectivity and 
	saw 
	something rather strange. Packets would go through just fine for a short
	
	amount of time, then there would be a long period of time between
	
	returned packets. It would be normal again for a small period of time,
	
	then quit again. Very strange.
	
	I walked him through various things on the phone. Check this... Okay,
	
	what do you have for that...
	
	I was absolutely stumped why only packets would go through some of the
	
	time. Usually in these sort of situations, either you see constant
	packets, or nothing it all.
	
	I told him to check something else...
	
	Then it struck me. As I was telling him to check over various things, 
	the 
	connection would "come alive". But as soon as he finished, the connection
	
	would die again.
	
	I told him to move his mouse back and forth across the screen. Sure
	
	enough, the connection came alive once again. I told him to stop. The
	
	packets stopped.
	
	As it turned out, he had an interrupt conflict! The only way he could
	
	push packets onto the network was to push his mouse around the screen. 
	:>
 
	(Tune:Paul Simon,"Fifty 
	Ways to Leave Your Lover")
	The problem is all inside 
	your code, she said to me;
	Recursion is easy if you take it logically.
	I'm here to help you if you're struggling to learn C,
	There must be fifty ways to hose your code. 
	She said it's really not 
	my habit to #include,
	And I hope my headers won't be lost or misconstrued;
	But I'll recompile at the risk of getting screwed,
	There must be fifty ways to hose your code . . .
	Fifty ways to hose your code.
	Just blow up the stack, 
	Jack,
	Make a bad call, Paul,
	You don't need to deploy, Roy,
	Just listen to me.
	Mess up the bus, Gus,
	You do''t need to recurse much,
	Traverse the wrong tree, Lee,
	And set your code free.
	She said, it grieves me 
	so to see you compile again,
	I wish there were some hardware that wasn't such a pain.
	I said, I appreciate that, and could you please explain
	About the fifty ways. 
	She said why don't we both 
	just work on it tonight,
	And I'm sure in the morning it'll be working just right.
	Then she hosed me and I realized she probably was right,
	There must be fifty ways to hose your code . . . 
	Fifty ways to hose your code.
	Just lose the address, Les,
	Clear the wrong Int, Clint,
	You don't need to debug, Doug,
	Just set your list free. 
	Mess up the bus, Gus,
	You don't need to recurse much,
	Just hit the wrong key, Lee,
	And program in C.
Programmer Song by tlode%[email protected] (trygve lode)
	Oh, I'm a programmer and I'm O.K. 
	I work all night and sleep all day. 
	(chorus) 
	        
	He's a programmer and he's O.K. 
        He works all night and sleeps 
	all day
	I type in code, I read my dumps, and even take 
	them to the lavatory. 
	Next Wednesday I will finish debugging and write an oratory. 
	
	(chorus) 
        He's a programmer and he's O.K.
	
        He works all night and sleeps 
	all day. 
Society
Groupthink :
Two Party System 
as Polyarchy : 
Corruption of Regulators :
Bureaucracies :
Understanding Micromanagers 
and Control Freaks : Toxic Managers :  
Harvard Mafia :
Diplomatic Communication 
: Surviving a Bad Performance 
Review : Insufficient Retirement Funds as 
Immanent Problem of Neoliberal Regime : PseudoScience :
Who Rules America :
Neoliberalism
 : The Iron 
Law of Oligarchy : 
Libertarian Philosophy
Quotes
 
War and Peace 
: Skeptical 
Finance : John 
Kenneth Galbraith :Talleyrand :
Oscar Wilde :
Otto Von Bismarck :
Keynes :
George Carlin :
Skeptics :
Propaganda  : SE 
quotes : Language Design and Programming Quotes :
Random IT-related quotes : 
Somerset Maugham :
Marcus Aurelius :
Kurt Vonnegut :
Eric Hoffer :
Winston Churchill :
Napoleon Bonaparte :
Ambrose Bierce : 
Bernard Shaw : 
Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient 
markets hypothesis :
Political Skeptic Bulletin, 2013 :
Unemployment Bulletin, 2010 :
 Vol 23, No.10 
(October, 2011) An observation about corporate security departments :
Slightly Skeptical Euromaydan Chronicles, June 2014 :
Greenspan legacy bulletin, 2008 :
Vol 25, No.10 (October, 2013) Cryptolocker Trojan 
(Win32/Crilock.A) :
Vol 25, No.08 (August, 2013) Cloud providers 
as intelligence collection hubs : 
Financial Humor Bulletin, 2010 :
Inequality Bulletin, 2009 :
Financial Humor Bulletin, 2008 :
Copyleft Problems 
Bulletin, 2004 :
Financial Humor Bulletin, 2011 :
Energy Bulletin, 2010 : 
Malware Protection Bulletin, 2010 : Vol 26, 
No.1 (January, 2013) Object-Oriented Cult :
Political Skeptic Bulletin, 2011 :
Vol 23, No.11 (November, 2011) Softpanorama classification 
of sysadmin horror stories : Vol 25, No.05 
(May, 2013) Corporate bullshit as a communication method  : 
Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): 
the triumph of the US computer engineering :
Donald Knuth : TAoCP 
and its Influence of Computer Science : Richard Stallman 
: Linus Torvalds  :
Larry Wall  :
John K. Ousterhout : 
CTSS : Multix OS Unix 
History : Unix shell history :
VI editor :
History of pipes concept :
Solaris : MS DOS 
:  Programming Languages History :
PL/1 : Simula 67 :
C :
History of GCC development : 
Scripting Languages :
Perl history   :
OS History : Mail :
DNS : SSH 
: CPU Instruction Sets :
SPARC systems 1987-2006 :
Norton Commander :
Norton Utilities :
Norton Ghost :
Frontpage history :
Malware Defense History :
GNU Screen : 
OSS early history
Classic books:
The Peter 
Principle : Parkinson 
Law : 1984 :
The Mythical Man-Month : 
How to Solve It by George Polya :
The Art of Computer Programming :
The Elements of Programming Style :
The Unix Hater’s Handbook :
The Jargon file :
The True Believer :
Programming Pearls :
The Good Soldier Svejk : 
The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society :
Ten Commandments 
of the IT Slackers Society : Computer Humor Collection 
: BSD Logo Story :
The Cuckoo's Egg :
IT Slang : C++ Humor 
: ARE YOU A BBS ADDICT? :
The Perl Purity Test :
Object oriented programmers of all nations 
: Financial Humor :
Financial Humor Bulletin, 
2008 : Financial 
Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related 
Humor : Programming Language Humor :
Goldman Sachs related humor :
Greenspan humor : C Humor :
Scripting Humor :
Real Programmers Humor :
Web Humor : GPL-related Humor 
: OFM Humor :
Politically Incorrect Humor :
IDS Humor : 
"Linux Sucks" Humor : Russian 
Musical Humor : Best Russian Programmer 
Humor : Microsoft plans to buy Catholic Church 
: Richard Stallman Related Humor :
Admin Humor : Perl-related 
Humor : Linus Torvalds Related 
humor : PseudoScience Related Humor :
Networking Humor :
Shell Humor :
Financial Humor Bulletin, 
2011 : Financial 
Humor Bulletin, 2012 :
Financial Humor Bulletin, 
2013 : Java Humor : Software 
Engineering Humor : Sun Solaris Related Humor :
Education Humor : IBM 
Humor : Assembler-related Humor :
VIM Humor : Computer 
Viruses Humor : Bright tomorrow is rescheduled 
to a day after tomorrow : Classic Computer 
Humor 
The Last but not Least  Technology is dominated by 
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. 
Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org 
was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) 
without any remuneration. This document is an industrial compilation designed and created exclusively 
for educational use and is distributed under the Softpanorama Content License. 
Original materials copyright belong 
to respective owners. Quotes are made for educational purposes only 
in compliance with the fair use doctrine.  
FAIR USE NOTICE This site contains 
		copyrighted material the use of which has not always been specifically 
		authorized by the copyright owner. We are making such material available 
		to advance understanding of computer science, IT technology, economic, scientific, and social  
		issues. We believe this constitutes a 'fair use' of any such 
		copyrighted material as provided by section 107 of the US Copyright Law according to which 
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) 
site written by people for whom English is not a native language. Grammar and spelling errors should 
be expected. The site contain some broken links as it develops like a living tree...
Disclaimer: 
The statements, views and opinions presented on this web page are those of the author (or 
referenced source) and are 
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness 
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be 
tracked by Google please disable Javascript for this site. This site is perfectly usable without 
Javascript. 
Last modified:
March 12, 2019