Sunday, June 8, 2014

Are we Having Fun Yet?

Lately, I’ve been reading Reality is Broken by Jane McGonigal. This book is an exploration of the role games play in our lives, how they make us better, and how games might help us improve the world. She has a powerful thesis, and some of the things she says resonates deeply.

In the opening chapters of her book, she illustrates how games can provide more meaningful work, and then follows it up with a chapter called “Fun Failure and Better Odds of Success”.

In that chapter, McGonigal lays out the position that games offer us overwhelming opportunities to fail repeatedly, but in a fun way. Whether it is avoiding barrels tossed by a gorilla, shooting at alien spaceships, or killing orcs and goblins, we typically only succeed after failing multiple times. It is obviously fun to fail at these games, because most of us don’t walk away from the game after we have failed once or twice. Instead, we start the level over and try again. It is this fun failure that gives us an “urgent optimism” that we are almost ready to conquer the level.

Be honest: how many late nights have you put in on Halo, Call of Duty, WoW, Tetris, or Candy Crush Saga saying, “Just one more level!”?

Fun failure, indeed.

But while the concept of “fun failure” is fine in a game, it certainly doesn’t reflect reality for those of us in the Support trenches. Except for the failure part, because sometimes it seems like we’ve got failure down pat. This is especially true when we have an intractable issue that defies logic, or when an issue keeps cropping up in the field and we can’t duplicate it in our debugging environments.

That’s because real life is difficult, reality is tough.

Right now, I’m working on an issue that is a dark shade of ugly. It is like one of those old maps that shows the known world and seas, and then near the edge of the map is a coastline followed by the legend, “Here there be dragons.”

This code that I’m trying to fix is miles inland from that warning. I’m so far into the dragon-scape that I can’t even tell you in which direction the coastline lies.

It is a whole lot of failure and even less fun. I’ve tried to refactor this code at least twice, and failed to make headway. Here there be dragons, and the dragons be winning. I have to admit that being unable to slay this dragon made me pretty demoralized.

But then I read this nugget from McGonigal:
Learning to stay urgently optimistic in the face of failure is an important emotional strength that we can learn in games and apply in our real lives. When we’re energized by failure, we develop emotional stamina. And emotional stamina makes it possible for us to hang in longer, to do much harder work, and to tackle more complex challenges. We need this kind of optimism in order to thrive as human beings.1
Getting energized by failure is a difficult concept to grasp, and as I reflected on how I might get energized by my current dragon-battle, I wondered what would happen if I adopted McGonigal at face value. That is, if games are fun and teach us how to have fun while failing, then what would happen if I turned my support efforts into a game? Instead of being demoralized by a seemingly invincible dragon, what if I was just facing a super-difficult Boss Level?

Just the simple change in my attitude has already given me hope. I know I can beat this level; it’s just a matter of time. I’ve taken a fresh look at the battlefield, reconnoitering the dragon’s landscape with a more critical eye. I’ve started mapping the dungeon, listing all the intertwined business rules that are driving the complexity of the code I have to fix.

Rather than driving me back and beating me down, my previous attempts — and failures — have become an integral weapon in my arsenal. I know what doesn’t work, and more importantly, I know where the dragon is likely to be lurking.

McGonigal is certainly right when she says that urgent optimism in the face of failure can be energizing.

A week ago, I was responsible for supporting 60 or so content editors in a content management system containing tens of thousands of content items, fixing bugs and adding features to a burgeoning legacy system with business rules that get more complex with every passing day.

But this past week? This past week I was playing an MMORPG with 60 or so other players. Within the game’s landscape there are tens of thousands creatures, mostly benign, but each of those creatures has the ability to become a problem overnight. Every passing day, new challenges arise as the game’s owners — my client —toss new business rules into the mix.

Last Friday was a pretty good day in my new game and I was able to complete two major quests. The first was “The Case of the Untranslated Zombie Documents”, and the second quest was “Why Does this Functionality Break in Internet Explorer 10?”.

The root cause in the second quest turned out to be caused by the change to the User Agent string reported by Internet Explorer. It turns out that the CMS we use is looking for “MSIE” in the navigator.userAgent string. However, with IE 10 and later, the User Agent string no longer contains “MSIE”; instead, it reports “Trident” (among other strings).

In that particular quest, I found the reason why the functionality broke, but I don’t have a fix for it yet. But, now that I know the root cause, fixing it is just a matter of time before I finish the quest and can move on to new challenges. No matter what happens, I can’t wait to get back to my game tomorrow.

I’m having fun at my job once again. Are you?

