Old Science Fiction: How well did they predict the future?

I've been reading my way through Project Gutenberg's Science Fiction bookshelf.  Much, maybe most, of the stories are short stories from the 1950s and 1960s. What stands out for me is that the big stuff has not happened and how much the mundane parts of our lives have changed.

Some of the "big stuff"[1] that has not happened:

• Space travel between planets and solar systems[2].
• Atomic powered rockets. And airplanes. And cars. And toasters (see next).
• Ubiquitous, essentially free power, typically atomic. Mass to energy converters are popular in the stories. Fission/fusion reactors are extremely small and safe in the stories.
• Flying cars.
• Moving walkways.

What is really interesting is how many things that are written into the scenarios as "normal life" at the time the stories were written have changed:

• The cold war (USA vs. USSR) is active.
• Phones had wires and operators (and rotary dials). They typically had a video feed as well.  While video is available today it is not prevalent for everyday use (no thanks, I don't need to see my boss).
• Smoking. Smoking. Smoking in spaceships(!). More smoking.
• Computers are huge.
• Typewriters, telegraphs, etc.
• Phone booths.

Misses:

• The concept of a cell phone is totally absent.
• Data transfer between computers (e.g. the internet).
• The computer power and size of todays computers is so much greater than the power of the (huge) computers envisioned is so far different as to be effectively a miss.
• A recurring theme is that, due to the automated production of goods, it will be the duty for people to consume products in order to keep employment from collapsing.
• Other planets in our solar system (primary Mars and Venus) are habitable and often have existing intelligent life forms.

My conclusion: speculating is fun, but the things that you think will be real in 20-50 years will still be will-o-wisps. On the other hand, a lot of the things you take for granted will be so different that it will make your grandkids laugh at you.

[1] Only considering things that don't violate known laws of physics.
[2] Well OK, interstellar travel either violates known laws of physics, or requires discovery of new laws of physics.

Serial wrap test using bash

And now, for something entirely different...

Doing a simple wrap test on a serial port should be a no-brainer in bash, but I could not find all the pieces in one place, so I assembled the pieces into a short bash script. This is not very stressful and, I am sure, could be improved, but it gets the basic job done: send a string, verify it wrapped and was received correctly, rinse and repeat.

Tip: View page source to get a better formatted copy.

#!/bin/bash # # Serial wrap test # PORT=$1 LOOPS=0 TIMEOUTS=0 MISCOMPARES=0 # Receive the wrapped string # \param $1 - port device # \param $2 - length of string that we should receive # # It works without knowing the length, but knowing the length # helps re-synchronize. # function receive { unset recv read -n $2 recv < $1 echo ${recv} > $3 } stty -F ${PORT} sane speed 115200 > /dev/null while [ true ] ; do send=`date +"%c %N"` receive ${PORT} ${#send} $$.tmp & sleep 0.1 # Block ourselves to let the receive run echo ${send} > ${PORT} sleep 0.5 # let the send complete if [ -f $$.tmp ] ; then recv=`cat $$.tmp` rm $$.tmp if [ "${send}" != "${recv}" ] ; then echo -e "\n${send} != ${recv}" let "MISCOMPARES += 1" fi else let "TIMEOUTS += 1" echo -e "\nTimeout" fi let "LOOPS += 1" echo -ne "Loops ${LOOPS} Timeouts ${TIMEOUTS} Miscompares ${MISCOMPARES}\r" done

The Statistical Singleton Falicy

The generalization of applying statistics to an individual could be called the statistical singleton fallacy: people (almost universally) inappropriately apply statistics to individuals. Statistics are only valid over populations (in the general sense). As the number of "things" in a population diminishes to 1, the confidence interval goes to 100%, i.e. you can not apply statistical conclusions to a singleton.

A simple graphic illustration of this is smoking. A smoker's probability of dying of a smoking-related disease before age 65 is 15.6%[1]. However, my probability of dying of a smoking-related disease (assuming I smoked) is either 0% (I don't die of a smoking-related disease) or 100% (I die).

