Skip to content

First Tesla Model S Long Distance Trip: Portland to Seattle and Back.

Was a great trip! Had some “range anxiety,” but not due to Tesla. I started off with a 100% charge from the house and flew up I-5 North towards Seattle. Was a very quiet and comfortable ride. Autopilot did most of the work for me.

I had to take over from Autopilot about 8 times over the entire trip on the I-5 when I was in the right hand lane and an exit was coming up. The car really wanted to split the width of the lane and aim for the exit sign planted firmly in the middle. I’d move the steering wheel to the left to get back firmly into my freeway lane, disengaging autopilot. It seems to handle ignoring exits much better if there was a car either directly in front of me or in the lane to my left just ahead of my bumper. If there was no traffic near me it wanted to drift right with the widening roadway for the exit to the point it was over too far and I had to correct.

The Supercharger at Centralia, WA was nothing short of AWESOME!!! Who knew? I connected for 30 minutes while grabbing a quick lunch with the family there at the Denny’s next door. On the way home we hit McDonald’s for another 30 minutes. To quick charge that quickly was perfect. Was also a great location as we needed to stretch our legs and hit the restrooms anyways.

I stopped in Bremerton, WA for the night and stayed at the Hampton Inn, which is at the Seattle Ferry station. Underground hosts 4 OpConnect charging spots (both Level 1 and 2). The plan was to get free parking and a full charge while I spent the night in the hotel upstairs. Worthless… They didn’t work. One had a screen that was frozen as the computer inside couldn’t mount its filesystem. The other would never send power to either the Level 1 or Level 2 circuits. I was on the phone with OpConnect support and they finally admitted they had a hardware problem with their network. I noticed on that somebody back in April had mentioned that they didn’t work back then as well.

It was here I learned how different OpConnect is from Blink Network. OpConnect, even ignoring their errors, has a very bad iOS app that has minimal functionality. You cannot even report and issue with one of their chargers. Blink, on the other hand saved the day. The app is full featured and I found a number of Blink Network stations in Bremerton. I finally settled on the one located at a Walgreen’s. They had 2 CHAdeMO quick chargers and 2 Level 2s. Their iOS app works. Their chargers worked. That said, I didn’t get a full charge, but just enough to get me back to Centralia after some local driving. I’m thinking a CHAdeMO adaptor is something worth having in the trunk and will order one later today…

Heading home I made it to Centralia with about 11% to spare and charged up quickly for the rest of the trip to Portland. I made it home with about 14% to spare.

In all it was a great trip. The drive was amazingly smooth and comfortable. Autopilot was awesome (except at a handful of exits) and it made me love my Telsa Model S even more. OpConnect? They are on my crap list. Blink? Proved to be awesome. Biggest lesson learned? Just like gas stations, have a plan B and C when it comes to charging options. My plan B at Bremerton was impromptu and after 9:00 PM, which added to my stress. Had I simply asked myself beforehand, “…and what happens if OpConnect is a bust?” I would have had a very smooth trip.

A Lesson In Resiliency

Back in the late 1980s and early 1990s there was a huge industry rivalry between two powerhouses in the personal computing software utilities sector. Up in Portland, Oregon was Central Point Software and down in Santa Monica, California was Peter Norton Computing. Both companies were bitter rivals as they fought a heated head to head battle to be the top dog in this market, slugging it out for revenue and market share. Central Point Software was on a path aimed towards filing an Initial Public Offering while Peter Norton Computing was stolen off of the launch pad, acquired by Symantec. That event didn’t change that the newly renamed Peter Norton Group was out for blood; their goals were clearly stated as “Delight customers, win all reviews, bankrupt competitors” — even the janitors knew it.

Both companies produced product suites which competed head to head in a daily battle to win both new customers and to take each other’s customers away. In one corner was PC Tools, the Central Point product, and in the other was Norton Utilities, from the Peter Norton Group. One of the main battlegrounds was in the area of disk optimization. Back when dinosaurs roamed the Earth—okay, back when personal computers had 12 Mhz Turbo switches and 10 to 20 MB hard drives—computers would get extremely slow if the hard drive became fragmented. Compress, from PC Tools would optimize the drives by rearranging file sectors to be contiguous again as would Speed Disk, the Norton Utilities product. This would make the computer fast again as the head on the hard drive wouldn’t have to move all over the place to find file sectors to read a file into the computer’s memory. One could argue which product was better than the other. Product reviews would tend to focus on which product would complete before the other as well as which drives would perform faster after being optimized.

