Skew, The Frontend Engineer's Misery

A popular explanation of the distinction between frontend versus backend engineers is that frontend engineers ¹ require a broader range of technical skills and backend engineers necessitate a more focused skillset. This view of the frontend engineer as a technical generalist leads some to view the frontend engineer as a technician to the backend engineer's craftsman, but the frontend engineer's role as a generalist is not restricted to technical matters; they are a generalist in a broader sense as well.

Within a healthy team, backend engineers are communicating frequently with product managers and occasionally with frontend engineers as well, but the backend engineers usually speak with an air of authority. When an expert speaks, you listen. On the other hand, pretty much anyone is ready to stand up and teach the janitor how to mop the floor.

With limited influence, unlimited hands in the pie, a low barrier to critique, and the perception of triviality, frontend engineers are the janitors of software development. Rather than cleaning up trash, the boulder they toil beneath is skew: the distance between team member's conceptions of a project.

Cleaning Toxic Waste With a Broom

Skew shares the same relationship with software development that radioactive waste shares with generating nuclear energy: it's an unwanted byproduct that's difficult to despose of. From the first moment a project is conceived, there will be disparate views of the project's goals and purpose. Early on these differences tend to be lofty and high-minded, but over time these inconsistencies blossom into uncomfortably tangible roadblocks.

The growth of skew means that--when you reach the time for integrating components--you'll find that everyone built female adaptors and was pretty sure someone else was building the male, but no one quite confirmed who it was.

Skew is pain. Skew is your pain.

Misconceptions That Plague FE Engineers

You might argue that frontend engineering shouldn't be the group combatting product skew. Isn't that product management's job? Or engineering management's job? This isn't my job, right? Unfortunately, reality doesn't read job descriptions, and whether or not you're supposed to be responsible, reality is going to prepose skew right between you and success.

There are a number of perceptions which contribute to skew's impact on frontend engineers:

• FE engineering is... trivial.
• FE engineering is... cosmetic.
• FE engineering is... just implementing a design.
• FE engineering is... just implementing a user experience.
• FE engineering is... the place to solve inadequacies in the backend.
• FE engineering is... easily comprehended even by non-technical individuals.
• FE engineering is... easily comprehended by technical people of other disciplines.

These perceptions play out in devious and predictable ways.

Skew Scenario 1

For some reason your backend stores blobs of JSON serialized arrays, but wouldn't it be cool to edit entries individually? Someone latches onto the idea, and out of nowhere it crystalizes into a product requirement. The backend engineers are behind schedule, and they're saying it will take a week to rewrite the system with the new interaction paradigm. That's okay, the frontend can just manage the interaction with some JavaScript.

For the frontend engineer it isn't even worth arguing over, because they're going to have to completely rework their interaction either way. Actually, by sticking with the current system they can work with a static api instead of with a changing one that breaks in exciting new ways, so the FE engineer goes ahead and makes the change.

Now the backend engineers view the product as operating in blobs, the frontend engineers understand it as a mishmash of blobs and entries, and everyone else thinks it operates on entries.

Congratulations, you were just skewered.

Skew Scenario 2

You're pretty much done with your product, but there is still some discussion over the copywriting and a few other details. You notice someone is being a bit quiet and fixating on something. Or they might be playing tetris on their phone. You hope it's the tetris, but they're starting to try to interject something. A few minutes later they succeed: We should really display those messages in popups.

"No", you argue, "that's actually a rather substantial change to the architecture."
"What?" they chuckle "everyone is using popups now. Users like popups. It must be easy."

What you actually want to say looks like this:

But what you actually say is closer to:

"Displaying error messages in popups means I need to know the impact of actions before I leave the current page. This is easy to do if it's designed this way from the beginning, but isn't something that can be bolt on as an afterthought."
"Everyone has popups. It can't be that hard. I think my nephew added popups to his site. He's five."
"Err, well, because of the involved application logic, this adds a lot more complexity than just a prompt."
"Well, I'm pretty sure everyone really wants these popups."

Skewered once again. This time it's because the frontend engineer sees managing errors on submission with popups as an involved modification, but to others they seem interchangeable. Not only are the two groups' perspectives skewed, the frontend perspective isn't on other groups' map.

Why You'll Pick Up That Mop Anyway

Whether you're convinced managing skew is your job or someone else's job, you're going to end up fighting it anyway. Any philosophical concerns are trumped by the most practical teacher: pain.

• The perception that frontend work is relatively trivial (compared to backend work) and because there are so many groups who own piece of the frontend (designers own appearance, user experience owns interaction mechanisms, product owns other pieces) means the frontend engineer sees skew early on and from every angle.

  The frontend engineer has to speak with everyone, and they have to delve into the details, which is where miscommunication becomes most apparent.

• If you ignore the designer's skew, then you're not implementing their design. If you ignore product management's skew, you're not implementing their vision. And so on.

  Reduced ownership directly translates to increased vulnerability to skew.

The frontend engineer is going to end up dealing with skew, because they are the least able to avoid or ignore it. The frontend engineer deals with skew because they're tired of getting skewered.

Reducing Skew

There are some ways for reducing skew, some more effective than others. While recognizing the irony of this statement, by far the least effective way of preventing skew is to tell other people about it. Although the vocabulary for discussing skew varies between individuals and groups, everyone is already aware of it, it's just that they don't feel skew's pain as acutely as the frontend engineer does. Education is a noble ideal, but you can't wait for people to get it when your sanity is hanging on a string.

Here are some of the strategies for combatting skew. You'll notice that these are predominately organizational changes, rather than intermediate bandaids for the current process; you don't perform triage in a morgue.

• The staple last-line-of-defense of engineers is to say No, or perhaps It isn't possible, or for the tactical sorts perhaps There are non-trivial implications to that requirement.

  I don't think this works well for the frontend engineer, with their reduced ownership and the looming impression of triviality of their work. Saying no is always a gateway to glares that accuse incompetence, but saying no when people think you're refusing to ride a tricycle and interfering with their job at the same time... that takes the pain to another level.

• The best defense against skew is having as small a team--and with as few compartments within the team--as possible. This is why small startups have almost no skew. When the frontend guy is the designer and the product manager and he just needs to talk to the backend guy, there isn't that much room for confusion, and cleaning up confusion is pretty straightforward.

• Give the frontend team greater ownership of their product. Skew arises between groups, but skew is amplified by one group designing what another group must implement. This is not only the case for designers and product managers architecting a frontend, but also for software architects designing a system for other engineers to implement.

  Dividing architects from implementors is not only frustrating for the implementor, it's a direct path to skew.

Winning By Degrees

A better writer would have saved an epiphany for the end. I didn't. Project skew isn't going to end anytime soon. It was skewing up projects before Fred Brooks and it's been screwing them up ever since. It's an uphill struggle, but sometimes you can win a battle against skew even thought you know you're going to lose the war in the long run.

Today, I'm okay with that.