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

Vladimir Bychkovsky

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.