Bruce F. Webster

A few decades back, when handheld electronic calculators were still pretty neat, someone did a study on the authority people gave to them. As I recall, those conducting the study built some normal-looking calculators that were designed with specific errors in the calculation circuits such that in certain cases the calculators would give wrong answers. The studies in the subject were asked to perform a specific set of arithmetic calculations using these calculators. For some of these calculations, the doctored calculators were certain to give the wrong answer. They were then asked to check the answers by hand and give what they felt was the correct answer.

A large percentage of the subjects — when given a wrong answer by the calculator — would get the right answer when they carried out their calculations by hand. But most of them would assume that they had made a mistake in their manual calculations and that the calculator was correct, and so put down the wrong answer. These individuals couldn’t conceive that that the calculator was giving a wrong answer, and so they would doubt their own by-hand calculations.

Nice story, but old. Why am I telling this? I had a nearly identical experience yesterday, except it didn’t involve a calculator — it involved a GPS unit.

For the last four years, I have lived about 25 miles southeast of downtown Denver. During that period I have driven to and from Wyoming — north of us — multiple times, via the I-25 freeway, so I have a general sense of what lies between Denver and Cheyenne. On the other hand, it’s been probably at least a year since I’ve made that drive, so it’s not exactly fresh in my mind.

Yesterday, I had to drive to Ft. Collins, which is between Denver and Cheyenne (WY), to testify at a trial. I had it pretty fixed in my mind that the trip to Ft. Collins would take about 90 to 105 minutes. I was supposed to be there by 2:30 pm, so I planned on leaving around 12:30 pm, giving myself some slack. Around noon, I got a call from my client’s lawyer, asking if I could be there by 2:00 pm instead. I told him I thought I could make it by then, got things pulled together, and got into the car. I punched the courthouse address into our GPS system — a Magellan Maestro 4250 — asked it to plot my route (”fastest time”), and drove off.

A few miles into my drive, I noticed that the GPS unit showed an arrival time of 2:20 pm. That seemed a bit long to me, and I remembered that I had changed the time zone on the GPS system during my recent three-week trip to California. So I popped the GPS out of its cradle, worked the menus to set the time zone back to Mountain Time, backed out to the map display, and stuck it in its cradle again.

And panicked: the arrival time was now 3:20 pm (which I should have already known, since I was changing from Pacific to Mountain time). I was going to be over an hour late. I might not even be allowed to testify; I was scheduled to be the last witness before my client’s lawyer rested my client’s case. At the best, I was looking at a scolding from the judge and a negative impression on the jury.

Now, with this GPS unit, I’ve occasionally had circumstances where the time-to-destination estimate shifts abruptly, but never by more than a modest number of minutes. I was going a back route, and I thought that the GPS might re-adjust the time estimate when I got onto the E-470 toll road, heading north.

It didn’t. I had picked up a few minutes — the estimated time of arrival was now 3:18 pm — but that bought me very little. While driving at a, uh, vigorous rate of speed on E-470, I canceled the route to the courthouse, then called it up again (on ‘Previous Destinations’) to ensure that I was actually going to LaPorte Road in Fort Collins, Colorado. I was. I selected that destination again, asked the GPS to calculate the route — and again got an arrival time of 3:18 pm or so.

I was dumbfounded. I had been certain that Ft. Collins was an hour and a half, maybe 1:45, from my house, and the GPS system was telling me that it was actually close to three hours. Given how long it had been since my last trip up I-25, I now wondered if I was simply misremembering. I punched the map ‘zoom out’ button repeatedly to ensure that I was going to Ft. Collins. Sure enough — the map showed my course up E-470 to I-25 and then to a point about halfway to the Wyoming border: Ft. Collins.

I was now even more confused. While I was still at home, I had called up Google Maps and plotted a course from my house to the courthouse, and I was sure that it had told me that my driving time was 1:49. But now I was wondering if I had misread the Google Maps page, and it was actually telling me that the distance was 149 miles.

I continued my rapid drive up E-470, hoping against hope that the estimated time of arrival would magically drop an hour or more at some point. It didn’t. Finally, a few miles from the turnoff to I-25 North, I bit the bullet and called the lawyer (via the client’s cell phone) to give him the bad news: that I wouldn’t be there until 3:10 or so (I had picked up a few minutes, though not nearly as many as I had hoped). He was professional on the phone, but I know he felt blindsided — how could I be so stupid (and unprofessional) as to not leave in time to arrive on time? We hung up, and I continued the rapid pace.