Let me now take a brief pause to introduce you to Brad Kingsbury, the first programmer hired by Peter Norton and one of my earliest mentors…

Brad wrote the very first versions of Disk Doctor and Speed Disk at Peter’s kitchen table. He knew it was time to go home from work when Peter’s wife was ready to set the table for dinner. Brad was obsessed with clean code that performed both fast and flawlessly. Brad worked with my team on Norton Desktop for Windows and was my boss on Norton Antivirus in its very early days before it hit the big time. He was a perfectionist and expected all of his developers to know exactly how many clock cycles every line of code written in C would compile to. He also expected each of us to test every code path while in our debuggers, shoving values in to memory (or even registers or on the return stack) if we had to in order to ensure we could single step our code through every possible conditional. To have a defect found in your code was a badge of shame. Anybody who wasn’t out to make their product both fast and perfect he crowned a Slacker, a badge of shame you worked your butt off to shake. When Microsoft told Brad that it would be impossible to write a version Speed Disk for Windows due to how the operating system worked and handled disk i/o operations, Brad scoffed and came back with a working proof of concept version after almost a week of straight all-nighters.

Now back to my story…

Both PC Tools and Norton Utilities were in a dead even heat in the marketplace. Both had similar products and very loyal customers who would align with their favorite. The market had become saturated and the only way to grow revenue was to take customers away from each other. This created a fierce feature battle between the two companies. Despite the pressure to add more and more new features, Brad would not back off of his mantra regarding being able to delight the customer, but also doing so with the fastest and most reliable products. Brad knew in his heart that our products were engineered better than the competition and that is when he discovered a fatal flaw in the PC Tools products that Marketing exploited in a way that nobody could have imagined.

There used to be an industry trade-show called Comdex, which was held each year in Las Vegas (today the Computer Electronics Show picks up where Comdex left off). In the Symantec press suite two identical IBM personal computers had been set up next to each other. Both had matching hard drives, which were exact duplicates of each other. They invited the press to watch as they kicked off the presentation and demo. On the first machine they started by installing PC Tools (from floppies no less) and on the second they installed Norton Utilities. After the products completed their installations they then launched the PC Tools disk optimization product on the first machine and at the same time on the second machine they started Norton Speed Disk. A couple of minutes later as the presenters were talking a loud gasp filled the suite.

After both products had run side-by-side while they talked the two of them did the unthinkable: they ripped the power cords out from the wall sockets. There was no stopping the programs, no powering down, just the hard pull on the power cords. The audience saw the monitors go dark as they heard the very audible sound of the disk drive heads falling onto the storage platters and bouncing. The only thing louder in the room were the gasps that followed from the audience.

Both PCs then had their power restored and they began their boot sequences. The first computer, where the PC Tools Compress disk optimizer had been running, wasn’t able to boot as the BIOS claimed that disk had a fatal flaw and was unmountable. The second computer, where Norton Speed Disk had been running, booted up fine. The command CHKDSK (which was used in DOS to check the integrity of a disk drive) was executed and said everything was fine. The demo then continued on the second machine: Speed Disk was restarted and it automatically began its task right where it had left off when the power cord had been unplugged. It completed a couple of minutes later with a fully optimized hard drive.

Now the first machine, which had been running Central Point’s PC Tools, was in real trouble. Not only were the contents of the drive damaged so badly the computer wouldn’t boot up, but the PC Tools emergency rescue disk wasn’t working. When the demonstrators rebooted the PC with the emergency disk in the floppy drive, it couldn’t even find the C: drive to try to repair it. Everybody thought the first PC was now a doorstop.

The next part of the demonstration was priceless. They then proceeded to reboot the first PC with the Norton Emergency Rescue Disk, which worked, of course. The Rescue Disk repaired the hard drive on the first machine, previously damaged by the loss of power during the PC Tools Compress optimization. The demo then continued on by optimizing the first machine with Norton Speed Disk.

