Friday, January 1, 2010

Programming Quotes and Other Life Truths

A compendium from here, here, and other sources.

Bjarne Stroustrup:
There are only two kinds of programming languages: those people always bitch about and those nobody uses.

More good code has been written in languages denounced as bad than in languages proclaimed wonderful -- much more.

C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg.

Edsger Dijkstra:
Simplicity is prerequisite for reliability.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits.

Being abstract is something profoundly different from being vague... The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

Albert Einstein:
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction.

Imagination is more important than knowledge.

The only real valuable thing is intuition.

Everything should be made as simple as possible, but not simpler.

Technological progress is like an ax in the hands of a pathological criminal.

We can't solve problems by using the same kind of thinking we used when we created them.

Not everything that counts can be counted, and not everything that can be counted counts.

Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth.
Sherlock Holmes by Sir Arthur Conan Doyle

Black holes are where God divided by zero.
Steven Wright

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
Antoine de Saint Exupery

Never mistake motion for action.
Ernest Hemingway

I've had a wonderful time, but this wasn't it.
Groucho Marx

When I am working on a problem I never think about beauty. I only think about how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong.
Buckminster Fuller< A good programmer is someone who looks both ways before crossing a one-way street. Doug Linder, systems administrator

I think there is a world market for maybe five computers.
Thomas Watson

There is no reason anyone would want a computer in their home.
Ken Olson, president, chairman and founder of Digital Equipment Corp., 1977

Considering the current sad state of our computer programs, software development is clearly still a black art, and cannot yet be called an engineering discipline.
Bill Clinton, former President of the United States

He can compress the most words into the smallest idea of any man I know.
Abraham Lincoln

For a long time it puzzled me how something so expensive, so leading edge, could be so useless, and then it occurred to me that a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a perfect match.
Bill Bryson, author, from Notes from a Big Country

Given enough eyeballs, all bugs are shallow (e.g., given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone).
Eric S. Raymond, programmer and advocate of open source software, from The Cathedral and the Bazaar

Good code is its own best documentation. As you're about to add a comment, ask yourself, 'How can I improve the code so that this comment isn't needed?' Improve the code and then document it to make it even clearer.
Steve McConnell, software engineer and author, from Code Complete

Inside every well-written large program is a well-written small program.
Charles Antony Richard Hoare, computer scientist

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would instead require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter.
Nathaniel S. Borenstein, computer scientist

The man who does not read good books has no advantage over the man who cannot read them.
Mark Twain

If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?
Seymour Cray father of supercomputing

#3 pencils and quadrille pads.
Seymoure Cray when asked what CAD tools he used to design the Cray I supercomputer

Interesting - I use a Mac to help me design the next Cray.
Seymoure Cray when he was told that Apple Inc. had recently bought a Cray supercomputer to help them design the next Mac.

Measuring programming progress by lines of code is like measuring aircraft building progress by weight.
Bill Gates, co-founder of Microsoft Corporation

Programs must be written for people to read, and only incidentally for machines to execute.
Harold Abelson and Gerald Jay Sussman, computer scientists and authors, from The Structure and Interpretation of Computer Programs

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
Tom Cargill, object-oriented programming expert at Bell Labs

The important point is that the cost of adding a feature isn't just the time it takes to code it. The cost also includes the addition of an obstacle to future expansion. Sure, any given feature list can be implemented, given enough coding time. But in addition to coming out late, you will usually wind up with a codebase that is so fragile that new ideas that should be dead-simple wind up taking longer and longer to work into the tangled existing web. The trick is to pick the features that don't fight each other.
John Carmack, computer game programmer

The key to performance is elegance, not battalions of special cases. The terrible temptation to tweak should be resisted unless the payoff is really noticeable.
Jon Bently and M. Douglas McIlroy, both computer scientists at Bell Labs

The last good thing written in C was Franz Schubert's Symphony Number 9.
Erwin Dieterich, programmer

The problem with using C++ ... is that there's already a strong tendency in the language to require you to know everything before you can do anything.
Larry Wall, developer of the Perl language

The sooner you start to code, the longer the program will take.
Roy Carlson, University of Wisconsin

The value of a prototype is in the education it gives you, not in the code itself.
Alan Cooper, software author, from The Inmates are Running the Asylum

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
Charles Antony Richard Hoare

Ugly programs are like ugly suspension bridges: they're much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code.
Eric S. Raymond

Unknown authors:
Most debugging problems are fixed easily; identifying the location of the problem is hard.

Hey! It compiles! Ship it!

Weeks of programming can save you hours of planning.

When a programming language is created that allows programmers to program in simple English, it will be discovered that programmers cannot speak English.

Managing programmers is like herding cats.

Real programmers don't comment their code. If it was hard to write, it should be hard to understand.