I transferred onto I-25 North and saw that my next turnoff was 80 miles away. I wondered for the nth time how I could have been so wrong about the distance to Ft. Collins. Then something bubbled up through my brain: if the Ft. Collins turnoff was only 80 miles away, that meant that I would get off of I-25 around 2:15 pm — it surely wouldn’t take another 45 minutes to get to the courthouse, would it? I tried to think back to the Google map and wondered if Ft. Collins was a really, really long town; if I had to drive another 20 to 30 miles once I was off the freeway. I looked more carefully at my next exit, the one 80 miles away.

It was in Cheyenne, Wyoming. And I felt hope for about the first time in 45 minutes.

I canceled the route to the courthouse and punched in a new route to Ft. Collins, picking the first street name and number I could punch up. I pressed ‘fastest time’ (the same control I had punched both times for the courthouse) — and got an arrival time of 1:55 pm, well over an hour sooner than the GPS had given for the courthouse. I called up the courthouse address again (from ‘previous destinations’), asked as before for the fastest time — and got an arrival time of 1:56 pm. About that time, I passed a freeway sign indication that Ft. Collins was 37 miles away, so I knew I had the right time this time. I quickly called the lawyer back (actually the client, on his cell phone) and let him know that I would indeed be there by 2:00 pm.

And I was. I testified, left the courthouse, and headed back home at a much more leisurely pace, stopping in Longmont to have dinner with my daughter and grandsons.

This was a genuine bug in the GPS unit that I encountered. All three route calculations to the courthouse used the same address and the same preferences (fastest time), yet the first two times, the GPS was somehow routing me through Cheyenne, Wyoming. Furthermore, when I had zoomed out the map, it did not show me going up to Cheyenne and back; it clearly showed me going only partway to the Wyoming border and then getting off the freeway.

That said, I did exactly what those people in the calculator study did: I trusted the GPS more than my own experience (and more than my recollection of what Google Maps had said). What’s more, I had a set of local and regional atlases in the storage pouch behind the passenger seat; it would have taken me maybe 60 seconds to pull over to the side of the road, pull out an atlas, and verify just how far it was to Ft. Collins. But instead of doing that, I panicked, drove fast, and assumed that the GPS was correct, particularly when I got the same arrival time result the second time.

There was one more point of confusion in all this that likewise could have cleared things up sooner.  When I called the lawyer the first time, to give him the bad news, he asked where I was. I told him that I was on 470, approaching I-25. E-470 is the toll portion of the 470 beltway that goes about 3/4ths of the way around the Denver metropolitan area. I-25, which runs north-south, crosses 470 twice – once north of Denver and again south of Denver. When I told the lawyer how late I was going to be and where I was, he likely assumed that I was at the southern intersection of I-25 and 470, which would put me about 80 miles from Ft. Collins and having to drive right through Denver (heavy traffic, lower speed limits) to get there. Instead, I was about 45 miles and outside of the Denver metropolis, with light traffic and a 75 MPH speed limit.

I’ve had this GPS unit for at least two years. As noted, I’ve had a few glitches in time and route calculation, but never anything of this magnitude. So I let what the machine was telling me override my own experience and knowledge. It is an error in judgment all too frequent when information technology is involved.

Food for thought.  ..bruce..

My newest Baseline column is up, and in it, I talk about technology lifecycles that can cause you grief:

Each technology is on its own product lifecycle, which may or may not match with your organization’s business and development lifecycles. In particular, there are certain cycle mismatch patterns that commonly occur in organizations looking to adopt new technologies. I’ve labeled four such mismatch patterns: firefly, underdone, conveyer belt, and landfill. Each is worth examining.

Go read the whole thing.  ..bruce..

Many large-scale software projects, whether commercial, two-party, or internal, end up poorly matched to their intended use and fail to achieve their intended use. But the same factors that lead to such disappointments occur in all industries and settings. Though I never drove one (and probably only saw them rarely while growing up), as a child I constantly heard of the Ford Edsel (above) as being the archtypical failed product design.

Car Lust gives the history of that failed product, and there are many lessons for software product designers, architects, and implementers to learn:

The tale of the Edsel is fascinating because it’s an instance of a large organization full of talented, competent, well-intentioned people setting a goal that seemed perfectly reasonable, marching confidently toward that goal–and going straight off a cliff. There was no one big colossal mistake–well, actually, there was one big mistake, in my opinion, but we’ll get to that–so much as there was a long series of minor to moderate miscalculations that all added up to an idea that not only didn’t fly, but crashed and burned on takeoff and left a great smoking hole in Ford’s corporate treasury. . . .

