Is it common to separate back-end and front-end into two positions on web development projects?

Question

At a web startup, is it more common to have an engineer working the front-end AND back-end of the feature (basically in charge of the whole feature)? Or have engineers separated between the back-end and front-end?

Which ones are more beneficial and for what situations?

The downside, I've noticed, regarding having one engineer in charge of the whole feature is that the person might only be particularly strong in either frontend or backend development but not both, thus sometimes having a decrease in speed and quality.

Having frontend and backend developers on one feature increase the speed of the feature and the quality AND it encourages collaboration. But I am concerned about having 2 engineers working on one feature which may be a poor use of resources since the 1 engineer can be placed on another feature to work on.

What is the common/best practice for allocation backend/frontend engineering resources at a small early-stage startup? And then how will it change as it grows?

Answer 1

Here is my wisdom from 14 years experience:

• if you have a startup, don't assign roles. Better hope that you assembled a good self organizing team. If everybody knows each other, everybody knows who does what the best. A project manager will only stand in the way.
• later on, the distinction between front-end and back-end makes sense. In the backend, quality is prio one. Code has to be performant, secure and transaction safe. In the front-end, implementation time matters. And you must be able to rely on a good back-end. The different goals of front- and back-end don't work good together.
• the back-end should already exist before the front-end coder starts to work. Otherwise, the front-end coder will be slowed down too much.
• backend has to be able react fast on front-end requirements in order not to slow them down

Answer 2

The best answer is from @Shark, but only the last part "It depends." In my experience, ~16 years or so, I've seen both options attempted in a variety of different configurations. Being a full stack developer myself, here's what I've come to learn:

*(BE = Back End, FE = Front End)

General Caveats Of Split Stack Development:

1. Agile development practices (a common strategy these days) recommends feature development, where the feature is a single valuable chuck of functionality from the customer's perspective. From this perspective you should have your developer implement both.

2. Splitting the stack along the server boundary creates an integration point between the two developers. Unless they communicate effectively and work well together this will cause a fair number of bugs when the two features come together.

3. Apply the n(n-1)/2 rule of communication from the Mythical Man-Month and you will see that splitting features in two parts between two people will increase your overall workload. Granted that rule applies to features as well, but spliting the stack doubles the amount of communication.

4. A designer will solve the problems of BE developers not being able to produce attractive interfaces from scratch. This assumes they at least know html & css and can produce an interface that matches the screenshots created by the designer.

5. Features are typically isolated components that interact very little with other features. This is not always the case but usually the point of interaction is at a low level like a database or filesystem. So there isn't much preventing a full-stack developer from implementing their feature. But if an FE developer has to wait on a BE developer to finish a task, it will add even more delay on top of the productivity loss in point 3.

6. Web2.0 blurs the distinction between FE & BE even further. With MVC frameworks, and entire applications being built on the client-side, a good deal of BE knowledge is now required to implement secure and efficient FE applications.

7. My biggest gripe towards this practice is that it limits the abilities of everyone involved on the project. Although this was a common practice in the early 2000's it was done out of necessity because finding developers that could do both was pretty difficult (purely because of new-ness not because of some intrinsic difficulty in learning both.) What remains of the practice is a decade later we still have "web developers" that don't know CSS.

8. My second biggest gripe is that it can easily segment a development team. A FE developer creates a bug after modifying BE code and the team votes to restrict cross-stack development wholesale. Whereas code reviews and education could solve the problem, people become territorial instead.

Benefits/Use-Cases of Split Stack Development:

1. RESTful API's are perfect for this delineation because there is no FE. Often a company will work on a RESTful API first, and then develop their web applications on top. In this case there is a strong case for keeping the BE team focused on the next major version while the FE is finishing the application. But the danger of churn still exists - especially if new information discovered in the FE dev phase requires non-trivial modifications to the BE API.

2. Unbalanced workloads between FE & BE are also a good case for creating a FE only team. Again this is very situational where perhaps the main development is done via a desktop application and the company is trying to develop a 'lite' web interface.

3. Training new/junior developers. If you are hiring an intern or a junior dev and are concerned about throwing them into the deepend, it's a good option to invest some of that communication/integration cost into a peer development system.

Concerns about @Ralf's accepted answer on this page:

1. The first point is pretty bold - and it will fail quickly if you don't have one of those "good self-organizing teams". Even if you have that team, it's in your and their interests to push their boundaries. And good self-organizing teams are not always self-motivated to do that.

