On the Ephemera of 'Front End'

Picture two teams. Team A has complaints that Team B produces buggy code and does not write tests, yet is heralded outside engineering as a fast-moving team. Team A tests their code, and has a lower incident rate, yet does not receive the same recognition outside engineering.

Team A is asked to prioritize its roadmap around Team B’s needs. They don’t like this.

Team A asked me to do something about the situation and the suggestions fell into three buckets:

• I should talk to Team B’s manager. Force these developers to test their code.
• I should talk to other teams (e.g., SRE, ops) to have more safeguards or barriers to keep Team B from releasing broken code.
• Influence senior leaders (i.e., VPE, CEO) to recognize other, more high-functioning teams.

What would you guess if I were to ask you which team, A or B, focused more on “front end” versus “back end”?

You’d be right if you guessed Team A involved more back-end work. But this isn’t a post about “back end” versus “front end” nor “right” versus “wrong”. Instead, this is about a resulting thought experiment.

What is the shelf-life of your codebase?

If you were to learn that your codebase would be in production for ten years, what areas of the code would you test, and what would you not test?

What if that shelf-life was reduced to two years?

What if that shelf-life was reduced to one year?

My point is we are terrible at predicting the shelf-life of codebases, particularly at startups. There are examples where companies end up acquired or go out of business, and it doesn’t matter. There are examples where a throw-away prototype accidentally becomes the company’s flagship product (much to the disdain of every engineer subjected to the hacks therein).

None of this keeps engineering teams from trying to guess what will happen to their codebase. After all, nobody sets out to work on a codebase that will eventually die (we also don’t hire for people who expect their codebases to die on the vine, but that’s a separate matter). We also like to think what we do is important and that what we build is built to last.

Reality has other plans.

What if you could afford to throw it all away?

How cheap does a rewrite need to be for you to plan the obsolescence of your current codebase? If it were cheap enough to toss and rewrite, what areas would you test today, and what would you not?

Front ends aren’t necessarily “cheaper” to throw away than back ends, but the truth is many companies (and engineering teams) act as if they are. This curious observation has a tail wagging the dog effect, but it also suggests that certain kinds of front-ends should be made cheap enough to throw away: Landing pages, progress indicators or interstitials, etc. And there are things which will always be expensive to throw away: Sign-up and checkout flows are two such areas with some exceptions.

In a future post, I’d like to explore what potential effect GitHub Copilot may have on how teams approach this question. It’s too early to know, but I have a lot of thoughts about that.

So, how did my real-world example turn out?

If it were easy to answer this, I’d do so. The truth is it was hard to parse the real problem at the time.

The biggest issue for Team A was not feeling recognized nor respected by senior leadership for the stability they provided. Behind this was a fear that the “throw shit at the wall, see what works” style of development they saw from Team B would grow to define all engineering (probably true). A common form of blindness in many organizations is failing to see what’s not broken after all.

What Team A did not see was the stress put on Team B. You can begin to see the real issue was as much engineering culture as any question of testing philosophy. I can’t say the solution solved itself as much as it faded to the background as the company matured.

Outside forces (i.e., shifting company strategy, change in leadership, P&L) always outweigh technical concerns. Nothing exists in isolation. This isn’t the most satisfying answer, but there you go.

And what happened to those codebases? Did Team B’s codebase get thrown out? Not immediately but nothing ends in a bang as much as a whimper: priorities shift, new front ends are written, people leave, new people get hired and other teams wrote those front ends.