• November 5, 2015

Incident on Alaska 609: How to Avoid Getting Called Out by Software Engineers for Bad Design

Incident on Alaska 609: How to Avoid Getting Called Out by Software Engineers for Bad Design

150 150 Matt Woodward

tarmac_snackDelayed by Design

Our plane arrived late to the gate, and there was some extra mess that needed to be “properly” cleaned up, so we had to wait for boarding. The crowd was mostly tech professionals, coming back from several days in Las Vegas after learning about the latest updates to Amazon’s Cloud platform by day and going out each night. Everyone felt ready to get home to Seattle, and the air had an unusual buzz of conversation.

We boarded, taxied to the end of the runway, and stopped.

Several long minutes later, the pilot explained why: We needed to catch a break in traffic to leave. The plane was heavily loaded with fuel and baggage, one too many free T-shirts in someone’s carry-on.

As the pilot explained, this Boeing 737 was designed differently than others. If we took off with the traffic and an engine shut down, we wouldn’t have enough power to continue our climb and make it over the mountains. We needed a break in traffic, which should take at least another 20 minutes.

People began grumbling. You could tell they were tech people by how quickly they questioned why things were the way they were. “That’s terrible design.” “What was Boeing thinking?”

It’s All About Choices

This crowd had immediately decided that this airplane suffered from poor design. More powerful engines, fewer people on the plane, lighter materials, different wing shapes, many choices could have produced a plane that could take off like the othersone that should have had us halfway home by this point.

The pilot came on again. “I understand there are still questions about why we haven’t been able to take off.” He reiterated his explanation, estimating at least another half hour until there would be a break in the traffic. He asked the flight attendants to serve water and snacks.

Even after cookies were distributed, people were not placated. Questions persisted.

“Couldn’t they have designed it differently?”
“Why does the airline fly a plane with this deficient design?”

I struck up a conversation with one of the guys questioning the design. “This is the airplane they fly to Hawaii,” I told him. “It’s designed to fly long distances over water and return to land even if one engine stops. According to the pilots, we’re loaded heavily today. Under different weather conditions, we might be taking off with the traffic and none of us would be the wiser.”

As we talked, he began to understand why these choices were made, why we were in this situation, that it wasn’t all foolishness. This design was well-suited for long and over-water trips, and as a consequence, it didn’t have the right performance in this situation.

Define Your Purpose

Every day, software engineers are faced with choices that define not only the way they do their jobs but the resulting systems they’re building. They have to constantly ask their own questions.

What are we building this software to do? How are we building it? Should it be fast? Should it behave perfectly in all situations, like software controlling medical equipment must? Should it be delivered quickly? Engineered for future flexibility? Should it be complete, or should we build the minimum viable product required to get user feedback?

Everyone has their bias. The things engineers value tend to color their work. Prior to writing the first line of code, the team building the software needs to agree on why they’re building it, what the business needs, and what that means about how it should be built.

With our own personal points of view, it can be difficult to have the discipline to hear, understand and align the solution with the user problem and business context.

To grow our company quickly, we need to focus our resources on the right problem and solve it as quickly and correctly as possible, so we can get on to the next thing. The system design should reflect this. What we build might not be perfect for all situations. It just has to be right for our purpose.

Explain Yourself

In a world where a highly trained pilot can’t effectively communicate with a planeload of software professionals, communication between engineers and business leaders can just as easily fail, derailed by jargon and a lack of common context.

Engineering leaders need to keep reminding their teams of the top business priorities, focusing resources on solving the most important problems in a way that keeps the company growing. And everyone has to remember that the way we explain the reasons for our choices is nearly as important as the choices themselves.

As RealSelf’s Chief Technology Officer, Matt Woodward supports enterprises with systems ranging from mobile applications that fit in your hand to e-commerce search and transactional systems spanning data centers across the globe. After hours, you’ll find Matt at a hockey game, snowboarding or, on the rare clear Seattle night, observing the universe through a telescope.

If you’re interested in talking with Matt about opportunities on RealSelf’s technology teams, learn more about our open roles and get in touch.