What support battles are you facing? Can you change your thinking and make it a game?

Support and Maintenance can seem like an epic battle, but it is a battle we can win.

Let’s start Winning Support!

1 Jane McGonigal, Reality is Broken (New York: The Penguin Press, 2011), 69.

Friday, May 9, 2014

Putting the Most Important Things First

Twenty years ago today, on May 9, 1994, I had one of my greatest personal work-related triumphs.  It was a Monday, the day after Mother's Day.

For the past six months I had been leading a development team creating a completely new version of our company's software.  This particular application was my baby; I had designed it and had convinced the company that it was best way to handle a growing customer base and getting our clients off the old, buggy, single line-of-business software.

Not only had I designed it, but the company had even let me name this new product.  I was intimately familiar with all of its files, all of the code.  I had a great team working with me, and we clicked like a well-oiled machine.

On that day, we had installed the software at a major client's headquarters, as a Beta Test site.  We spent the day hand-holding the users, going from desk to desk, answering questions and giving pointers.  Sure, we had a few glitches, not the least of which was the discovery that the memory manager that I had designed was not up to the rigors of the abuse the clients were giving it.

But, all in all, it was a banner day, a day which I count among one of my greatest career achievements.

Around 7:30 that evening, we were exhausted.  The team was gathered in the server room, analyzing dumps and traces, trying to figure out how we were going to replace the memory manager.  We were laying out the schedule for the next day and handing out debugging, code-fixing, and hand-holding assignments.

Suddenly, the group leader's pager went off.  He looked at the number, expecting it to be a client, and he said, "BobR, I think your wife is trying to get in touch with you."  This was before cell phones were commonplace, and I wasn't at my desk, so she had paged my boss.

I called her and got the news I was expecting to hear.

Twenty years ago today, on May 9, 1994, my Dad ran his last race, fought his last fight, and drew his last breath.  He had finally lost a very short battle with a fast-spreading cancer.

For the previous six or so weeks, he had been in the hospital in Los Angeles, his life ebbing away.  I had had to make the painful decision not to fly out there from Kansas City until the end, knowing that when I had seen him just nine weeks earlier, it was going to be for the last time.

At that moment, the problems with the memory manager were flushed from my mind.  My boss told the team that we were done for the night, and we headed home.  The problems with the software would have to wait.

It is difficult to provide Winning Support when you are faced with a personal tragedy.  It is difficult to serve others when our own lives are in turmoil.

I learned a couple of important lessons that day.

First and foremost, your family comes first.  Period.

Yes, I truly believe that we are to serve our clients to our utmost, but we also have to consider our family as our most important client.

If your clients are more important to you than your family, I would suggest that you need to take a long, hard, serious look at your life.  Clients are important, jobs are vital, and work needs to go on, but clients and jobs will not be around forever.  Your family, on the other hand, should be your refuge, your place of respite, your primary responsibility.  Cherish those around you.

If you have a husband, wife, partner, brother, sister, son, daughter, father, mother, or any other close loved one, then put down the mouse, step back from the keyboard, and give them a call.  Better yet, go see them and give them a hug.

The second thing I learned is how important it is to have a good team around you.  Over the next day, I had to develop a work plan for the team, reassign all my work, bring a team member up to speed on the memory manager, get ready to fly across the country, design a headstone, and prepare a eulogy.  I had an awesome team and they all stepped in and supported me in my time of grief.  And the work got done without me.

If you are a one-person shop — if you are all alone in your position — do yourself a favor and find a friend.  Buddy up.  Cross train someone.  Do some pair programming.  Find someone who can help shoulder the burden when you need help.

Providing Winning Support is an endurance race, not a sprint.  Take care of yourself, take care of your family, and then take care of your clients.

You cannot serve others well — you cannot provide the type of Winning Support of which I know you are capable — if you aren't putting the most important things first.

Others stepped up to help me when I needed it, and I want to pay back that favor.

If you need some help, I'm here for you and will help in any way I can.  Feel free to leave comments below.  I would love to hear from you.  How may I serve you?

Let's start Winning Support.

Sunday, May 4, 2014

Winning Support Through Selflessness

On April 11, 1970, the Apollo 13 mission was launched with the goal of becoming the third time that humans were going to step onto the surface of the moon. Two days later, an oxygen tank exploded, which then caused the other oxygen tank to release its contents into outer space. This crippled the Service Module.

One of the primary functions of the Service Module was to supply power to the Command Module, which housed the astronauts. With only fifteen minutes of power left, the astronauts were forced to move into the Lunar Module — which had limited, self-contained supplies of oxygen, water, and power — and use it as a lifeboat.

