Oracle Blog

The philosophy, art and science of software project leadership

Breaking The Fourth Wall

The term "fourth wall" is used in performance art to describe the invisible barrier between
the actors and the audience. On occasion, a performance will "break the fourth wall" by
having an actor address the audience directly. While there are many examples in classical
plays, my own vivid memory of one example is of the Burns & Allen Show on TV, when
George Burns would turn directly to the camera and talk to the audience, one-on-one, about
what was transpiring on the show. There actually was no audience on the set, just a
camera, but Burns broke the fourth wall just by acknowledging that an audience eventually
would be watching the show.

As product development engineers, we often hide behind the fourth wall that separates
us from our customers, the end-users of our product.
We work on products, oblivious to the fact that they eventually will
be interacting with our customers. We sometimes design products for ourselves instead
of our customers, or ignore annoying little "features" that might drive customers
crazy hoping maybe no one would notice, or design individual products without much
consideration how a customer will assemble them into a system. In effect, we act on
a soundstage in front of a camera, oblivious to the audience behind the fourth wall
that will eventually view our performance.

Last year I had a rare opportunity to meet with a large customer. I got to
break the fourth wall. This customer owned hundreds of our products, from desktop
machines up to multi-million dollar high-end servers. Along with a couple of
senior engineers from the other product families, we were to present our low-end,
mid-range and high-end product roadmaps. While I went into the meeting with excitement
and pride, I crawled out of there feeling like a wounded puppy. And I would go back
in a second.

In the meeting, the first thing the customer mentioned was connectors. Connectors?
We wanted to talk about processor architectures, memory capacity, and IO options. Who
cares about connectors? Well, the customer cared. On our current high-end products,
the serial console connector is an
DIN connector, similar to most keyboard or mouse connectors. They found that
if the cable is bumped or tugged, the DIN connector could fall out, requiring
physical access to the datacenter to re-insert the cable. And
very few individuals were allowed physical access to the datacenter. "Why couldn't
you use a captive connector, like an RJ11 or DB9?" they asked. I had no answer.

The next issue they raised was the command line interface for managing our
products. Each product family had different commands. And when two product families
happened to have the same command, the options and arguments were often different.
"We have to train our employees on three different command sets," they explained,
showing a "cheat sheet" they issued to all their system administrators showing how
to do the most common tasks on each product line. "Why can't you have one set of
commands for all your products?" Again, I had no answer. We had created a great
command line interface for our product line, with exactly the features and options
our product needed. The engineers working on the other product lines did the same
thing for their products.

The honest answer to both of the questions is simple: We failed to break the fourth
wall before we shipped the product. The customer knew the answer; they were just
trying to make a point and get us to realize it ourselves. Aside from the tongue
lashing, the customer did praise our products: we did a great job engineering our
products, but we could do better. And the customer expressed how happy they were
that we development engineers were coming to visit them -- they were glad to see
the fourth wall being broken and hoped that our encounter would have a lasting
impression. It did.

In development, we need to break the fourth wall -- the invisible barrier that
separates the developers from the customers. We need to see how customers
use our products, understand their issues and concerns, and internalize their
pain. And nothing helps internalize pain than feeling it first-hand. It's not
enough to read articles, or listen to stories second
or third hand. I learned a lot from that customer visit; the people who listen and
read my story might only learn a small fraction of it. We need to get all of our
developers out in the field, meeting with customers directly, accompanying our
Service Engineers on customer calls, shadowing our Tech Support Engineers in our
Call Centers, and talking to our Field Engineers (who in many ways are our
customers as well). When we break the fourth wall, both our products and our
customers will benefit.