C. Keith Ray

C. Keith Ray writes about and develops software in multiple platforms and languages, including iOS® and Macintosh®.
Keith's Résumé (pdf)

Monday, December 30, 2013

Proposed Assembly Language Instructions (mid-1980's humor)

Imagine the computer-room of old: non-removable disk drives that are the size and shape of a dishwasher. Tape drives spinning like in those old black-and-white movies. Punch card input. Paper-tape for input/output. Form-feed printers with paper 17-inches wide. And the computer operator in white lab coat who controls access to the room-sized computer and loads tapes for you. In that world, these assembly-language instructions are funny. 

I'm not quite old enough to have experienced that world directly. I've never actually seen a paper-tape IO device, and I never actually wrote code that used those big magnetic tapes for input/ouput. (I did use cassette-tape storage with a ZX-81. That's very different.)

BH Branch and Hang
TDB Transfer and Drop Bits
DO Divide and Overflow
IIB Ignore Inquiry and Branch
SRZ Subtract and Reset to Zero
PI Punch Invalid
FSRA Forms Skip and Run Away
SRSD Seek Record and Scar Disk
BST Backspace and Stretch Tape
RIRG Read Inter-Record Gap
UER Update and Erase Record
SPSW Scramble Program Status Word
EIOC Execute Invalid OpCode
EROS Erase Read-Only Storage
PBC Print and Break Chain
MLR Move and Lose Record
DMPK Destroy Memory-Protect Key
DC Divide and Conquer
EPI Execute Programmer Immediate
LCC Loud and Clean Core
HCF Halt and Catch Fire
BBI Break on Blinking Indicator
BPO Branch on Power Off
AI Add Improper
ARZ Add and Reset to Zero
RSD Read and Scramble Data
RI Read Invalid
RP Read Printer
BSP Backspace Printer
MPB Move and Pitch Bits
RNR Read Noise Record
WWLR Write Wrong Length Record
RBT Rewind and Break Tape
ED Eject Disk
RW Rewind Disk
RDS Reverse Disk Spin
BD Backspace Disk
RTM Read Tape Mark
DTA Disconnect Telecommunication Adapter
STR Store Random
BKO Branch and Kill Operator
CRN Convert to Roman Numerals
FS Fire Supervisor
BRI Branch to Random Instruction
PDR Play Disk Record
POS Purge Operating System
USO Unwind Spooled Output
EPSW Erase Program Status Word
PMT Punch Magnetic Tape
AAIE Accept Apology and Ignore Errors

Laws of Computing (circa mid-1980's)

First Law of the Computer: I am a computer. I am dumber than human, and smarter than a programmer.

Lloyde's First Law: every program contains [at least] one bug.

Eggleston's Extension Principle: Programming errors which would normally take one day to find will take five days to find if the programmer is in a hurry.

Gumperson's Lemma: The probability of a given event happening is inversely proportional to its desirability.

Weirstack's Well-Ordering principle: the data needed for yesterday's debug shot must be requested no later than noon tomorrow.

Proudfoot's Law of the Good Bet: if someone claims that you can assume the input data to be correct, ask them to promise you a dollar for every input error.

Fenster's Law of Frustration: if you write a program with no error-stops or diagnostics, you will get random numbers for your output. (This can, incidentally, be used to an advantage.) However, if you write a program with 500 error-stops or diagnostic messages, they will all occur.

The Law of the Solid Goof: In any program, the part that is most obviously beyond all need of changing is the part that is totally wrong.
Corollary A: No one you ask will see it either.
Corollary B: Anyone who stops with unsought advice will see it immediately.

Wyllie's Law: Let n be the number of last category-1 job run at the computer center, then the number of your job is either n+1 or n+900.

O'hane's Rule: The number of cards in your deck is inversely proportional to the amount of output your deck produces. [FYI: it was one line of code per card in ye olde days of programming.]

Mashey's First Law: if you lie to the assembler, it will get you.

Mashey's Second Law: if you have debugging statements in your program, the bugs will be scared away and it will work fine, but as soon as you take away the debugging statements, the bugs will come back.

The Law of Dependent Independence: It is foolhardy to assume that jiggling k will not diddle y, however unlikely.

The Law of Logical Incompatibility: all assumptions are false. This is especially true of obvious assumptions.

Velonis's First Law: the question is always more important than the answer.

Velonis's Second Law: when everything possible has gone wrong, things will probably get worse.

Velonis's Third Law: the necessity for providing an answer varies inversely with the amount of time the question can be evaded.

Tuesday, December 3, 2013

Diana Larsen on Changing Your Organization

(Originally posted 2003.Apr.30 Wed; links may have expired.)

Diana Larsen's article on change and learning (and XP) http://www.cutter.com/itjournal/change.html 12 pages (PDF).

She quotes Beckhard's formula for change (my paraphrasing): If dissatisfaction with status quo, plus desirability of change, plus clear definition of what/how to do, are greater than the resistance to change, then you can achieve the desired change.

She says to encourage change, market it by increasing awareness of the problems with the status quo (I see a risk of being called names like "negative" or "not a team player") and the communicating the desirability of getting to a better situation. "When you are implementing change, there is no such thing as too much communication."

Some of this runs counter to Jerry Weinberg and another (name forgotten) book. Jerry says "don't promise more than a 10% improvement." A manager doesn't want to admit that more improvement is possible, because then they would have to admit that they were not doing a "good job" before. The (name forgotten) book pointed out that too clear a picture of the future can be paralyzing because people can see the perceived drawbacks of that situation too visibly, while not appreciating the benefits.

She writes "XP has the advantage over many change efforts in that fast iterations build in the feedback loop for short-term success. While floundering through the chaos, nothing bolsters the participants in a change effort like the sense of progress from a quick 'win.'"

Larsen recommends Chartering to start a project, and agrees with Lindstrom and Beck on "Hold two-day professionally facilitated retrospectives each quarter." (And at project end.)

Change takes time. "Putnam points out the need for patience with change efforts as he maps out six months' worth of defect tracking and shows its consistency with Satir's [change] model. He notes that if you had an evaluation of success or failure after three months, you might have come to an erroneous conclusion."

Also check out Rick Brenner's "Fifteen Tips for Change Leaders" here: http://www.chacocanyon.com/essays/tipsforchange.shtml

Keith Ray is developing new applications for iOS® and Macintosh®.. Go to Sizeography and Upstart Technology to join our mailing lists and see more about our products.