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.

Flocks of Programmers

Flocks of birds and software developers fly on three very simple rules:

1. Separation — Don't run over your neighbor.
2. Alignment — Make your flight vector similar to your neighbors'.
3. Cohesion — Have a common destination.

The difference between the "V"s of geese and the ever shifting clouds of starlings is the level of cohesion and the variance in their alignment.

Geese have waypoints; starlings, not so much. Starling flocks have a lot more coupling - they have many neighbors - and a lot less cohesion.

So, the question for software projects is, how do we reduce the coupling and increase the cohesion?

1. As Robert Frost said many years ago, "Good fences make good neighbors." For programs, good interfaces reduce coupling and negative interactions.
2. Increase bandwidth. One of the agile techniques is to have a very structured daily 15 minute "scrum" meeting: each developer says briefly what he accomplished the previous day, what he expects to accomplish today, and any issues he has. This helps keep all the developers aware of everything that is going on, helps maintain separation, and helps improve alignment.
   
3. Decrease latency. The open source mantra is "release early and often." This is where distributed revision control systems (e.g. git, Mercurial, DARCS) shine and where the open source technique of publishing patchsets on an email list is very beneficial; long windy roads can be straightened out before they become a serious problem.
   

Sailing Adventure 2009

We have been doing an annual Sailing Adventure on our '77 Ericson 27. What we lack in boat, we make up in fun. ;-)

This year we polled the kids whether we should go north (Manistee) or south (South Haven). Molly and Melissa said "north." Jeremy said "west" (i.e. cross the lake). Sorry, Jeremy, Manistee wins this year. :-D

2009-06-20 | Mileage: 19.0nm

• Rain cleared, sunny by 10:00
  
• On the water 12:40
  
• Motorsailed W ~5nm, then headed for White Lake
  
• Wind died ~ half way there, motoring the rest of the way
  
• White Lake Municipal slip 32p
  

2009-06-21

• Layover in White Lake: sunny, high haze & warm
  
• Paddled, rowed around end of the lake, up White River (under bridges)
  
• Melissa and Jeremy rowing up dock waterway and got caught by fisherman (they floated over his line, he must have pulled it in as they went over it and snagged the dinghy)
  
• Lots of turtles, several very large
  

2009-06-22 | Mileage: 41.8nm

• Sailing for Ludington
  
• Knotmeter broken, always 11.2kts. Dream on!
  
• On the water 9:00
  
• Sunny, light wind from SE (offshore breeze), motorsailing
  
• 11:00 wind shifted S, no apparent wind
  
• It is stupid fly season. :-( There are two fly seasons: June/July is stupid fly season. They are trivial to kill because they are so stupid, but there are hundreds more for every one you kill. They don't bite, but they crawl all over, making your skin crawl. August is biting fly season. They use their serrated proboscis to painfully saw a hole in your skin and are very hard to kill because they are very jumpy.
  
• 11:10 wind from W, cool and refreshing
  
• 12:40 coming up on Little Sable Point, wind from behind us, funky again
  
• 13:25 took down main, S wind behind us
  
• 14:50 passing Pentwater, wind backed NNW
  
• 14:45 gave up on wind, motoring last 6nm
  
• Ludington Municipal, slip b22p
  
• Went to the House of Flavors for ice cream cones :-)
  

2009-06-23 | Mileage: 23.2

• Depart 9:15, light W wind, motoring w/ sail up 0.1kt boost
  
• 11:00 rounded Big Sable Point, better wind angle, 5.9 kts
  
• 11:30 Wind clocked around behind us, jibed the jenny
  
• 12:50 wind died, motoring last 3nm
  
• Manistee Municipal, slip 11s (fishing boat ahead of us jumped our original slip assignment)
  
• The White Rose (Frankfort, Il) is in the next slip - 60 ft? yacht
  
• Some changes in town: new condos by Maple St bridge, Green Apple shop gone (bummer).
  
• Molly flipped the kayak getting in off the rocks (jumped in, instantly rolled). Once we got her on the water right side up, Dad, Melissa, and Jeremy rowed the dinghy and Molly paddled the kayak up river to the lake.
  

2009-06-24

• Layover in Manistee, sunny, blue sky. Gorgeous beach day.
  

2009-06-25 | Mileage: 33.1nm

• 9:00 heading back to Ludington
  
• Patch of blue overhead, clouds all around, hazy, temp cooler, pleasant. No wind.
  
• 9:50 som wind from W, main up, little boost
  
• 10:05 Weather holding, changed destination to Pentwater
  
• 10:20 Got the jenny out, the wind died :-( see what happens around Big Sable Point 7.8nm
  
• 10:50 Picked up some wind, set jenny
  
• 11:10 Lost the wind, jenny down
  
• 11:25 Found wind, set jenny
  
• 12:00 Rounded Big Sable Point, jenny down again
  
• 12:20 Set the jenny, broad reach, maybe the breeze will hold this time
  
• 13:00 Passing Ludington, breeze nice
  
• 13:50 Lost our bet that we could beat the rain to Pentwater. Just sprinkles, no big deal.
  
• Pentwater Municipal 36p (they have 7 transient slips - this is the first time we got in the municipal)
  
• Rowed to Little Bayou with Molly & Jeremy, Melissa kayaked
  
• Supper at the Brown Bear - excellent burgers
  
• Band concert on the green at 8:00PM
  

2009-06-26 | Mileage: 39.7nm

• Pentwater municipal: just the basics - no coffee, no microwave - but clean, nice view over the channel and anchorage
  
• Breakfast at Gull Landing, on Island time: good food, but over a hour wait :-/
  
• 11:30 left
  
• Sailing W wind
  
• 12:30 wind dropped some, used motor to kick us through a dead spot
  
• 13:25 Passing Little Sable Point, motor kicker again, wind aft and following seas
  
• 13:50 Main down, jenny not doing much :-(
  
• 14:10 Wind picked up, jenny working :-)
  
• Waves building ~3ft until passed White Lake, then diminishing as we approached Muskegon
  
• Supper at Bear Lake Tavern - new owners, same excellent food
  

2009-06-27

• Slept on the boat in our slip.
  
• Queen's Cup (interesting history) Milwalkee-Muskegon, saw the boats finishing in the morning
  
• Breakfast at Mike's Landing - yum!
  

Cruising - worked:

• Dinghy and kayak - fun!
  
• Thermos e5 mugs - awesome insulation!
  

Cruising - didn't work:

• DTV was a total bust
  
• Laptop screen unreadable topside (no surprise)
  
• Towing dinghy more drag than I expected - over 5kt, it had a bigger wake than our sailboat!