Computer quote of the day 0x47

“Any sufficiently advanced bug is indistinguishable from a feature.”
– Unknown

Computer quote of the day 0x46

“Never put off until run time what you can do at compile time.”
– David Gries, in “Compiler Construction for Digital Computers”, circa 1969.

Real programmers… 0x2A

Real Programmers never use API’s, they create API’s.

Re-post: The Six Stages of Debugging

I’ve been thinking about writing an article on the sad realities of debugging a program and the effect that it has on us barely human programmers. Then I came across this post at 4 Lines of Code. It’s genius and I love it and it is all perfectly true. Somebody should be collecting these pearls of wisdom from blogs and making a book. Seriously.

We have examined earlier the fundamental laws of bug finding. You will probably know the fundamental stages of bug finding. The 6 basic stages of debugging are well-known among programmers and can be found in various blog posts. During debugging, developers and programmers go through a cycle of emotional states:

1. DENIAL. That can’t happen.
2. FRUSTRATION. That doesn’t happen on my machine.
3. DISBELIEF. That shouldn’t happen.
4. TESTING. Why does that happen?
5. GOTCHA. Oh, I see.
6. RELIEF. How did that ever work?

First (1) we have a stage of denial and surprise: you say that the bug isn’t possible, that it can’t happen, because you have not observed it before. You are surprised. The reason is (2) that is doesn’t happen on your machine or on your computer. You can not reproduce it instantly, and you have not seen this bug before. You get frustrated and sometimes a bit angry. Therefore you think that (3) it shouldn’t happen. Yet someone – unfortunately often a customer or a user – insists that it does. So you (4) ask why it is happening, and why it can happen. The only way to solve this problem is to find out what really happens. You start to examine logs and to debug the program, until you are able to find and to reproduce the bug. If you’ll do this long and hard enough then (5) you see the reason for the bug, and are able to remove it. You are trying to reproduce the bug again to see if it is fixed. Finally (6) you ask yourself how it ever work before. The longer you seek a bug and the longer the phases (1)-(4), the larger the relief in the end.

You can read the original post here: http://4loc.wordpress.com/2010/03/13/the-six-stages-of-debugging/

If you’re into development at all, be sure to check out 4 Lines of Code, it’s good stuff.

Computer quote of the day 0x45

“Programming graphics in X is like finding sqrt(pi) using Roman numerals.”
– Henry Spencer

Another Glitch in the Call Song

We don’t need no indirection
We don’t need no flow control
No data typing or declarations
Did you leave the lists alone?

Hey! Hacker! Leave those lists alone!

Chorus:
All in all, it was, just a pure-LISP function call.
All in all, it was, just a pure-LISP function call.

Sung like so: http://www.youtube.com/watch?v=-Py5aPLG348

Seriously, somebody needs to put together an album of these gems. I’m speaking to you Mr. Weird Al’ Yankovic. *pointed look*

Computer quote of the day 0x44

“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

Programmer’s Creed: The Mark of Quality

I was floating around the intartoobz when I came across this pearl of wisdom. I think that following these 4 prime laws will most certainly increase the quality of software. I would venture though, that, in the event of the quality assurance manager being of the male persuasion, that the head in option 4 be replaced by something more important.

The Programmers Creed:

1. I will not begin the design phase until the user requirements have been unanimously agreed upon by all users, and etched onto large stone tablets.
2. I will not begin development until the design is signed off, preferably in blood.
3. Issues that arise during testing will be recorded in the issue management system, and the relevant developer shall be notified, in writing, before he or she is taken out and flogged, not after.
4. Product upgrades will not be released into the production environment until the quality assurance manager has scheduled a time to place his or her head on the correct chopping block, and the axe-man or axe-woman has verified that the axe is indeed sharp.

0x41men

(CnP™ from http://secretgeek.net/creed_.asp)

Programmer's Creed: The Mark of Quality

I was floating around the intartoobz when I came across this pearl of wisdom. I think that following these 4 prime laws will most certainly increase the quality of software. I would venture though, that, in the event of the quality assurance manager being of the male persuasion, that the head in option 4 be replaced by something more important.

The Programmers Creed:

1. I will not begin the design phase until the user requirements have been unanimously agreed upon by all users, and etched onto large stone tablets.
2. I will not begin development until the design is signed off, preferably in blood.
3. Issues that arise during testing will be recorded in the issue management system, and the relevant developer shall be notified, in writing, before he or she is taken out and flogged, not after.
4. Product upgrades will not be released into the production environment until the quality assurance manager has scheduled a time to place his or her head on the correct chopping block, and the axe-man or axe-woman has verified that the axe is indeed sharp.

0x41men

(CnP™ from http://secretgeek.net/creed_.asp)

Computer quote of the day 0x43

“The primary purpose of the DATA statement is to give names to constants; instead of referring to pi as 3.141592653589793 at every appearance, the variable PI can be given that value with a DATA statement and used instead of the longer form of the constant. This also simplifies modifying the program, should the value of pi change.”
– FORTRAN manual for Xerox computers