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 20^th 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.

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.