2. Your second point is just wrong. Modern web development requires FE code that is performant, secure, asynchronous safe, XSS-proof, cross-browser, and developed quickly. The goals simply do not compete with BE they are effectively equal.

3. The third point is also a bad assumption - FE development can begin with pure html/css/js without any BE foundation work. From there it's only a trivial effort to break it down into templates for BE rendering. Often times it's best to start with FE work because it will give stakeholders a warm & fuzzy feeling to see visual progress up front.

Conclusion:

If you are a startup and you don't happen to have a lot of time or money to burn, then don't hire FE or BE only developers. Hire senior level web developers and a good ux/designer, and they will get your application off the ground as quickly as possible. They cost more, but they are far more productive and you'll need fewer of them.

Answer 3

I think the question is wrong.

All startups I took part in did not have a FE-BE only architecture.

Most startups I know have:

• Core - the actual product that exposes an interface
• UI - BE and FE. The BE uses the Core's API.

APIs are stateless and easily mocked - even without the need of a Core Developer. Hell, if I had to start a project from scratch I might start with an entire UI that works purely on mocks - which will be great for presentations. Most of the feedback is due to UI. Customers note that more - ( depends on your target audience. )

For example - Google Search has the Core component which crawls the web, indexes it etc.. and the Google UI is a totally different world. This core can easily support non WWW searches, while the UI cannot.

This way your UI is "pluggable" and you have separation of concerns.

You referred to Development knowledge, however you're overlooking project management aspects. While the core team might need 2 weeks sprint duration, the UI team will use CI - everything is uploaded all the time. The Core team will need backward compatibility while UI will not.

Language differs. You will probably want C developers for the Core component - and you will be ok if it runs on a single OS, where as the UI will be written in a Cross OS Language.

Tests differ. The UI test world is one of the most complex I know in software development. Most startups neglect it and regret this decision later on. You cannot separate BE and FE when testing. It has to be a single unit that handles it.

Open Source UI - one of the greatest benefits of separating the two is that you can open source your UI. UI project need open source support.

I cannot imagine a UI developer that cannot understand the entire session feature. You know - where you login and stay logged in between different requests. True they might know PHP and not Java.. but the BE concept should be clear (e.g. use an encrypted cookie). The specific language barrier is wrong - every developer should be willing to work in any language. Who would've thought they would write BE in JavaScript a couple of years ago?

If you go on having 3 teams : Core, BE and FE, it is a waste of resources imho. What about DB? should you have DBAs? Why should a BE developer know DB and a FE developer not know BE and DB? There's no limit.

If you require experts, and you will, outsourcing them works pretty well. They usually deliver quality code and they do it quite fast. You do not necessarily want them in-house because you will get lost if they leave. Besides you can get great advice online today. Cutting edge stuff might require different approach.

So the outcome is basically a very thin BE in the UI that every FE developer can develop. If you have a thick BE in the UI you most probably have some API functionality required in the Core.

There's always at least one developer that stands out of the rest. Given such a thin FE, he/she can manage giving support (not develop) other developers in BE code. My opinion is that this developer is in a very good position and should be awarded appropriately (not in salary though, something else). I also trust that they will be able to handle build process and build properly.

This model gives you a great flexibility regarding BE development. The BE world have known several turnarounds in the last couple of years, so I don't recommend relying on BE stability too much anyway. Core is a different story.

There still remains the question - should FE and BE be the same project? You should note the following

• Static resources are best served from front-server. Since Front-End servers (e.g. nginx) are very powerful and since you can use Cache for static resources, you can manage with a single deployment of your static resources (which should be all HTML content, JS, CSS, Images).
• Backend code does not have the same luxuries, so you must have a distributed system - which is also managed by a front-server.
• FE code is highly to be reused with all the new technologies that support JavaScript. You can now write Desktop and Mobile applications with JavaScript.
• The build process is completely different - and that can even include patches delivery, upgrade, installation etc..

I can go on, but I hope it is clear that I think BE and FE should be the same team, but maybe different projects.

Answer 4

I think the successful implementation could be a few things. If there is a sole developer that has a strong backend but also has a decent grasp on the user interface and all "front-end" pieces, then it could probably be successful. That's not typically the case, though (in my personal experience). For instance, I consider myself a back-end developer. But I work on a lot of projects by myself. Do I work on the presentation and the client-side pieces? Sure. Do they look as good as an actual talented designer and client-side developer would make? Absolutely not.

It's all give and take. But don't let the collaberation of two developers make you hesitate. There are tried and true ways to maximize production between a developer and a designer.

In other words...It depends