Instead of trying to land the crew on the moon, the mission became focused solely on bringing them back safely to earth.

For the next four days, extraordinary measures were undertaken by the NASA support staff. Flight technicians stayed at their consoles around the clock, working on every conceivable aspect of the rescue mission. Calculations for consumables such as oxygen, battery power, and water were fed into the computers. Engineers had to write completely new procedures and test them thoroughly, in just a matter of days. Simulations were run, checked, double-checked, rerun, and then re-verified.

Their selfless devotion was successful, and on April 17, 1970, astronauts Jim Lovell, Jack Swigert, and Fred Haise landed in the South Pacific Ocean. The story of the rescue became the stuff of legend, spawning books and a blockbuster movie.

The survival of the crew and their safe return stands as an incredible example of Winning Support.

Mission Control staff supported the astronauts by designing new solutions and in giving detailed instructions by which to carry out those solutions. They didn’t have email in those days, so Communications staff supported the Mission Control technicians by relaying messages between consoles using a pneumatic tube messaging system. In fact, they even delivered sandwiches to the Mission Control room using that same system.

One of my former managers was a computer programmer for a NASA sub-contractor. She supported the engineers who were performing the calculations and running the simulations. She spent the entire rescue mission in the basement of the Johnson Space Center hand-checking printouts of diagnostic calculations made by the computers to make sure the computers themselves weren’t malfunctioning. She slept only while waiting for the printers to finish churning out the next report to be checked.

There are many lessons to be learned from studying the Apollo 13 rescue mission even though most of us are not rocket scientists or hold others’ lives in our hands. Whether we provide support for nuclear plants, hospitals, office software, video games, or content-driven web sites, there are lessons that can help us provide Winning Support to our own clients.

One of the most critical elements of the Apollo 13 mission was the attitude of all involved: Failure is not an option. Each person involved with the mission had to be selflessly devoted to the astronauts, putting the needs of the crew and of the mission ahead of his or her own needs. In effect, the mission support staff had to adopt an attitude of servanthood toward the crew whose very lives depended upon it. The consequences of not following through on their tasks did not have to be explained.

In my own quest to provide Winning Support, I have had to ask myself some tough questions:
  • How much of a servant’s attitude do I bring to my job in supporting my client and in maintaining our software?
  • Do I put the needs of my end-users above my own?
  • Am I putting others first?
  • Am I here to serve my clients or am I just collecting a paycheck?
I have found that how I answer these questions has a direct bearing on my own job satisfaction, and I am absolutely positive that this is especially true in a Support or Maintenance role. The ongoing, day-to-day grind of facing never-ending problems from the field has the potential of eroding a person’s soul. The Internet is full of stories of Support technicians who have erupted towards their clients, walked off their jobs, and ended their careers in frustration.

I don’t want to be one of those stories, and I’m pretty sure you don’t want to be, either.

From painful introspection, I know that when I have not had a servant’s attitude toward my clients, my job has seemed frustrating. When I have put my needs first, I felt like I ended up in last place.

But yet, that same introspection reveals that when I have been most fulfilled in my career — when my job satisfaction has been the highest — the needs of the users have been first and foremost in my mind. My best work — my most creative solutions — have come when I have tried to solve their problems, and not my own.

Napoleon Hill was a man who studied the movers-and-shakers of the early 20th Century and tried to encapsulate the secrets of their success. He became successful in his own right, becoming an advisor to two Presidents of the United States. He commented on this very subject, saying, "Great achievement is usually born of great sacrifice, and is never the result of selfishness."

The support staff at Mission Control whose efforts brought back Apollo 13 exhibited that sacrifice and unselfish behavior.

Compared to Apollo 13, our jobs might be considered mundane, and lives may not hang in the balance. However, I believe that if we put our clients first, we will achieve great things; and if not great things, then great satisfaction.

The best way to serve our clients is to follow good, solid principles in our code. We can make life easier for them by making our software easier to use. We can provide clean and efficient solutions. We can clean our code so that future changes in requirements have a minimal impact.

Winning Support starts with an attitude; only time will tell where that attitude will take us.

Let’s start Winning Support.

Sunday, April 27, 2014

Winning Support

Hi.  My name is Bob Rench, and I've been involved in all aspects of software development since the early 1980s.  I started programming in high school on an Apple IIe, and in college, wrote my first commercial program in dBase II, running on an Osborne 1 luggable.

