Archive for June, 2010


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)

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)

The programmer and the SDLC

The SDLC as it happens in the real world:

  1. Programmer produces code he believes is bug-free.
  2. Product is tested. 20 bugs are found.
  3. Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
  4. Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
  5. Repeat three times steps 3 and 4.
  6. Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
  7. Users find 137 new bugs.
  8. Original programmer, having cashed his royalty check, is nowhere to be found.
  9. Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
  10. Original programmer sends underpaid testing department a postcard from Fiji. Entire testing department quits.
  11. Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
  12. New CEO is brought in by board of directors. He hires a programmer to redo program from scratch.
  13. Programmer produces code he believes is bug-free…

It’s true, no word of lie.

Geek O'Clock

Geek O'Clock

(HT Kangaroo Digital)

  1. Any given program, when running, is obsolete.
  2. Any given program costs more and takes longer.
  3. If a program is useful, it will have to be changed.
  4. If a program is useless, it will have to be documented.
  5. Any program will expand to fill available memory.
  6. The value of a program is proportional to the weight of its output.
  7. Program complexity grows until it exceeds the capabilities of the programmer who must maintain it.
  8. Any non-trivial program contains at least one bug.
  9. Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited.
  10. Adding manpower to a late software project makes it later.

And that is all I have to paste about that…

“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

The Story of Mini and Micro

I wish I could claim to have written this, but I can’t. It’s genius and I couldn’t help myself from ripping it off to bulk up the content on my content deprived blog.

For your enjoyment, The Story of Mini and Micro. Safe for work, the people who care won’t get it anyway…

Micro was a real-time operator and dedicated multi-user. His broadband protocol made it easy for him to interface with numerous input/output devices, even if it meant time-sharing.

One evening he arrived home just as the Sun was crashing, and had parked his Motorola 68040 in the main drive (he had missed the 5100 bus that morning), when he noticed an elegant piece of liveware admiring the daisy wheels in his garden. He thought to himself, “She looks user-friendly. I’ll see if she’d like an update tonight.”

Mini was her name, and she was delightfully engineered with eyes like COBOL and a PRIME mainframe architecture that set Micro’s peripherals networking all over the place.

He browsed over to her casually, admiring the power of her twin, 32-bit floating point processors and enquired “How are you, Honeywell?” “Yes, I am well,” she responded, batting her optical fibers engagingly and smoothing her console over her curvilinear functions.

Micro settled for a straight-line approximation. “I’m stand-alone tonight,” he said, “How about computing a vector to my base address? I’ll output a byte to eat, and maybe we could get offset later on.”

Mini ran a priority process for 2.6 milliseconds then transmitted 8 k, “I’ve been dumped myself recently, and a new page is just what I need to refresh my disks. I’ll park my machine cycle in your background and meet you inside.” She walked off, leaving Micro admiring her solenoids and thinking, “Wow, what a global variable, I wonder if she’d like my firmware?”

They sat down at the process table to top of form feed of fiche and chips and a bucket of Baudot. Mini was in conversational mode and expanded on ambiguous arguments while micro gave the occasional acknowledgements, although, in reality, he was analyzing the shortest and least critical path to her entry point. He finally settled on the old would you like to see my benchmark routine, but Mini was again one step ahead.

Suddenly she was up and stripping off her parity bits to reveal the full functionality of her operating system software. “Let’s get BASIC, you RAM,” she said. Micro was loaded by this his hardware was in danger of overflowing its output buffer, a hang-up that Micro had consulted his analyst about. “Core,” was all he could say, as she prepared to log him off.

Micro soon recovered, however, when Mini went down on the DEC and opened her divide files to reveal her data set ready. He accessed his fully packed root device and was just about to start pushing into her CPU stack, when she attempted an escape sequence.

“No, no!” she cried, “You’re not shielded!”

“Reset, Baby,” he replied, “I’ve been debugged.”

“But I haven’t got my current loop enabled, and I can’t support child processes,” she protested.

“Don’t run away,” he said, “I’ll generate an interrupt.”

“No, that’s too error prone, and I can’t abort because of my design philosophy.”

Micro was locked in by this stage, though, and could not be turned off. But Mini soon stopped his thrashing by introducing a voltage spike into his main supply, whereupon he fell over with a head crash and went to sleep.

“Computers!” she thought as she recompiled herself, “All they ever think of is hex!”

I read it here first (and he doesn’t seem to know who wrote it either): http://geekswithblogs.net/dtotzke/archive/2006/02/15/69618.aspx

Impossible Code

To code the impossible code
To bring up a virgin machine
To pop out of endless recursion
To grok what appears on the screen

To right the unrightable bug
To endlessly twiddle and thrash
To mount the unmountable magtape
To stop the unstoppable crash

This is my quest
To debug that code
No matter how hopeless
No matter the load
To write those routines
Without question or pause
To be willing to hack FORTRAN IV
For a heavenly cause
And I know if I’ll only be true
To this glorious quest
That my code will run cuspy and calm
When it’s put to the test

And the queue will be better for this
That one man, scorned and destined to lose
Still strove with his last allocation
To scrap the unscrappable kludge

(http://mudcat.org/@displaysong.cfm?SongID=3001)

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

I couldn’t find a recording of the Impossible Code, which is a pity, I’d probably pay money for it.

Lies.

There are three kinds of lies: Lies, damned lies, and benchmarks.

Other Languages

How a Lisp programmer views the users of other languages. Click to de-shrink.

(Re-posted from here: http://kvardek-du.kerno.org/2010/01/how-common-lisp-programmer-views-users.html)