This demo was repeatable over and over again and without any variation in the outcomes. It became a huge buzz at the national convention and the press had a field day. For about a year the media decided to cover all of the stories they could find where PC Tools customers suffered outages and data loses while using their products.

It was just a couple of short years later that my plane landed at PDX for the first time. PC Tools had pulled their IPO, we had taken a huge percentage of their customers away from them, and Symantec had decided to purchase what was left of the company to consolidate market share. My job on the ground was to meet with the former Portland-based PC Tools software development teams and to help them learn “the Norton way.” I then went on, as part of my responsibilities after I relocated, to take over their security product teams and fold in the development teams from the newly acquired Fifth Generation Software company.


Why am I sharing this story? I feel like I’ve seen this movie before, but many in this industry are doomed to not learn from its lessons and film the bad sequels. As software developers it is one thing to complain about how crappy the infrastructure is that your system is running on (i.e. how it isn’t fair that somebody pulled the plug out of the wall), but it is another thing to design and develop software with failure in mind. Coding and testing for “happy path” is a recipe for disaster even in advanced PaaS environments like AWS and Azure. We need to keep in mind delighting customers includes resiliency, as that is a critical piece of the equation.

Will this tale change how you think about designing, coding, and testing for failure? Do you already do this? If so, please share your insights.

Commitments – Making, Keeping, Revising

Back on October 20, 2012 I posted “Rants of a Madman – When 30 Day Syndrome Attacks – Planning Like You’re Goldilocks.”  It was a rant about software teams who go back to the well saying that they need another 30 days to finish a release, just to find out they need another 30 days, and perhaps even another 30.  It was also a rant as to how Agile can help solve this problem.  While traveling from Chicago to Wichita last week I was reminded about this post and thought I’d share my recent advice to my teams.

I earned the “Most Flight Delays For A Single Flight In A Single Day” Achievement this week. I think I’ll sew the badge onto my suitcase. 11 flight delays for my flight from Chicago into Wichita and I have the 11 text messages on my phone to prove it! It was just crazy. I was afraid that I was going to burn out my FitBit as I went back and forth between gates.

Although United tried to be very transparent with the delays, I think there is a lesson to be learned in one of the key mistakes they made: At one point they gave up, quit planning, and began issuing off the cuff, gut-check last minute updates. The last 4 delays were caused when somebody assumed “this surely cannot take longer than 5 more minutes” and updated the new departure time to be 5 minutes in to the future. Well, you can guess what happened — they missed their updated time. About 10 minutes after they missed their previous “this cannot possibly take longer than 5 more minutes” update, they decided again it couldn’t take longer than 5 more minutes. Yes, next update, next fail. And yes, they made this mistake 4 times in a row.

When it comes to updating expectations one of the worst things one can do is to fall in to this syndrome of simply tossing out a quick answer that “feels good.” When providing an update for a new date, many forget that this creates a new commitment. Yes, mistakes happen and sometimes a commitment needs to be reset, but when it is reset one needs to understand that is indeed a new commitment. It is perhaps even more important in some ways than the original.

Missing commitments over and over destroys any previously earned credibility. It doesn’t matter how smart one is or how hard one works, the continued miss on commitments creates mistrust not only to customers but with one’s team. United would have been served much better had they taken a pause to actually think through setting a new expectation.

Sometimes one feels pressure to come up with that new commitment immediately, even before the answer is known to themselves. Don’t fall for this trap. If one doesn’t know it is best to say so, then give a date for a date. That is make a commitment as to when others can expect to receive an updated prognosis and final commitment.

Don’t become Goldilocks… 😀


Showing Initiative – A True Story

Although I was in Portland this week, I reflected over an experience I had last week while traveling. I went out for dinner and had similar things happen, but with totally opposite results. In the first case I wanted to order my meal and was told they were out of what I wanted. I then tried again, but received the same answer. I tried a third and fourth time and each time I received the same answer: “We are sold out of that and we don’t get our food shipment until tomorrow morning.” I ended up putting down some money for my iced tea and leaving to go someplace else. How can you operate a restaurant when you are out of meat, poultry, fish, noodles, and greens? And yes, my attempts were in that order <grin>. What was even more frustrating was each time I asked the waiter played the victim as he walked back to the kitchen, asked, and then came back to tell me “try again.” It wasn’t his fault, he explained, his “…manager hadn’t ordered enough produce this time around.”

