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.
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…😀
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.
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…
I managed to capture this screen shot at Pi time on Pi Day:
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. http://www.portlandoregon.gov/transportation/article/519306
PDX Rides Community Forum
Thursday, February 26, 2015 | 6 – 8:30 p.m.
Portland Building, Second Floor, 1120 SW Fifth Ave.
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.