Spring Break - Niagara Falls, Washington DC

For Spring Break, we did a family excursion to Washington DC with waypoints of Niagara Falls and Watkins Glen.

Prep work:
Navigation: My two year old Garmin GPS did not have maps of Canada and it would cost $60 to buy an expanded map, so I bought a new Garmin nüvi™ 1690 with US/Canada coverage instead.

Registering it and upgrading the maps was a horrible experience.  Theoretically it can be registered manually using any browser by typing in the serial number, but the Garmin web site did browser version sniffing (more than simple User Agent string detection so spoofing failed) and refused to go to the registration page unless I was running a Windows or a Mac machine.  I finally gave up and powered up an old Mac Mini and went through their whole rigmarole. [rolls eyes]

I downloaded updated maps, but the updates would not go into the onboard memory, so I bought a 4GB microSD card.  The Garmin software would not load the updated maps directly into the microSD card, I had to download and run their host-based map software, download the maps to my Mac, and then use the Mac software to download the map pieces to the Garmin.  It was extremely slow and annoying.  To top it all off, I suspect it was not using the map pieces off the SD card during our trip based on missing information, e.g. it did not know about the Flight 93 National Memorial. [rolls eyes]

Hotel reservations:

• Embassy Suites in Niagara Falls, Ontario, Canada.  Our northern neighbours have the best view of the falls, and we wanted to see the falls at night.  The hotel was chosen because of location, location, location (and I was able to trade in all my accumulated points for a night).
• Hampton Inn in Horsehead (Elmira), NY.  This was picked fairly arbitrarily to be reasonably close to Watkins Glen and on the way between Niagara Falls and Washington DC.
• Hawthorn Suites in Alexandria, VA.  This was "home base" for our DC daily adventures. Since it was a suite, it was much more comfortable than a simple hotel room.  This was an excellent choice, as it turned out.
  
  1. Hot breakfast (scrambled eggs, mystery meat, waffles) plus fruit, cereal, juice, coffee, etc.
  2. Roomy suite with a generous living/dining area and a kitchenette.
  3. "Manager's Reception" at night was actually supper (we had burgers, tacos, and loaded baked potatoes while we were there).
  4. Free shuttle to and from the Van Dorn metro station.

March 31
We launched the expedition at 6:50AM, an excellent start time for us.  At Port Huron, we used the Garmin to find a Speedway gas station, using the Google Search feature.  Unfortunately, it was closed.  Quite closed.  Fortunately, we found another one nearby that was open.

We made it to the Embassy Suites about 2:00PM. Shuttle parking threw us on check-in, we were (naively) expecting self-parking.  There was two choices: valet parking for $30 or semi-valet parking for $20 (a valet parked the car off-site with a shuttle to pick it back up again).  We scrambled to get the right bags, etc. out of the car, but we did score an undefended luggage cart and moved into our room OK.

The falls are walking distance from the hotel, which was nice. It is all uphill on the way back.

We did the tour behind the falls: it was very expense for a ho-hum experience. Definitely a "do once." Maybe.  There was a movie shoot going on overlooking the Horseshoe Falls. We saw a couple of takes, but it is like watching paint dry.

We went out to see lighted falls about 8:30PM. No lights due to Earth Hour.  I looked out the hotel window about 9:30PM and the lights were on. We went back out but only to the upper level, by then we were running out of ambition to climb the hill from the lower level back to the hotel.

April 1
We crossed back over the border and drove down to Horsehead, NY.  The Hampton Inn there was very nice. From Horsehead, it is 18 miles to Watkins Glen. After settling in at the hotel, we drove around the Watkins Glen park to get the lay of the land. The trail through the canyon closed yet for clean up and repairs. Bummer, but we knew about that. It was raining off and on, mostly on.

The GPS is giving me the silent treatment. I figure Griping Gertie is pissed because I switched to English June and Aussie Andrea.  I had to reboot the GPS to get her to talk to me again.  For the rest of the trip, we stuck to Gertie. [rolls eyes]

April 2
In Elmira and surrounding countryside, we saw a lot of Mark Twain signs, so we did a little research and discovered Samuel Langhorne Clemens was buried in Elmira so we visited his grave site.

After that, we headed for Watkins Glen, with a preliminary stop at Montour Falls - She-qua-ga (tumbling waters).  The Montour Falls were really spectacular.  That is one advantage of scoping things out the night before - finding the unexpected.