The C programming language -- a language which combines the flexibility of assembly language with the power of assembly language.

There are 10 kinds of programmers, those that understand binary, ....

The Story of Mel, a Real Programmer

This was posted to USENET by its author, Ed Nather, on May 21, 1983. Link here.

Real Programmers write in FORTRAN.

Maybe they do now, in this decadent era of Lite beer, hand calculators, and "user-friendly" software but back in the Good Old Days, when the term "software" sounded funny and Real Computers were made out of drums and vacuum tubes, Real Programmers wrote in machine code.

Not FORTRAN. Not RATFOR. Not, even, assembly language. Machine Code. Raw, unadorned, inscrutable hexadecimal numbers. Directly.

Lest a whole new generation of programmers grow up in ignorance of this glorious past, I feel duty-bound to describe, as best I can through the generation gap, how a Real Programmer wrote code. I'll call him Mel, because that was his name.

I first met Mel when I went to work for Royal McBee Computer Corp., a now-defunct subsidiary of the typewriter company. The firm manufactured the LGP-30, a small, cheap (by the standards of the day) drum-memory computer, and had just started to manufacture the RPC-4000, a much-improved, bigger, better, faster --- drum-memory computer. Cores cost too much, and weren't here to stay, anyway. (That's why you haven't heard of the company, or the computer.)

I had been hired to write a FORTRAN compiler for this new marvel and Mel was my guide to its wonders. Mel didn't approve of compilers.

"If a program can't rewrite its own code", he asked, "what good is it?"

Mel had written, in hexadecimal, the most popular computer program the company owned. It ran on the LGP-30 and played blackjack with potential customers at computer shows. Its effect was always dramatic. The LGP-30 booth was packed at every show, and the IBM salesmen stood around talking to each other. Whether or not this actually sold computers was a question we never discussed.

Mel's job was to re-write the blackjack program for the RPC-4000. (Port? What does that mean?) The new computer had a one-plus-one addressing scheme, in which each machine instruction, in addition to the operation code and the address of the needed operand, had a second address that indicated where, on the revolving drum, the next instruction was located.

In modern parlance, every single instruction was followed by a GO TO! Put *that* in Pascal's pipe and smoke it.

Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the "read head" and available for immediate execution. There was a program to do that job, an "optimizing assembler", but Mel refused to use it.

"You never know where it's going to put things", he explained, "so you'd have to use separate constants".

It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. His code was not easy for someone else to modify.

I compared Mel's hand-optimized programs with the same code massaged by the optimizing assembler program, and Mel's always ran faster. That was because the "top-down" method of program design hadn't been invented yet, and Mel wouldn't have used it anyway. He wrote the innermost parts of his program loops first, so they would get first choice of the optimum address locations on the drum. The optimizing assembler wasn't smart enough to do it that way.

Mel never wrote time-delay loops, either, even when the balky Flexowriter required a delay between output characters to work right. He just located instructions on the drum so each successive one was just *past* the read head when it was needed; the drum had to execute another complete revolution to find the next instruction. He coined an unforgettable term for this procedure. Although "optimum" is an absolute term, like "unique", it became common verbal practice to make it relative: "not quite optimum" or "less optimum" or "not very optimum". Mel called the maximum time-delay locations
the "most pessimum".

After he finished the blackjack program and got it to run ("Even the initializer is optimized", he said proudly), he got a Change Request from the sales department. The program used an elegant (optimized) random number generator to shuffle the "cards" and deal from the "deck", and some of the salesmen felt it was too fair, since sometimes the customers lost. They wanted Mel to modify the program so, at the setting of a sense switch on the console, they could change the odds and let the customer win.

Mel balked. He felt this was patently dishonest, which it was, and that it impinged on his personal integrity as a programmer, which it did, so he refused to do it. The Head Salesman talked to Mel, as did the Big Boss and, at the boss's urging, a few Fellow Programmers. Mel finally gave in and wrote the code, but he got the test backwards, and, when the sense switch was turned on, the program would cheat, winning every time. Mel was delighted with this, claiming his subconscious was uncontrollably ethical, and adamantly refused to fix it.

After Mel had left the company for greener pa$ture$, the Big Boss asked me to look at the code and see if I could find the test and reverse it. Somewhat reluctantly, I agreed to look. Tracking Mel's code was a real adventure.

I have often felt that programming is an art form, whose real value can only be appreciated by another versed in the same arcane art; there are lovely gems and brilliant coups hidden from human view and admiration, sometimes forever, by the very nature of the process. You can learn a lot about an individual just by reading through his code, even in hexadecimal. Mel was, I think, an unsung genius.

Perhaps my greatest shock came when I found an innocent loop that had no test in it. No test. *None*. Common sense said it had to be a closed loop, where the program would circle, forever, endlessly. Program control passed right through it, however, and safely out the other side. It took me two weeks to figure it out.

