Thinking Outside the Engineering Box

This story about his experience as an engineer in the dot com era by the late Seamus Young should be extremely enlightening, for engineers and non-engineers alike, as it has the benefit of providing us with not only the communication that took place in the meeting, but also what he was thinking about it at the time. Keeping in mind that this is nominally written from the perspective of “the engineer is the good guy who knows what he’s doing and what he should be doing”, see if you can identify the fundamentally destructive element described in the following vignette.

John Business seems to be the most important guy in the room. He’s also the guy who narrated the pitch video. He’s seemed happy so far. But now he turns to me and asks, “Can we start visitors outside of the mall? We have this grand entryway and we want them to be able to see it before they go inside.”

I scrunch up my face. “Yeah guess you can. But people like to teleport because it’s more convenient…” I trail off. John Business looks confused. Did I mess up and give him some jargon?

“Shamus means they like to appear and disappear in different places rather than walking.” My Boss is clarifying things for me. That doesn’t happen very often.

John Business nods. He gets it now.

Holy shit. This guy doesn’t know what teleporting is? I guess the whole video presentation he just narrated made him seem a little more tech-savvy than he really is. Okay, I need to step this all the way down to neophyte language. How the hell did someone with such a limited understanding of virtual worlds end up in the deep end? This guy doesn’t seem to know enough to launch a web-based business, and he’s going to oversee the construction of a virtual one?

I nod at my boss. “Right. One of the advantages of virtual space is the way people can move instantly to their desired location. Making them ‘walk’ for a long distance before they can begin using the software will just make them reluctant to log in. And unless we change it every few days, they will quickly tire of the entrance.”

John Business looks annoyed. My boss shifts nervously in his seat. I’ve messed up again. I’m evidently offering guidance above my pay grade. John Business asked me a simple question about a simple task and now he seems to think I’m trying to weasel out of doing it. Possibly he suspects I’m a slacker. They don’t want my artistic input. These guys have already designed the place. They just want me to answer the question.

My boss steps in to smooth things out. “We’ll have them start outside and see how it works out. We can always change it later.”

I nod. Fair enough.

John Business also nods, perhaps ticking off a mental checkbox before moving on to the next question.

It goes on like this for half an hour. He keeps asking me to do simple things that would be impractical, annoying for the end user, or harm usability. He’s trying to make a world not just for people playing “a videogame” for the first time, but people who are overall new to the internet. I want to educate him on why the design is wrong, but I can’t seem to do so without violating some sort of unexplained social order. Usually I pride myself on being able to smooth out misunderstandings and bring people up to speed, but right now I find myself falling into the role of the “obtuse, obstructionist engineer” and I can’t seem to break out of it.

What’s wrong here? Our company is typically good at this stuff. We’re usually pretty adept at bridging the gap between what the customer asks for and what they actually need. But this meeting is running sideways and the power dynamics are all wrong. For some reason, John Business seems to regard me with… is it suspicion? I don’t know. But there’s a communication problem here and I can’t seem to solve it.

Without trust, every time I say “no” or “Yes, but…” it irritates John Business. And that makes my boss nervous, which eventually makes him frustrated with me. So it feels like the room is against me, which makes me nervous and panic-y, which makes me stammer and vacillate, which makes me sound even more untrustworthy.

John Business returns to his printed notes. “When a visitor clicks on an item on a shelf, can we have it fall into their shopping trolley?”

I somehow resist the urge to make a horrified face at the suggestion.

People are going to push shopping carts around your virtual mall? Doesn’t that have the stench of low-end shopping? Will the carts collide with shelves? If so, then people WILL get stuck, frustrated, and log out without buying anything.If not, then expect people to navigate as if the cart didn’t exist, which means they will constantly end up clipping into walls. Everywhere you go, you’ll have the front ends of shopping carts peeking at you through walls and shelves. In addition to being really ugly and immersion-breaking, this will be confusing to people. And don’t even get me started on the ways people might confuse or harass each other with them. What if I leave a store without paying? Does my cart vanish, or is it cleared? Will the items be restored if I return later? We need to figure out what the “expected behavior” is going to be before we know how to design this.

Isn’t the advantage of a VIRTUAL mall the fact that you don’t need to worry about the physical hassles of carrying items? I know in your head you’re picturing people simply replicating real-world behavior, but that’s not going to happen. People will act in ways that don’t make sense. What if I click on an item that’s nowhere near my cart? Should the item fly across the room and land in the cart? If so, then expect new users to be confused by random items flying all over the place. Or you can give them an error message telling them to move closer. That will stop the flying merchandise, but now you’re inconveniencing people trying to buy stuff.