We walked the Watkins Glen rim trail, which was very neat.  The rim trail has several good overlooks, including a bridge across the chasm.  It would have been neater to walk the canyon trail.  On the positive side, it was sunshiny, warm, and we had the whole park almost to ourselves. During the summer, it gets pretty busy.

After the Glenn, we beat feet for our hotel in Alexandria, VA, arriving just before 7:30PM.  By the time we were checked in, we missed "Manager's Reception".  The "Manager's Reception" turned out to be a lot more than we expected: basically a light supper, including drinks.

April 3
For the Metro, we did day passes ($9 per head, unlimited travel from 9:30AM till closing).  This was a little more expensive than a direct ticket to DC, but a lot less hassle and gave us flexibility that we used to visit the National Cathedral and the Zoo.

We walked the mall for 6 hours. We went from the Smithsonian Metro stop to the Capital building, Union station (way overrated), and then back along the mall.  On the mall we saw the World War II memorial,  Washington Monument, White House (total bust), Lincoln Monument, FDR Memorial, and the Jefferson Memorial. The weather was great; sunny and pleasant.

The White House was a total bust because there was Something Important™ going on, so security had a major area behind the White House closed off (including part of The Ellipse).  We saw the front of the White House, but nothing of the back (which is the more publicised side).

April 4
Wednesday, we started out for the Mall, but changed our plans on the Metro and went instead to the National Cathedral.  The concept was to make a side trip there before we were all footsore from a day of Mall walking. The Cathedral was very interesting and impressive.  It was a bit of an uphill hike, but it was down on the way back so it all evened out.

The kids were pretty excited about the Zoo, so we agreed to duck in and check it out on the way back to the Metro.  Well, that turned into spending the the whole day there. It is a very nice zoo and the kids thoroughly enjoyed it.  We hit almost all the displays, leaving as it was closing for the night.

The weather mostly overcast but no rain - perfect weather for a day in the zoo.

April 5
We were originally scheduled to head home.  We had seen the monuments of the Mall, but we had not gone inside any of the museums, so we extended our stay another night.

We first hit the Museum of Natural History.  It was interesting, but very busy.  The gemstone collection was especially busy.  We ended up seeing the Hope Diamond, but none of the other gem displays because of the press of people.  That was a little disappointing.

Next we went to the National Archives.  It took a very long time to get in.  What was frustrating was the line would move nicely, then stall for an extended period of time.  When we got close to the door (after an extended "stall"), a security guard explained people were using their smartphones to buy a tour reservation for $1.50, bypassing (and stalling) the exterior line.  Once we got inside the building, the line for the Rotunda moved pretty quickly.  It looked just like the picture on the National Archives web site, except there are a lot more people clustered around the display cabinets in real life.

It was interesting to see the actual documents, but the experience was marred by the long wait, the crush of people, and the dim light combined with the faded documents (the Declaration of Independence was unreadable).  As a result, I was unable to fully appreciate and savour the experience.

We spent the rest of the day at the Smithsonian Air and Space Museum.  That was a great experience. I went all geek on my family and they even enjoyed it.  We saw most of the exhibits, but not in the depth that they deserved.  Next time...

April 6
On Friday we checked out of the hotel and drove to Arlington National Cemetery.  We got there in time to see the Changing of the Guard ceremony.  We went through the Lee House, saw the Kennedy grave sites, and then walked to the Marine War Memorial (Iwo Jima Memorial).  While walking to the Marine memorial, we watched a caisson procession, which was sad but beautiful.

After Arlington, we headed home.  On the way, we saw signs for the Flight 93 National Memorial so we did a little detour to see it.  The detour was pretty spectacular, a very nice drive through the scenic Allegheny Mountains.  Our feckless GPS had no clue about the the memorial and park roads, despite my updating the maps before we left. [rolls eyes]


The only other event on the drive home was driving past a bad car fire.  The car was fully engulfed in flames.  The highway was five lanes wide (counting the shoulders) so we were able to safely pass on the left shoulder, but not without some excitement.

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.

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!
  

Requirements are a finite set of rules.

[A]ny finite set of rules is going to be a very incomplete approximation of reality.

— Douglas Lenat (Stanford University)

In the above quote, substitute "requirements" for "rules." Requirements are necessary to bound the problem, but insufficient to fully define reality. This is a major reason why "Big Design Up Front" (BDUF) has an unblemished history of failure.