Now, this very same week I went to another restaurant and thought I was going to have a déjà vu moment. I ordered and the waitress came back to tell me that they were out of what I had selected. Now here is where the story differs… The waitress went on to say “…our manager isn’t here, but the busboy decided to run down the block to get some groceries and should be back in less than 20 minutes. Would you like to order something else or would you prefer to wait?” She then went on to make a recommendation based on what she knew they had. In my case I decided to wait. I later saw the busboy sprint through the front door, rather winded, toting three to four plastic grocery bags. I also saw her bus some of her own tables while the busboy was out. I read some news articles and some of my current book on my Kindle while I waited and then went on to have a very enjoyable meal.

Why am I sharing this story? Based on my previous experience just a couple of days earlier I was inspired by the initiative shown by the employees at this second restaurant. At the first restaurant all of the employees had given up and were waiting for something to happen outside of their job descriptions. It wasn’t their fault they had run out of produce before their next deliveries for that week. As a customer asking them for things they were out of I was even beginning to become annoying to them. However, at the second restaurant, an employee who had nothing to do with food procurement or preparation decided to solve the problem to help his teammates out. Those employees at the second restaurant showed great initiative to do the right things for the right reasons to ensure that their company delivered the best product and experience possible to their customers.

I was really inspired by that busboy. So much so I made a note to share this experience with anybody who would listen. I hope you are inspired too.

In Agile it isn’t about job titles or job descriptions; it isn’t about tossing things over the wall via e-mail or ticket to some other team member, functional group, or department – it is about doing the right things for the right reasons in an effort to delight customers in a timely manner.

Agile is about real-time collaboration to solve a problem, divide the work, and push through it vs. waiting.

I’d like to thank all who understand and practice that across Agile teams today. You too are inspiring…  The rest of you?  Perhaps pretend you work at the second restaurant?  😀



One problem the software industry has is that it has been difficult for it to attract women to pursue Computer Science degrees and then go on to work in development, QA, or other software engineering positions. I believe this is kind of criminal given a woman, Ada Lovelace, wrote the first computer program in the mid-1800’s. A component of the issue regarding the lack of diversity in tech has been stereotypes that have been created and perpetuated throughout the industry. One woman, Isis Wenger of OneLogin, decided to address this head on with her #ILookLikeAnEngineer campaign on Twitter. There is a good article on TechCrunch that explains why she did this. 

Some may find this to be a controversial topic— it shouldn’t be. Collectively, we need to further promote and aid diversity in the workforce. I believe that it starts with #STEM programs and encouraging school age girls to learn how to code and explore the career opportunities that exists within this industry. It continues with breaking down the perpetuation of stereotypes. For our female team members, you may wish to share your own post to #ILookLikeAnEngineer to help contribute to diversity education and the conversation.

It’s PI DAY!!!

Hey, this Saturday is Pi Day. Did you know that everything that has ever existed or will exist can be represented somewhere in Pi? Every book, every movie, even your unique DNA sequence. I know, it makes your brain explode thinking about it…
Pi Day Countdown

I managed to capture this screen shot at Pi time on Pi Day:

Will Portland Hear Our Innovative Spirit This Thursday?

This Thursday night the political gears will be grinding away. The transportation commission hosts their public hearing on Uber, Lyft and similar technology-based services. Sometimes our Portland tech community can be loud about what it believes in and at other times it can be quite passive and quiet. I believe this is a moment where Portland tech needs to be vocal about the entrepreneurial spirit and push back on legacy, protectionist policies that exist to block innovation. It isn’t Uber and other similar services at risk here; it is any tech startup who dares to challenge the status quo.

PDX Rides Community Forum
Thursday, February 26, 2015 | 6 – 8:30 p.m.
Portland Building, Second Floor, 1120 SW Fifth Ave.

RadioShack R.I.P.