Since then, I have worked for huge, medium-sized, and tiny companies.  I've worked for multinational corporations, as well as for companies so small that we held all-hands meetings over lunch at Olive Garden.

I have designed and implemented enterprise-level software, both pre- and post-Internet; from old-school fat-client software applications to web sites and web applications.  I'm a survivor of the OS battles of the 90s (hint: OS/2 lost, but shouldn't have), the browser battles of the early 2000s (go Netscape … er … Mozilla ... er ... Chrome), and the managed-code skirmishes between Java and C#.

I've seen a lot of things come and go in the last 30 years, but, no matter what new technology comes along, somebody still has to support the clients and maintain the software.

Support and Maintenance.  Ugh.  (I heard you.)

It’s a necessary job, and isn’t glamorous.  Sometimes, it can be extremely frustrating dealing with all kinds of headaches, from systems that just stop running, to data that gets corrupted, to users who don’t know how to run such well-crafted, thoughtfully-designed, well-engineered software.  If you are lucky, you only have to work on one issue at a time, but typically, it’s more like playing Whack-a-Mole.  On a machine that doesn’t register the hits.  While drunk.

Some days, things can be so quiet, you might say to a friend, “You know, things are really going great!  My queue is empty, so I’m going home early to relax.”

And when you come in the next day, you wish you had not tempted the software gremlins; before you know it, three weeks have gone by with no end in sight.

Even if you love solving problems (admit it: finding a solution when everybody else has failed can be such a rush!) Support and Maintenance roles can often feel like a soul-sucking swamp, and you can’t wait to find another job — any job!

If that is how you feel, then I think you’ve come to the right place.

Maybe you’ve been slogging through the swamp for a while, wondering if you’ll ever get through it to firmer ground.

Maybe you’ve just started your career, and somebody had the brilliant idea of putting you on the Support or Maintenance teams to learn the software, but dealing with legacy spaghetti code is driving you crazy.

Maybe you have a tough support issue and need some lateral thinking.

I know how you feel, because I have been there many times in the past.

Recently, I was asked to take on support for a large, legacy website.  Maybe I had forgotten how much I disliked support in the past, so I said, “Sure, why not?”

Perhaps I’ve matured, or maybe it’s because I love being challenged by multidimensional puzzles, but I can tell you that I don’t feel like I’m stuck in a swamp like I did on my last Support gig.  Instead, I have found that a Support and Maintenance role can be satisfying.

I currently work at the world’s largest digital-marketing company; a company whose clients include some of the biggest names in the airline, fast-food, beer, sports, and financial industries.  I am privileged to be providing support and maintenance for a Fortune 100 company, managing an international website, and supporting content editors who are working in nine languages, including French, Germany, and Chinese.

Like any living, breathing system, our website has evolved over the past few years.  That evolution and growth has required providing creative solutions to meet new business needs, while at the same time, making sure the old business needs are being met, and all the business rules are followed.

But, no matter how well-planned the changes, no matter how creative the solution, no matter how disciplined the developers, no matter how thorough the testing, things happen; things break.

When things break, my job is to fix them.  But I don’t want to just fix them; I want to take the steps to make sure they don’t happen again.

After thirty years, I’ve grown weary of stumbling across the same problems project after project.  And no, I didn’t create all those problems.  Most problems I encounter were created by a combination of poor design, changing requirements, creeping scope, and shrinking budgets.

But, we all know there are better ways of doing things.  Lately, the development landscape has been shaped by powerful forces, such as:
  • The Pragmatic Programmer by Andrew Hunt and David Thomas; 
  •  Clean Code by Robert C. Martin (“Uncle Bob”); and
  • Development philosophies such as Agile, using Scrum, eXtreme Programming, Kanban, or Test-driven Development.
These are great tools to have at our disposal.  But, there is a lot of legacy code around that was not developed cleanly.  Or, how many times have we known that there was a right way to do something, but were forced by budgetary or time constraints to just get it working, and then fix it later?

Usually, “later” never comes.  And, once again, we’ve made the same mistake our predecessors did.

It’s like playing a video game where we have to kill the monsters in a particular room.  We enter the room, turn left, and get pounded by the monsters.  We re-spawn, re-enter the room, turn left, and die once again.  We keep losing the game because we keep making the same mistakes.

Let’s start doing things the right way.

I want to become better at my craft.  I want to become more disciplined as a developer and more creative in my problem-solving.  I want to improve.

I want to provide outstanding service to my clients; after all, they allow me to have two things that I really enjoy: sleeping indoors and eating.

We can do this.

Let’s start Winning Support.