“Mechanical jokes”

I’ve decided to revive my ‘quotes’ file that I used to keep. I couldn’t resist posting the first entry into it, because it represents so much of why I love reading and also justifies my dislike of driving. One of the great things about Heinlein (and other authors) is that some of the best passages are really just them doing some exposition on some topic that they are passionate about. The passages tend to be only tangentially related to the plot at hand, but are nonetheless part of what makes the work great.

By the way, the majority of quotes are much, much smaller, but there was no real way to shorten this particular one.

“A reciprocating engine was a collection of miniature heat engines using (in a basically inefficient cycle) a small percentage of an exothermic chemical reaction, a reaction which was started and stopped every split second. Much of the heat was intentionally thrown away into a ‘water jacket’ or ‘cooling system’ then wasted into the atmosphere through a heat exchanger.

What little was left caused blocks of metal to thump foolishly back-and-forth (hence the name ‘reciprocating’) and thence through a linkage to cause a shaft and flywheel to spin around. The flywheel (believe it if you can) had no gyroscopic function; it was used to store kinetic energy in a futile attempt to cover up the sins of reciprocation. The shaft at long last caused wheels to turn and thereby propelled this pile of junk over the countryside.

The prime mover was used; control, only to accelerate and to overcome ‘friction’ — a concept then in much wider engineering use. To decelerate, stop, or turn the heroic human operator used his own muscle power, multiplied precariously through a series of levers.

Despite the name ‘automobile’ these vehicles had no automatic circuits; control, such as it was, was exercised second by second for hours on end by a human being peering out through a small pane of dirty silica glass, and judging unassisted and disastrously his own motion and those of other objects. In ed in his almost all cases the operator had no notion of the kinetic energy stored in his missile and could not have written the basic equation. Newton’s Laws of Motion were to him mysteries as profound as the meaning of the universe.

Nevertheless millions of these mechanical jokes swarmed over our home planet, dodging each other by inches or failing to dodge. None of them ever worked right; by their nature they could not work right; and they were constantly getting out of order. Their operators were usually mightily pleased when they worked at all. When they did not, which was every few hundred miles (hundred, not hundred thousand), they hired a member of a social class of arcane specialists to make inadequate and always expensive temporary repairs.

Despite their mad shortcomings, these ‘automobiles’ were the most characteristic form of wealth and the most cherished possessions of their time. Three whole generations were slaves to them.”

That’s from Robert Heinlein’s Space Family Stone (originally 1952, but this is from a 1971 paperback edition that I paid about $0.40 for, but it’s on Amazon for $29) . It’s one of his “space opera” style deals that, as far as I can tell, has no real purpose other than to tell a story about a family and some experiences of theirs. A quick summer read.

The whole section puts things in perspective, and especially justifies why somebody like me (who tends to be absent-minded while driving) really does not belong behind the wheel of one of these “mechanical jokes”.

Going to end this with a last quote from a friend and co-worker’s Wes’ blog which I had to read out loud to my wife because it was so profound in its statement of the limitless possibilities of reading and the fact that you can only be reading (and have read) so many books, but there is an endless set of books that you have not read and will never be able to get to:

“But what can I say: a man only has so many books he can not finish at once.”

Quite.

Design Smart, Code Stupid

“Design Smart, Code Stupid” is just another way of saying “Don’t be clever” at the code level. Remember that as soon as you write some code, you are now its primary maintainer. If the code base is a hobby project, you may be the only maintainer, so you owe it to yourself to make your code easy to read. If its not a hobby project, it becomes even more important (if only to save face!); the last thing you want is other developer’s looking at your code and thinking “what does this line do?!” Instead, another developer should look at your code and think, “this makes total sense, anybody could write this!” A little self-test is to revisit your code a week or two after you wrote it. If it confuses you and produces a lot of “wtf?” then you need to simplify it.

Do you really need to use a ternary operator? Is it honestly easier to do a bit mask and a bit shift in the same statement? You may want to reconsider that nested a.getB().getC().getD().doSomething() you have going there.

So that’s the “code stupid” part… kinda starting backwards here.

So every line should be obvious, but each one should also go toward solving a problem (why else is it there anyhow). As you take the view higher and higher through the system, it should continue to make just as much sense. Each method should be well-named so that a person does not even need to look at it to know what the purpose is: the calling of a method should be as obvious as a built-in language construct. At the class or module level, it should be obvious what role it serves in the big picture. Multiple modules and classes should be “packaged” together as a cohesive unit that solves some problem.

Essentially, at whatever level a person looks, it should be obvious what what the system is doing, and why it is being done in the way chosen (even if there are alternative methods).

And you know what, another developer will look at the design and think “Man, that’s smart!” Because it is not easy to do for any non-trivial problem.

Because you know what, if you don’t have a good view of the big picture design of your system, then neither will anybody else. Instead, you will have a hodge podge of classes and methods that sort of work together. You need to know what it is you are building before you build it. Always think about the Use Cases!

I have no idea if Steve McCcconell uses the phrase in “Code Complete.” I would not be surprised, as entire book is really devoted to the idea of building a system that makes sense at every level. So I know that I am havingaa completely un-original thought, and I’ll freely admit it. I have no doubt read it so many times that its worked its way into me into some sort of meme. Nonetheless, I just thought I’d talk about it for a bit. I try to live it and know that I screw it up all the time.

Update: Fixed the sentence on Code Complete, realized that I had left out like 4 words 😉