The quote comes from a very interesting story in the New Yorker, partially quoted below, and a whitepaper with more details.

In 1981, a computer scientist from Stanford University named Doug Lenat entered the Traveller Trillion Credit Squadron tournament, in San Mateo, California. It was a war game. The contestants had been given several volumes of rules, well beforehand, and had been asked to design their own fleet of warships with a mythical budget of a trillion dollars.
:
:
Lenat had developed an artificial-intelligence program that he called Eurisko, and he decided to feed his program the rules of the tournament. Lenat did not give Eurisko any advice or steer the program in any particular strategic direction. He was not a war-gamer. He simply let Eurisko figure things out for itself. For about a month, for ten hours every night on a hundred computers at Xerox PARC, in Palo Alto, Eurisko ground away at the problem, until it came out with an answer. Most teams fielded some version of a traditional naval fleet — an array of ships of various sizes, each well defended against enemy attack. Eurisko thought differently. "The program came up with a strategy of spending the trillion on an astronomical number of small ships like P.T. boats, with powerful weapons but absolutely no defense and no mobility," Lenat said. "They just sat there. Basically, if they were hit once they would sink. And what happened is that the enemy would take its shots, and every one of those shots would sink our ships. But it didn’t matter, because we had so many." Lenat won the tournament in a runaway.
:
:
"Eurisko was exposing the fact that any finite set of rules is going to be a very incomplete approximation of reality," Lenat explained. "What the other entrants were doing was filling in the holes in the rules with real-world, realistic answers. But Eurisko didn’t have that kind of preconception, partly because it didn’t know enough about the world."

BDUF, "IBM Master Programmer", and naive outsourcing strategies are "Eurisko programming." ... the resulting program may meet the literal requirements, but is not going to be very satisfactory.

Career Decision Tree

Do you know how to do the job?
Y: That's great, but learn something new.
N: Does it enhance my career (is it worth learning)?
   Y: Life is good, grow. —— employee sweet spot
   N: Does it pay well?
      Y: Do you need the money?
         Y: Suck it up, do the job.
         N: Are you a contractor?
            Y: To be expected. —— "hired gun" contractor
            N: Look for a new job.
      N: GET A NEW JOB. —— the coffin corner

Turing Test Take Two

One concept that Alan Turing is famous for is his test for evaluating artificial intelligence, know as the Turing Test. In the test, people attempt to identify by means of a conversation which "far end" conversationalists are people and which are computers.

I would propose an alternate version of the Turing test: the artificial intelligence side runs the source code through a tool and an engineer (fairly literally) implements the tool's recommended changes. The "control group" would be one or more experienced engineers who do a peer review of the same code and implements their improvements. If an observer cannot tell which code "improvements" were the result of the machine and which were the result of good engineering judgment, the tool has passed the Turing Test Take Two.

Conversely, if a tool cannot pass the Turing test, we must use an experienced engineer to filter the "recommendations" that the tool makes before we apply it.

---

Case study

---

In our contracts and in our work instructions, we have implicitly made our tools the "gatekeeper" and final judge of our code quality. The way that we fall into this trap is via our contracts or Plan for Software Aspects of Certification (PSAC), we specify that we will provide the artifacts that are generated by our tools to proved that our code is "good." The result is that the goal of running the tool is no longer to produce good code, but rather it is to produce clean printouts ("no faults found") for the customer.

The way back from this madness is to make engineers responsible for the code they write and the code they review. They should use tools to help them write good code and perform quality reviews, but the artifact that we take to the customer should not be "PCLint signed off on this code written by an anonymous cog" but "Gerald Van Baren wrote this code and is proud of it" and "Joe Competent Engineer reviewed this code and agrees that it is good." In other words, our engineers must taste the sausage. (In that article, map leaders => experienced engineers (aka. gatekeepers), sausage => code, broken machines that result in overtime => broken or misapplied tools that result in overtime.)

Our C Coding Standard (an internal standard consisting mostly of MISRA-C rules) is a classic example of a tool gone wrong. We sowed the seeds of a Turing Test Take Two breakdown in Rule 4 (of the internal standard): "Source code shall be run though an acceptable static source code analyzer." When we write in our PSAC that we will follow our C Coding Standard, we just jumped the shark and never saw it coming. While Rule 4 does not explicitly state that the engineer must implement the tool's "recommendations,"¹ in practice it is easier to make the tool shut up than it is to explain and defend and defend and defend good engineering judgment that is contrary to the tool's "recommendation."