The RPC-4000 computer had a really modern facility called an index register. It allowed the programmer to write a program loop that used an indexed instruction inside; each time through, the number in the index register was added to the address of that instruction, so it would refer to the next datum in a series. He had only to increment the index register each time through. Mel never used it.

Instead, he would pull the instruction into a machine register, add one to its address, and store it back. He would then execute the modified instruction right from the register. The loop was written so this additional execution time was taken into account --- just as this instruction finished, the next one was right under the drum's read head, ready to go.
But the loop had no test in it.

The vital clue came when I noticed the index register bit, the bit that lay between the address and the operation code in the instruction word, was turned on --- yet Mel never used the index register, leaving it zero all the time. When the light went on it nearly blinded me.

He had located the data he was working on near the top of memory --- the largest locations the instructions could address --- so, after the last datum was handled, incrementing the instruction address would make it overflow. The carry would add one to the operation code, changing it to the next one in the instruction set: a jump instruction. Sure enough, the next program instruction was in address location zero, and the program went happily on its way.

I haven't kept in touch with Mel, so I don't know if he ever gave in to the flood of change that has washed over programming techniques since those long-gone days. I like to think he didn't. In any event, I was impressed enough that I quit looking for the offending test, telling the Big Boss I couldn't find it. He didn't seem surprised.

When I left the company, the blackjack program would still cheat if you turned on the right sense switch, and I think that's how it should be. I didn't feel comfortable hacking up the code of a Real Programmer.

What I Think I Do

Why it's Better to Pretend You Don't Know Anything About Computers

Read the rest at

How a Web Design Goes Straight to Hell

See the rest at

WTFs per Minute

Link to source.

Little Bobby Tables

From xkcd.

Chromium Plated Muffler Bearings

My brother was a mechanic for General Motors for well over 15 years. My Dad is one of those guys that can fix an ill wind, so long as it comes with an engine. In fact, I can trace my family's repair-ability back to my Great-Grandfather who closed down a Livery Service in Warren Ohio, to open up the Morey Brothers Auto Garage. As for me, I'm a digital guy who can't tell the difference between a spark plug and a chromium plated muffler bearing. Fortunately, my brother gives me a discount every time he fixes my muffler bearings.

One thing I have learned is that a car has four tires (I *can* count), and that if the tires are not perfectly aligned, you'll end up with less control over the car, lower fuel efficiency, more wear on the tires, and increased friction in the muffler bearings (or so I'm told). Alignment is very important. I thought of this recently when someone asked me about my tag-line for this blog, i.e. The process by which the technical capabilities of an organization are aligned with the business goals.

What exactly does that mean, and how could the two be un-aligned? As a company that prides itself on managing risk, we'll often say that technologically, we are a fast follower. Our business model is not dependent on implementing the very latest in technology. This may sound 'icky', but I'm not suggesting we use stone knives and bear-skin rugs, rather we have a vibrant and thriving Information Technology discipline based on proven platforms, technologies, and partners.

A few years ago, one of our developers wanted to use (the then very new) Java version 1.2 for his application. This would have meant accelerating the deployment of new J2EE Application Servers (which would have required more memory), and a host of other changes. I'm not even sure that 1.2 was out of beta, but even if it were, it represented cutting edge capability, memory management, garbage collection, thread management, and container-based processing.

The developer was adamant that he NEEDED Java 1.2. I asked him, if 1.2 were not yet invented, would he cancel the project? Of course not, he'd find another way to deliver the business function. We have since deployed newer versions of Java, but remain generally a version behind the latest and greatest because we value our ability to understand, manage, and communicate risk.

Our customers are not coming to us because we guide the space shuttle, can hit a bullet with a bullet, or polish muffler bearings. They come to us for superior performance which invokes feelings of ease, confidence, and achievement. By aligning our technology stack to our business model, we are in the best position possible to architect a great enterprise.

The next time I see my brother I'm going to ask him just how gullible he thinks I am. "Spark Plugs?", come on Ed, I'm no mechanic, but I can recognize a con.

Wednesday, December 30, 2009

Got Architecture?

Jokes about milkmen have been around forever, even if the practice of home delivery has been dying off.

Joanne read in Vogue magazine that a milk bath does wonders for your skin. So she wrote a note asking the milkman to leave 100 bottles of milk for her next delivery. Eddie, the milkman, saw the note, and thought there must be an error in the number of zeros. Therefore he knocked on the door and asked Joanne, to clarify the order. Joanne confirmed that she wants 100 bottles to fill her bath. The milkman then asked, 'Do you want it pasteurized' Joanne replied 'No, just up to my neck'.