People don't understand why some people smoke when there is such clear evidence of the increased probability of death due to smoking-related disease. Well, for each smoker, the probability is either 0% or 100%. If the smoker believes his probability is 0%, he will continue to smoke. If he believes his probability is 100%, he is a hypochondriac.

Thus, smokers either believe they are untouchable or they are crazy.

This is why it is so hard to sell "it's good for you" things... they are almost invariably statistically good for a large population, but can make no guarantees of "goodness" when applied to a singleton.

This applies in spades to health-anything:

• Individual's health: Lose weight and exercise - it's good for you... but then they advise you talk to your doctor first to make sure the exercise won't kill you before it becomes good for you.
  
• Program's health: testing is not guaranteed to find any bugs - if it were, running testing a second and third time would always find more bugs.

[1] http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1646951/?page=3

I'm a "sled dog" developer

I have never been comfortable labeling myself a rockstar or ninja developer. Instead, I consider myself to be a sled dog developer.

The "rockstar ninja guru" epithets have a "lone hero" connotation for me, so I am happy to hear that that meme is worn out. The best developers are team players. Even when developers are "a team of one", they are still building with and on the works of others (languages, frameworks, libraries, OSes) and contributing back via Open Source software, email lists, knowledge bases, Q&A sites, blogging, etc.

There are two main qualities that are expected in sled dogs: endurance and speed.¹ Sled dogs live to run the trail. They love to do Important Things^TM like saving lives in a Great Race of Mercy, but they are just as happy running the Iditarod race.

Sled dogs work as teams. There is a lead dog, of course, but also point dogs, swing dogs, and the powerful wheel dogs filling out the team. These have different personalities and strengths, working together to make a team better than the individual components.

To a good sled dog, the worst thing in the world is not working hard, it is not running fast. What breaks his heart is being locked in a kennel and fed dog food.

[1] Sled dogs (Wikipedia)

The Three Ninety Percents: Open Source, Enterprise, and Great Software

The Graphing Calculator Story has a great quote in it.

It is a cliche in our business that the first 90 percent of the work is easy, the second 90 percent wears you down, and the last 90 percent — the attention to detail — makes a good product.

As a pretty good approximation, this explains the user experience of Open Source, Enterprise, and Apple software.

Open Source software often stops after the first 90 percent, the fun part, and does not go beyond that.

Enterprise software is characterized by someone (no longer with the company) having done the first 90 percent years ago. The curse of enterprise software is that the programmers only ever do the second 90 percent, the unfun stuff. Enterprise management is not interested in creating new software (the fun 90 percent) or spending the time and money to make a polished product (the last 90 percent).

There are a few companies, Apple being in the vanguard, which do all three 90 percents.

One word: Discoverable

The following is my take on The Black Box Disease, an excellent blog post. It is a revised edit of my post on Hacker News.

---

The "transparent" vs. "opaque" abstraction distinction is excellent, but I submit it is an instance of a more important philosophy. The philosophy can be summarized in one word...

Discoverable.

Opaque abstractions are not discoverable: you cannot look inside to discover what makes the abstraction work. If the abstraction works, life is good. If When it breaks, you are forced to limp along with a broken mental model of the abstraction. With opaque abstractions, every time it breaks, you get "buyer's remorse."

Transparent abstractions are discoverable: if you need to (or want to), you can open the box and look inside. As long as your mental model matches the actual functioning of the abstraction, you don't need to open the box. More importantly, when your mental model vs. the abstraction breaks down, you can open the box and either fix your mental model (likely) or fix or enhance the box.

Now to expand "discoverable", think of Apple's products (I think Apple is the best company at implementing discoverable products). Why do they not provide a 2 inch thick printed manual with their products? Because they have a comprehensive Help file[1]? No, it is because their products are discoverable.