The case study in creating an "acceptable static source code analyzer" is the (first try internal C Coding Standard) checking tool. We spent (lots of money) contracting (elided) to implement it and then discarded it because it was hopelessly inadequate. We followed that by spending (a tenth as much money) on the (second try internal C Coding Standard) tool which was only moderately inadequate. We are now mainly using PCLint (thousands of dollars per seat) which is almost adequate, but is still incapable of passing the Turing Test Take Two.

We actually (inadvertently) did the Turing Test Take Two on the (first try internal C Coding Standard) and (second try internal C Coding Standard) tools: we assigned engineers to implement changes to project source code in a "sea of hands" fashion on the results of running the static analysis tool on that code. That was a disaster. Management quickly realized from the howling of anguish from the affected internal engineers that it wasn't working and backed off on that approach.

---

1. When I discussed the (first try internal C Coding Standard) tool with an experienced, highly regarded engineer, he told me he ran the (first try internal C Coding Standard) tool on his code because the PSAC said he had to. He noted that the PSAC had a [X] checkbox for running the checking tool, but did not have a check box that said that the results were used for anything, so he did an incredibly practical thing: he simply discarded the verbosely bogus results. He then ran PCLint on his code, using it as a tool (not a judge), to identify problem areas in his code and applied his engineering judgment to determine which complaints were real and which were artificial.

Intellectual. Property.

Or, as our British friends would say, "intellectual (full stop) property." Management has subscribed to the term "intellectual property" to allow them to indulge in their fantasy that the company's "intellectual property" can be transferred readily to a "low cost labor region." If the "intellectual" part is embodied in employees, it is not very portable, which really balls up their plans to save money by transferring their "intellectual property" to "low cost labor regions."

I contend that intelligence is real and it does create property for companies, but the property (code, documentation, manufacturing, etc.) is an artifact of intelligence. It isn't intelligence itself and thus "intellectual property" is a jarring discord. Toner on paper does not have any ability to be intelligent. Bits on a disk do not have any ability to be intelligent.

The property half is held inside the company walls, but the intelligence half walks out the door every evening.

Management can talk all they want about the company's "intellectual property", but disks full of bits have only a residual value without the human intelligence that understands what those bits mean.

As an aside, if the intelligence half did not walk in the company door some morning, it does not lessen the value of the property the company actually owns. Management is inappropriately taking credit for the intelligence that humans bring to the business.

Transferring "intellectual property" to "low cost labor regions" is an extremely short term and an extremely destructive strategy. The fundamental reason some areas are "low cost" is because the workforce there often is inexperienced in general and always is inexperienced in the problem domain of the "intellectual property." By the time the "low cost labor region" workforce has gained the domain knowledge to effectively use the "property" part (the bits on the hard drives), they will no longer be low cost. Aggravating this, there is a substantial risk that the intrinsic value of the the bits on the hard drives will have decayed to a level that no amount of added intelligence can restore the value back to its original level.

---

As a concrete example, how much better are the "big three" domestic automakers doing after transferring their "intellectual property" (knowledge of how to build automobiles) to "low cost labor regions?" I contend it nearly killed them. Maybe it has killed them and what we now see is their death throes.

In an article on IBM layoffs, Robert E. Kennedy, a professor at the University of Michigan's Ross School of Business states "GM is stuck with high-cost, medium-skilled engineers. That's one reason it takes GM seven yearsto go from concept to design to the showroom floor [to produce a new car model],whereas it takes Toyota only three years. If they were more into tapping into the best talent wherever it is in the world, GM would be in better shape today."

This is a completely specious argument. Toyota hasn't moved their engineering to "low cost labor regions." Instead, they have worked to make their engineers higher skilled and more efficient. Dr. Kennedy's quote cuts exactly opposite of what he intended to show: it states that offshoring is killing GM. The engineers that remain are the second rate ones... by implication, the best ones have all left.

My google searches indicate that Toyota created new technology centers in...

• Ann Arbor, MI - Detroit's back yard. Not a "low cost labor region." If there truly are no good engineers in Detroit, it would follow that they wouldn't be in Ann Arbor either.
  
• Cannes, France - one of the most expensive countries in the EU.
  
• Australia - I don't know how this compares, but it definitely isn't the low cost labor region in that region.
  

First post

When it is your own blog, it is easy to score "first post!"