I don't ever think my family used a milk delivery service, and yes, I look just like my father thank you very much. Frankly I wasn't sure they even existed anymore until I stumbled across a couple of news articles indicating that after a peak in the early 1960s, the home milk delivery business plummeted until about 2000, and then started to pick up again. Mostly, it is estimated, that the combination of convenience for two-income families and the desire for fresh local milk has spawned a re-emergence of this industry.

If you worked for such a company and were an Enterprise Architect you'd design systems to maintain the tenuous just-in-time stream of fresh milk from local suppliers, schedule drivers, configure delivery routes, drive down costs, maintain infrastructure, lease vehicles, manage inspections and repairs, and of course, conform to government regulations.

Imagine pitching a new GPS tracking system to improve on-time delivery and enable real-time tracking of milkmen. For the first time ever you would be able to monitor milkmen who stay suspiciously long at certain addresses!

There are only a few key elements to your Milk Home Delivery business. Get them right - you stay alive. Get them wrong, hello Customers of home milk delivery want convenience and reliability. Frankly, they can buy milk just as good from the local A&P/Giant Eagle/Food Lion - and for less money. Everything you do, must be focused on convenience and reliability. Period. Nothing else matters.

If you think you want the new cool GPS, you have to equate it to convenience and reliability. I don't mean you have to find a way to cleverly convince your boss that a GPS will improve reliability - you have to be able to prove it to yourself; and you should be a skeptic.

But, but, but... you say, "Our competitors have a GPS in their trucks!" So what? Can you prove that the presence of the GPS makes them more reliable? I didn't ask if you could make a case for more reliability, I asked, can you prove it?

As technologists, we can be overly enamored with the prospect of adding new solutions, tools, and capabilities to our arsenal.

Architects must understand the key drivers of our businesses and skeptically evaluate every solution in terms of it's impact on those key drivers. Are you concerned that your company doesn't have the latest technology? Prove that you need it. If you can't prove it, then spend your time and intellectual energies on improving your use of existing technologies.

Here's a test -- whatever the cost of your next project, assume it is the last 'N' dollars you have for the next two years. What project would you spend it on? Before you implement that SOA solution, the latest JDK, the newest database engine, or a cool new network appliance, prove there is no better way to invest the money.

Architecture Backpacks

I just saw the movie "Up in the Air" with George Clooney. I don't mean to suggest that George was with me when I saw it, only that George, well... you know.. was in the, nevermind. He plays the part of a professional "Displacement Manager", i.e. he is hired to fire people - and he's very good at it. It's the kind of show where you love the movie, but hate most of the message.

As a side job, Clooney's character gives the world's worst motivational presentations. How he ever lands a speaking engagement is one of those Hollywood riddles that you just have to accept. Kind of like the new Star Trek movie when young Kirk is marooned on an alien world which is close enough to witness the total destruction of a neighboring planet, but somehow is unaffected by the gravitational distortion. I'm such a geek.

In Up in the Air, Clooney's character uses a backpack as a metaphor for all of the things in your life that are holding you back. For example; friends, relatives, spouses, co-workers, and such. He says these are things you throw in your backpack that just weigh you down, hold you back, make you unsuccessful. (This is his "motivational" message!). Please George, don't become a counselor.

Clooney's motivational lack of elegance notwithstanding, the backpack metaphor can be applied to our work as architects, developers, and project managers. Every project comes with certain challenges such as costs or time lines that causes us to forgo perfection. We learn to accept low quality code, obfuscated APIs, fragile connections, magic numbers, and stupid coding tricks just to make our time / cost estimates.

As Clooney suggests, these weigh us down, reduce our satisfaction and infuse errors and performance problems into our systems. This baggage holds us back, keeping us tied to systems from which we'd like to progress away. This year, find something in your backpack to get rid of. This might mean revisiting an existing solution on the down low and replacing a hack with a hooray!

Maybe you can lighten your backpack by committing to never using a magic number in your code. For instance:

for( int x = 0; x<=9; x++ ) {
// some code

In this instance, '9' is a magic number. Why 9? Why not 8 or 10? Yes, yes, I get it, you want to loop 10 times, but why? How about:

static final int MAX_ALLOWABLE_ACCOUNTS = 10;

for( int x = 0; x < MAX_ALLOWABLE_ACCOUNTS; x++) {
// some code

The next developer to touch this code (assuming an IQ over 12) is at the very least going to ask, "Why do we only allow 10 accounts?" This becomes a business question that will yield a better understanding of both the business model, the program code, as well as a lighter backpack for both you and the next coder.

This change takes no additional time, costs zero additional dollars, improves the understanding of the business, reduces future maintenance time, and lightens the backpack for everybody. If that isn't motivation enough, maybe we could arrange a one on one with George Clooney.

Follow by Email