The Spectrum of Scale

Your company is six people working in the basement of the founder’s house. The “CTO” is also going to have to configure the server, write requirements, debug CSS, do UAT, make Costco runs for snacks and Red Bull, figure out the financials and make sales calls when she’s not envisioning the technical strategy for the start-up. That’s the nature of small, “all hands on deck” teams. The goal is to get that MVP proof of concept in front of investors. All the developers need to be jack-of-all-trades, git’er done types. Performance, efficiency, even quality are secondary concerns. Things are too lean for egos and not my job types.

But you know what they say about jacks-of-all-trades; they’re masters of none. Once you’re dealing with the complexity of enterprise applications the stakes change. Enterprises can have dozens, if not hundreds, of integrations, both SAAS and proprietary. These mission critical APIs are tied together by applications serving tens of thousands of users. Forgoing front end developers can lead to reduced performance, slower development velocity, regrettable architectural decisions and poor code quality. A good FED can be the difference between success and anxiety induced sleep deprivation.

And yet every single day I run into enterprise clients looking for “full stack” developers, the mythical unicorns of tech that are masters of all. But of the estimated 4 million developers in the USA, exactly 42 developers can legitimately claim to have mastered the “full stack”, whatever that means. The reality is most (all?) full stack developers are (hopefully) above average at one aspect and much less so at everything else. There is just too much to know, especially in the front end space where things are changing at a frightening pace. A developer who isn’t passionate about the domain can’t possibly hope to keep up. So that full stack developer, who I’m sure is smart and dedicated and hardworking, takes on a front end story and figures it out, sort of, with the help Stack Exchange and maybe a blog post. Not optimal.

In the 90’s

In the nineties, web applications were completely generated on the backend in application servers using technologies like Java Server Pages (JSPs) and Active Server Pages (ASPs). The UI was created with a patchwork of server oriented languages (like Java) interspersed with snippets of HTML & CSS. If there was any JavaScript, it might be there for simple interaction or validation. That was fine for the time. HTML, CSS and JavaScript were still pretty rudimentary and, before the appearance of tools like Babel to alleviate some of the pain of dealing with browser compatibility issues, it was a brave, patient soul who dared try anything too fancy. Being a full stack developer was easy because, well, there wasn’t front end developers. We didn’t need them. Everyone was full stack.

Then came AJAX, better JS tools and frameworks and an explosion of creativity inspired by the appearance of Gmail and especially Google Maps that kind of blew peoples’ minds when it was first released.

Modern Applications

Now modern applications are based on APIs, both proprietary and from SAAS providers, orchestrated by MV* framework-based front ends, often served as static files from a content distribution network (CDN). On the backend are micro services potentially serving multiple applications, delivered over multiple devices or even syndicated. The definition of the “application” is defined by the UI and the front end, combining the services needed to deliver the desired user experience. Well-designed enterprise applications will leverage design systems of reusable UI components, ideally implemented as a component library distributed through a repository like npm.

The front end is now the nexus of the application and the skills needed to implement a robust, performant apps are infinitely higher than they used to be back in the day. Profound, foundational JavaScript skills are essential prerequisites in addition to knowing any given framework or set of libraries. Add to that the pace of innovation and refinement happening with the tools in the front end space, it becomes untenable for someone without a singular focus on the front end to keep up. More often than not, a full stack developer is months (yup, things are moving so fast that we measure in months) if not years behind, checking in code that’s already a technical debt. For example, just look at the React roadmap.

That increased complexity does not necessarily mean increased timelines thanks to more sophisticated tools. Command line tools let a knowledgeable FED spin up the scaffolding for an application in a few minutes which is fantastic, assuming the develop knows what they’ve created.

That said, it pays huge dividends, especially when working with a UX/UI design team (and you absolutely should, but that’s another post), to take time to establish a design system and corresponding component library. Developing component libraries up front and enhancing them throughout makes pulling together screens and making global adjustments faster down the line. The unit tested reusable components also ensures quality and consistency in the user experience, making the application easier to understand and use.

From Experience

Historically, it has been our experience that a ratio of two or three back end developers to one front end developer maximizes velocity and minimizes roadblocks. Technologies like GraphQL seem to be shifting the ratio to the front end by giving the front end developers more and finer control of the APIs and data delivery.

The FED tools also make it easier to write unit and e2e tests and shorten the feedback loop to detect/fix/avoid bugs before the code even leaves the developer’s workstation. This shifting to the left of defect detection radically lowers the cost of fixing bugs.

To be clear, I’m not saying a full-stack developer can’t learn all this stuff. Of course, they can if they dedicated themselves to learning and keeping up with what is going on up front but then again, isn’t that the definition of a front end developer?

For Thought

Here are some questions to help you decide if your project could benefit from adding a front end specialist to your team:

• Is there a dedicated UX designer for the team? How does communication happen between UX and developers? How often?
• How well organized is the project structure and the code? Is the HTML clean and well-structured and semantic? Is the CSS a monolith with one main file or logically organized into modules? These can be really easy and often accurate indicators of a FE code base’s quality.
• How up-to-date is the tooling and dependencies? This goes beyond “using the newest version of React” into “is it using a lot of deprecated dependencies that could be security and/or performance risks?”
• How hard is it to get up and running with the project? When adding a new feature, is it fast and easy or does it take longer than it should? Who do you ask about the code architecture and structure? If the answer isn’t “anyone”, the code is probably too complicated.
• How is the frontend code built and the unit tests run? Look for a set of simple steps, like “npm install; npm build”. Is it efficient (e.g. does the dev-feedback loop require a 10 minute build)? Are there automated UI regression tests?
• Are front end/back end dependencies clearly fleshed out and surfaced before a sprint starts?
• What are the performance budgets for the site/application? Size of assets, speed, accessibility, responsivity?

Header image courtesy of Unsplash.