I felt that I needed to write a eulogy for Radio Shack, given its demise this week.  Radio Shack is one of the reasons I’m in computers today.  It started in 6th grade with a Science Fair 150-in-1 Electronic Project kit in the 70’s that my parents purchased for me on a whim.  After that Radio Shack became the cool place you went to when you wanted to build or create something that none of your friends had.  It had all the instruction manuals, tools, and electronic components to allow you to build a variety of great things. I remember that AM Radio transmitter I built from scratch that let me pretend to be a radio DJ one summer. I built my first “robot” after reading an article in OMNI Magazine (also dead today) from parts purchased at Radio Shack: a gutted remote control car that was hardwired with electronics to either follow a flash light automatically or to scurry away like a cockroach and hide in the dark once a light was turned upon it.  Then there was the Trash-80, as we affectionately called their CPM-based early microcomputer.  I learned that it was easier to change code than to modify circuits by wirewraping or soldering new components.  I’m sad.  Today we have the Rasberry PI and similar escapes; if we could only get our kids to look up from their thumbs blurring away texting, Instagraming, and Facebooking to take a glance at them…  Radio Shack R.I.P.

Portland Political Leaders Say “Uber can go pound sand in our city”

The city has had ample opportunities, even back in September of 2013, to address 2-3 easy “issues” regarding Uber and similar services. Instead it decided to stonewall and delay while protecting status quo. Using lawyers instead of proactively managing the update of policy and regulations to those in line with the opportunities of this century is perhaps one way to govern. Congratulations to how the mayor and Transportation Board decided to prioritize and spend taxpayer dollars on something that should have never reached this point (I’m being flip). Now it seems like they are simply digging their heals in because “they can” vs. asking “what is the right answer for our citizens and travelers who visit our great city?”

I have no horse in this race other than that of being a business traveler who has been repeatedly delighted as a customer while using Uber when traveling to other cities across this nation. As a prior board member of the Technology Association of Oregon and former Chief Technology Officer of Regence Blue Cross Blue Shield I’m frankly embarrassed that Portland has sided with the Luddites as opposed to embracing what great technology can enable.

As a business traveler I will continue to vote with my wallet (and my Uber phone app) until I am no longer delighted by the service they and their drivers provide to me as a consumer compared to other available options. I suspect other consumers will decide to do the same.

Banner Ad Turned 20

ATT Banner Ad

Last month if you had found a time machine and turned the dial back 20 years you would have seen the first set of banner ads. partnered with fourteen companies to try something new and innovative.  If you want to go back in time and see what AT&T did as one of these collaborators and early adopters, look at the top of this posting or go to (don’t worry about feeling nostalgic and setting your video settings to 640×480 first).  Go ahead and click on the banner ad and check out the static text landing page that had 3 hyperlinks, which then buried a couple of pages that were pretty dramatic and jaw dropping for the day).

One of the coolest aspects of their first banner ad was that they tied it in to a video advertising promotion that they had been running both on CD-ROM (as magazine inserts) and on TV.  The campaign was called “You Will” and it featured some of their predictions for what people would be able to do in the future due to technology.  You can see a compilation of these videos here.  It’s worth going through them all.  Video didn’t stream on the internet back then, but the “You Will” tagline tied their messaging and unique content delivery across multiple mediums together for them.

What is ironic about these predictions is that they pretty much nailed all of them, but one.  We may still be waiting for personal medical records, but the prediction they missed was one that was in their own space at the time.  How is it they were able to predict all the others, but not their own?  Quite simply they suffered from a phenomenon known as Innovator’s Dilemma.  Simply put they were too close the problem, could only see the solution in terms of how they would solve it based on their domain knowledge of the day, and they failed to ask the question “How would others do this?”

I’m a big fan of a methodology called “The 6 Qs” when trying to take on an initiative or problem (I’ll explain it in a future post).  Question 5 is “How have others solved this problem?”  All too often many of us think that when it comes time to solve a problem that we have to leverage our own creative juices to find the answer.  Most of us leverage our own experiences within our space, try to leverage how our products work today, and then try to leap to the next logical change or enhancement that would get us to the solution.  Our starting point is often based on where we are standing today vs. from where others are standing.

The truth is that many notable innovations come from what has already been invented.  The reality is that these stem from leveraging a solution in an adjacent space and reapplying it in your own domain in a way that delights your customers.  History is full of examples of people and companies credited with inventing or innovating something really transformative to an industry.  The dirty secret is that if you peel away the layers of the onion you often find they were the ones who saw a solution in an adjacent space and were the first to make the leap as to how to apply it within their own domain.

How will somebody else from an adjacent space out innovate you as you work from where you stand today?