How will they get items back out again? Physics engines that operate in a shared space are years away, so making them rummage around a pile of loose items won’t work. What if they want to remove an item from the cart and it’s buried under others? What happens if I go to the other side of the store and then remove the item? Should it fly across the store to where it belongs, or should we replicate the real world where fickle shoppers constantly scramble your inventory by abandoning items in random parts of the store? Or should it just poof away?

What I actually said:

“Sort of. We can show an object falling into the cart.”

“But will the object disappear off the shelf?” This point seem to be awfully important to him.

You… you want to create a virtual store with scarcity? WHYYYYYYY? Madness! If this is possible, people WILL try to empty the shelves into their cart so that nobody else can buy anything.

What I actually said:

“No.”

The actual answer would be “It depends”, but it would be long and complex and I sense everyone is just looking for simple answers to complex questions. We could make shelves that deplete of stock and need to be refilled, but this would create all sorts of interface headaches and the need for a bunch of new coding, because we’d need to create a program to track the position of all items and handle restocking them. I can spend ten minutes explaining that the timetable is already WAY too tight and there’s no way we have time to code experimental new features with unknown challenges for purely cosmetic effects.

The meeting drags on like this, with John Business casually asking for monumentally difficult things that will make the store less useful in order to re-create the limitations and frustrations of the physical world.

Crash Dot Com Part 3: The Meeting, TWENTY-SIDED

I’m convinced that one of the reasons engineers are correctly viewed as needlessly obtuse and obstructionist by the rest of the business world is that too few of them have ever played team sports and the concept of “do your job” is therefore intrinsically foreign to them. Or, to be more precise, “don’t do what is not your job”.

Did you see what the fundamental problem with the engineer’s attitude is? Here’s a hint: it’s a fundamentally Gamma action.

What’s remarkable is the way that the engineer unconsciously elevated himself into an assumed authority that he flat-out does not possess. He’s not only “managing from below”, he’s actually taking it upon himself to “design from below” on the basis of a) his opinions about user preferences and b) his preferences about what he works on and how to work on it.

Even if he is 100-percent correct about the ultimate consequences, he’s 100-percent wrong to attempt to assume that authority, because he does not have the responsibility. Moreover, he doesn’t even want that responsibility; the best way to shut an obstructionist engineer up is to threaten to put him in charge of the project, including the sales and marketing.

But the most important thing for an engineer to grasp is that he does not have the whole picture, and that what makes zero sense in one context might make complete sense in a more significant context. Maybe the company wants to lose money. Maybe the company just needs to get something out the door to maintain its patent or its trademark. Maybe it’s not really supposed to be a working product, but a proof of concept that is a milestone on a corporate merger. Or maybe the executives are technologically ignorant and the lead designer is a lunatic with an insane and impossible vision.

Regardless, if someone asks you a question, it is literally never your job to infer from it what might be, unknown to himself, the unconscious motivations of the asker, then answer the question on the basis of your own interpretation of those hidden objectives and goals. Answer the question asked. Then, if necessary, talk to your boss later about your opinion that the nature of the questions indicated a high probability of future project failure from your technical perspective.

What’s remarkable about Seamus is that he eventually figured out the problem on his own.

Personally, I HATE the e-commerce / distance learning stuff. It’s dumb and boring and lame. One afternoon I’m standing in the aisle complaining about this when Roger takes me aside and explains that while the e-commerce stuff isn’t sexy, it’s actually an important revenue stream. Those business people might be boring and tedious to work with, but they have tons of money they’re willing to spend on this stuff. If it wasn’t for them, we wouldn’t be able to serve those aspiring game designers I love so much. The game designers are interesting people, but they’re broke as hell.

I slowly begin to realize why so few of my feature suggestions make it into The List™. I always argue for things in terms of how “cool” it will look and how intensely people want it, but I rarely make a business case for my ideas.

Crash Dot Com Part 6: The List™, TWENTY-SIDED

Business Lesson 101: You don’t make money by doing what you think is cool. You make money by giving other people what they actually want, whether what they want makes sense to you or not.

SSH Lesson: The more special and unique and technical you are, the less your opinions matter to everyone else. Unless asked, keep them to yourself.

PS: DM of the Rings is absolutely hilarious and the Remaster is worth re-reading.

DISCUSS ON SG