Front-end Versus Back-end
Or, Sisyphus Writes Java Script
Why does front-end work seem like an ever-expanding grind while back-end work seems to have at least moments of calm?
I made this observation to Jessitron & she suggested I post it. Back-end work tends, in my personal experience & in my observations of teams, to reach a state of, if not completion, at least satisfaction. You start with a list of scenarios you’d like to handle (the Test List from Canon TDD). As development proceeds of course you discover new scenarios. However, that spawning generally happens at a rate slower than the rate of completion. Eventually you run out of work to do, at least for the moment.
Front-end work acts completely different. I again start with a list of scenarios. Every one I complete, though, tends to spawn two or more new items for the To-Do List. The front-end, then never feels complete. There are always a long list of potential improvements & that list gets longer by the day.
Once the system is in production, some of those front-end changes require changes to the back-end, so the sense of completion on the back-end never lasts long. However, after some work, the back-end settles back down until the next round of front-end-inspired changes.
This difference implies that managing front-end development requires different skills than managing back-end development. UIs aren’t release, they escape. As a front-end project manager, you need the skill of learning when it’s okay to let the tiger off the leash. It won’t be tame because it will never be tamed. What of the remaining issues are truly blockers? What new issues should jump to the head of the queue? How do you mix larger, longer-term initiatives with tweaks?
Managing a back-end project is more a question of how to maximize throughput getting the to-do list down to zero, while providing the front-end opportunities for feedback. There’s more to back-end projects than this, but it’s a different skill set.
The picture is complicated because these to melodies, front-end & back-end, work together as counterpoint. Neither can deliver without the other.
Why?
Regular readers will notice that I’m never satisfied until I can explain why some phenomenon is occurring. That’s true here as well. What’s different about the context of front-end versus back-end development that results in such a different experience of developing?
A former student
speculated (& it makes sense to me):
One of the factors in the 4 Factors model of complexity that makes complex systems impossible to steer is Variation. When the parts of a system or the context of the system introduces variation, the system becomes harder to steer (multiply this by the system being in a multitude of possible states, the interdependencies between the parts of the system, & the irreversibility of changes & you get the whole model). Variation looks very different on the front-end & the back-end.
Changes to the front-end propagate to the back-end through the API.
Many parties introduce variation to the front-end (those are the moments when completing one item introduces 2, 3, 4 more). That variation is damped by the time it reaches the back-end. Many front-end changes require no back-end changes.
The back-end has its own sources of variation, but they tend to be smaller and more focused than the source of front-end variation.
Each completed front-end change spawns an unpredictable variety of further front-end changes, humans being infinitely unpredictable & subject to Heisenberg Requirements. The constraints on the back-end are both better known a priori & more mechanical, less human.
Consequences?
The above explanation is as far as I’ve gotten. My basic principles of combined front-end/back-end development remain:
Deliver value end-to-end in small slices.
Encourage full-stack collaboration (at least pairing across the divide).
Take a step back from time to time to reconsider the boundary between front-end & back-end responsibilities to reduce coupling across that boundary.
Don’t expect the front-end to ever be done. If urgent back-end work begins to balloon, dig deeper.
I love seeing the discussion of how front-end development mixes into the wider software design mix. Last year I posted about what frontend and backend even mean. There is little shared understanding leading to frequent misunderstanding https://www.industrialempathy.com/posts/frontend-backend/
In my post I call your usage of front-end uppercase-Frontend to disambiguate from lowercase-frontend which is just the part of any distributed system talking to its clients.
Some general topics that are interesting about frontend development:
- Skew boundaries involve more long-lived clients not under deployment control of the system author
- More-commonly stateless services making techniques like immutable deployments more feasible
- The general direction of the last 10 years in state-of-the-art frontend development has been to blur the client-server boundary and to eliminate separation of concerns: A move from MVC architecture to unidirectional dataflow (which now completely dominates web development). The implications of unidirectional dataflow for backend technologies remain underexplored.
Working on Screenshotbot, I have unique insights into this, and it's usually part of my pitch to potential customers. Unit tests fail relatively rarely (used as a proxy for how often the system behavior changes), UI changes very frequently (using screenshot tests as a proxy for frontend behavior changes).
For instance, most screenshot test changes we see on Screenshotbot are intentional changes. Very rarely are they actually "rejected" for being a bug. I could run the exact numbers.
(To complete the sales pitch I use, many companies use screenshot tests like unit tests, or what some people call acceptance tests. They store screenshots in the repo and the tests fail when screenshots change. But that introduces a lot of overhead for UI devs because UI changes so damn frequently, and UI devs have to keep re-recording screenshots manually. It's the wrong way to think about screenshot tests.)