You don't have to know how to use every feature of the iPhone in order to get started, you just turn it on and make a phone call. All the useful features a new user needs are obvious and intuitive. Need to browse the web? OK, there is an icon that looks like it will browse the web. Hey, look, it worked. Need to do ______? Poke around, ask a friend, ask Google and you discover new and better ways of doing _____.

More importantly, the advanced features lie quietly in wait. They do not distract the new user, but they are discoverable as the new user becomes more sophisticated.

Not needing a manual is just a side benefit of being discoverable. The bonus for the user and Apple is that the user's delight in the product does not end after the turn it on for the first time. There is no "buyers remorse." Instead, they are discovering new features for months, sometimes years, which results in a long term stream of surprise and delight in the product.

[1] Windows and most Windows software attempts to make their products discoverable by...

1. showing all possible options at once, making their product incomprehensible, and
2. providing an incomprehensible help file that, if printed, would be 2" thick.
   

Joe the Plumber
and
Control Theory

In-house.
Outsource.
Off-shore.

What can we say about their strengths and weaknesses?

Let's first consider physical goods and services.

• Who calls Joe the Plumber to unplug their toilet?
• Who outsources their major plumbing?
• Who off-shores their plumbing?
• Where was your cellphone or laptop manufactured?

Most people outsource their major plumbing, but nobody off-shores it.

Why not?

Let's set that question aside for a moment and look at...

---

System Control Theory

Who remembers system control theory? Bode plots? Frequency and phase? Poles and zeros?

Rather than frequency and phase, I will use bandwidth and latency - they are equivalent but more descriptive in our context.

Here is the premise: In-house, outsourcing, and off-shoring development can be modeled in systems engineering terms of bandwidth and latency.

What does control theory say about bandwidth and latency?

• If you have insufficient bandwidth for the system you are controlling, you cannot close the loop.
• If you have too much latency for the system you are controlling, you have instability (oscillations).

Either way, the result is that you build the wrong thing.

---

Bandwidth = Communications

So... what is bandwidth in our system? It is human-to-human communications.

While we do not have methods to quantify this bandwidth, it is pretty easy to rank qualitatively:

1. Face-to-face communications. Excellent bandwidth.
2. Telephone communications. You lose body language, but still have decent bandwidth.
3. IRC communications — still interactive, but you lose the body language and vocal nuances.
4. Email communications — not interactive, no nuances. It works, but when a misunderstanding occurs, it can cause major problems.
5. Crossing a language barrier is difficult. Doing it over a speakerphone is very difficult.

---

Latency = Time of Flight

The other critical system control piece is latency. Latency is the time it takes for information to travel. It is the "s" in Laplace.

1. The number of time zones increase the average latency between a question and the answer.
2. Heavyweight processes, contractual approval cycles increase latency.
3. The serial nature of a waterfall development model results in latency.

(Proponents of a global development model say it results in 24 hours of development per day. That sounds good, but the dark side is that it results in 16-24 hours of latency for every question.)

---

The Off-Shoring Advantage

1. Cost.

That.     Is.     It.

...and even that may be an illusion.

[shrug] Sometimes cost is everything.

Off-shoring has success where bandwidth and latency is less important, for instance, mass manufacturing of commodity items like cell phones and laptops (although latency can sting here too, such as building millions of defective items or the wrong toy for Christmas).

---

The Local Advantage

1. High bandwidth
2. Low latency.

Conclusion: Play to your strengths.

So, what did we learn from plumbing?

• Plugged toilet: Joe the plumber has too high of latency, unplug it in-house.
• Major plumbing: Joe the Plumber has acceptable latency and much higher bandwidth (domain knowledge, building codes).
• Plumbing parts: off-shore — latency is not critical, but cost is.

Here is one final thought. What do Agile development methods emphasize?

1. Close interaction with your customer — high bandwidth.
2. Continuous integration, short iterations, incremental improvements — low latency.