July 22, 2019
An analogy I’ve used to help explain frontend vs backend programming to non-techies
I don’t exactly come from a long line of computer scientists. My father worked as a waiter for decades after immigrating to the United States; my mother is a lifelong special education teacher and (recent) administrator.
As such, I’m often looking for ways to explain what exactly I do while haunched over the computer for substantial portions of my day. Talk of unit testing, functional programming and flexible user interfaces are received with the same enthusiasm as an extended lecture on ancient Assyriology. While both subjects may be of keen interest to me, if I don’t take the time to frame my explanations with real-world concepts and examples I may as well be speaking another language.
As a fullstack developer, one of the concepts that comes up most often is the distinction between frontend and backend development. It’s a subject that many understand in principle: tech companies have big servers that do computer-type things behind the scenes. If need be, these servers can be hacked on TV shows by pounding random characters on your keyboard with a worried expression.
Pair programming at its finest.
Try to explain any further, though, and you’re wading into dangerous territory. There’s a metaphor I’ve used in the past that has worked decently well:
The frontend is your experience of liking a post on Facebook. The backend is what Facebook does behind the scenes when you like a post.
For the most part, this analogy accomplishes its stated goal: giving the listener enough context to change the subject without exposing their lack of knowledge or interest. But to me, the comparison is too direct, too close to the subject matter to be truly useful.
Recently, I’ve been using another point of comparison that I believe paints a more vivid picture of the responsibilities of frontend and backend dev. The comparison? Restaurants.
When the comparison first came to me, it seemed so obvious that I was sure someone had thought of it before:
Frontend development is everything you see as a diner in a restaurant: the interior decor, the music, the atmosphere, etc. Backend development is everything that happens in the kitchen: buying ingredients, creating new dishes, and, of course, cooking the food.
In essence, instead of asking people to picture Facebook itself, I ask them to imagine Café Facebook. As your typical listener will have more experience with restaurants than server farms, they’ll have more information to fill in the details of your analogy on their own terms.
There are a couple reasons why I find restaurants to work well in this scenario:
1. Frontend development maps well to restaurant design.
Going over the details of an appealing restaurant atmosphere is a good way to think about the multifaceted skills necessary to excel in frontend development. When one explains frontend development in isolation, there’s a tendency to view the process as glorified graphic design, where developers copy-pasting Photoshop documents into HTML to create pixel-perfect designs instantly.
While we developers might pine for that reality, our jobs are not nearly that simple. From accessibility to security to performance and more, frontend developers regularly juggle competing tasks and priorities when deciding how to build interfaces.
Similarly, running a successful restaurant dining room requires much more than Instagrammable decor. Every choice, from menu design to table placement to employee schedules and obligations, must be carefully considered to meet complex and sometimes capricious customer desires.
Importantly, looks are far from the whole story. If the cutest table you find online wobbles uncontrollably upon bearing the slightest weight, you’ll find yourself cursing as you pick up yet another plate of food knocked off the table by a wayward elbow. The most successful restaurants balance form and function with every decision they make to maximize aesthetic value without compromising on quality.
2. Backend development maps well to kitchen logistics.
Just like website backends, kitchens are the hidden hearts of restaurants. Tucked away from public view, kitchens nonetheless provide the experience that no restaurant can survive without: the food.
Because the goings-on of kitchens happen away from the spotlight, much less concern is paid to aesthetics. The chef’s knife doesn’t need to be photogenic; it just needs to cut food well and quickly.
This isn’t to say that backend developers can afford to be sloppy, just as chefs cannot be careless with customers’ orders. While we may laugh at memes suggesting that all website backends are dumpster fires hiding behind shiny exteriors, all good developers pay close attention to their craft regardless of frontend or backend speciality.
Rather, good backends are designed to be resilient: failures of individual services shouldn’t crash the entire application, and all technical details should be hidden from the client as much as possible.
I’m sure you’ve never been to a restaurant that told you, “I’m sorry, your food will take longer than we expected. Our new waiter sneezed into your gazpacho because of the dust clouds lingering in our kitchen.” Oversharing in this way is a good way to guarantee your customers won’t return again, even if your second gazpacho is Michelin-worthy.
Similarly, a good backend shouldn’t confuse users with esoteric error messages and obscure references to missing methods and properties. Instead, it is the job of backend programmers to detect these errors and send human-friendly error messages that tell users in straightforward terms what, if anything, to do to fix their problems.
3. Websites and restaurants can specialize in either dimension, but the path to success often involves mastering both.
Some of my favorite restaurants are hole-in-the-wall establishments making only the slightest of concessions to diner experience. Like many other diners, I forgive these restaurants their lapse in aesthetic taste because their food, to use the official term, is really frickin’ good.
I’m sure many of you have had similar experiences with websites as well: the design isn’t going to win any awards for originality, but the site works as advertised.
Funnily enough, neither restaurants nor websites tend to work as well the other way. I’ve seen many a restaurant spend more time on interior design than on food; until Instagram pays out restaurants based on number of checkins, these businesses are often doomed to failure.
Now, it is possible for websites to focus exclusively on frontend design — but only if these websites are strictly informative in nature. Static websites can, and often do, thrive with only the barest of backends powering them behind the scenes. However, as soon as the contact form on your website doesn’t work or your orders aren’t properly placed on checkout, not even the sleekest of designs will save your website from quick abandonment.
For this reason, for restaurants and websites alike, the surest path to success is to focus on both frontend and backend development. Cohesive vision and comprehensive execution will do more to win over lifelong customers than a narrower focus on one aspect of the user experience at the expense of other parts.
There are other places you can push the metaphor: for example, client-side vs server-side rendering as cooking table-side vs cooking in the kitchen. However, the point of this column is to help provide developers with better language to explain the basics of what we do. If you’re trying to explain server-side vs client-side rendering to your grandmother over Thanksgiving dinner, I recommend taking a step back and reconsidering your options.