To make the Edsel different, it was decided to feature a pushbutton interface in place of the usual column shifter. Rather than put the pushbuttons in a logical location on the dashboard, like Chrysler did, Edsel’s brain trust stuck them in the center of the steering column–creating the infamous Teletouch Drive found on something over 90 percent of 1958-model Edsels. As a matter of ergonomics, the Teletouch Drive was just a little bit dodgy, as it put the shifter where most cars traditionally put the horn button. (Edsel owner tries to honk horn, puts Edsel in reverse, hilarity ensues.) It also later proved to be unacceptably fragile. . . .

In the last weeks before E-Day, build quality suddenly became a critical issue that threatened the whole project. Since the planned new Edsel factories did not yet exist, the Edsels were being built at Ford and Mercury plants. Edsels were different from Fords and Mercurys, they took different parts and had different assembly sequences–which made them inconvenient and annoying to deal with–and they didn’t really “belong” there. As a consequence, Edsels didn’t get the attention they deserved, and they were coming off the line with parts missing and body panels out of alignment. The Edsel sales and support staff, and many dealers, had to scramble to make those first cars presentable, and quite a few Edsel dealerships had “hangar queens” squirreled away in the back room on E-day, waiting for parts to come in. . . .

It was about this time that a lot of the build quality issues that had been hastily covered up in the month before E-Day began asserting themselves. Cars developed squeaks and rattles and minor (and major) malfunctions. The fragile Teletouch Drive began misbehaving with alarming frequency. Edsel dealers’  service departments suddenly became very busy. Word got around that the cars were lemons. Wags began claiming that the name “Edsel” was an acronym for “Every Day Something Else Leaks.” Bob Hope added Edsel jokes to his stage routine. Just a few weeks after hitting the market, the Edsel had gone from being The Next Big Thing to a national punch line. . . .

You mean, kind of like Microsoft Vista? Be sure to read the entire article: it’s fascinating, informative, and entertaining to boot. Hat tip to Instapundit.  ..bruce..

I have written about the thermocline of truth, a phenomenon I have witnessed several times in large IT projects where the true status of the project (usually not good) gets blocked at a certain layer of management, slowly moving up the management chain and usually reaching the top just weeks before the scheduled release date.  Not long ago, I had a brief note here about the thermocline of truth as it applies to NASA projects, pointing readers to a post by Rand Simberg at the ever-excellent Transterrestrial Musings.

Now, and again courtesy of Rand Simberg, comes this brilliant video, made recently by frustrated workers within NASA to show how efforts to innovate and improve a troubled project (can you say “Ares”, boys and girls?)  get blocked by middle managers:

Simberg actually pointed to a post by Wayne Hale, a long-time NASA manager, on an official NASA website blog. Hale felt that many of these problems had already been addressed and was surprised (or Simberg put it, “shocked, shocked”) to find them still pervasive at NASA:

Recently I had a couple of events which affected my thinking on this.  I have been out of the Shuttle Program manager job for almost a year now and a trusted coworker just a week ago told me that people in his organization had been prevented from giving me important alternative choices for some program choices that occurred a couple of years ago.  This was staggering. It was happening right in front of me and I was totally unaware that people - who I trusted, who I hoped would trust me - kept their lips sealed because somebody in their middle management made it clear to them that speaking up would not be good.

Astounding.

About two weeks ago an activity that Mike Coats started at JSC had an all day report out period.  The Inclusion and Innovation Council was to propose ways to improve innovation at NASA.  Various teams reported out, including one team of young employees who has the task to talk about the barriers to innovation at NASA — specifically at JSC.

The video attached was their result.  I found it extraordinarily funny and not at all funny.  These young people have obviously found themselves in situations RECENTLY in which managers at various levels applied sociological and psychological pressures to keep them from bringing ideas forward.

I am convinced that if we asked the managers who were the models for this little morality play whether they stifled dissent or welcomed alternate opinions, they would respond that they were welcoming and encouraging.  Probably because they have that self image.

But actual behavior, not inaccurate self perception, is what we really need.

Watch the video, read Hale’s post, and then ask yourself: how many of these problems affect innovation and product development in both organizational and commercial IT development groups? ..bruce..

I’m doing some administrative work on the site; please excuse any flakiness.  ..bruce..