Currently there is a tendancy in our industry to specialise in front-end or back-end development and stick to it, it often comes down to interest or education. On top of this companies now tend to create two disctinct teams to take care of their applications and websites.
This split was effective or put into place in the last companies I've worked at and I wanted to give my two cents on this trend. The split is not obvious and should not be done lightly.
Why would we want to ?
This trend follows the logic that has been the default go-to architecture for websites and applications in the latest years. We build a stand-alone front-end that communicates with an API. No only does this give the possibility to release those two components independantly but it also gives the opportunity to develop other applications on top of the API without having to put in the effort of building a new back-end system to communicate with.
And since we have two different code base, two different deploy pipeline and two different applications it looks like the two team split makes sense.
The benefits
As mentionned, the fact that, in the end, the front and back end side of the application become two independant part of the same product means that there is no need to have the same team tackle these two development.
One of the major benefit is the fact that you can hire experts in their fields, language or framework. It brings efficiency in their team as well as the insurance that the project can move forward avoiding some of the hurdles those project usually encounter.
Communication also benefits from this. The team focuses on the same codebase, talk the same language and have a wider knowledge of the codebase since they're always working on the same one.
A smaller team also means that voices are heard more easily and the ideas flow faster. It helps with productivity and reactivity on new features or bugfixes.
A smaller and often underappreciated benefit is the added quality to documentation. Since the front-end team and the back-end team need to easily communicate, usually a standard way to communicate how things work is put into place.
But we can easily see how this could be a problem in certain situations.
The drawbacks
The communication within the teams benefit from this split, but what about the communication between the two teams. And what about the communication between each team and other actor of the company.
When building a project from scratch, or even developing new features, the communication between both teams and the product team must be crystal clear. And if it is not, it can lead to conflicts in what each team has understood about what needs to be developed.
If the teams are in a configuration where they both have a manager and those manager don't communicate a lot and prefer going through their common superior, the slowness of the loop might create a divergence in the objectives of the teams and lead to changes or even large rewrite of the applications.
In my experience this has lead to one of my biggest fear when this split is done, the front-end and back-end team are tired on waiting on each other and develop the parts of the application that both of them judge as the most critical and when the time comes to put things together, a huge refactor is necessary to be able to present the tiniest thing.
So... Should we do it?
I am not pretending to have the perfect answer to this but I think that this decision should not be taken lightly.
From experience, I've been able to see it work extremely well and very poorly.
It worked when the split was done at a point in the company where they wanted to grow and build something new on the front-end without having to pull resources from the back-end.
It worked because the API was already designed, functional and documented. The front-end team was able to design their new application without having to wait on the API to be functional, and when it came to adding feature, the team knew how the API was designed and could ask for endpoints that were aligned with how the API worked.
On the other hand it has gone very poorly on a full rewrite of an application. Both teams started working on their architecture for a while, this time was used by the product team to define the scope of the new application.
The issue came when both teams did not finish their research at the same time. Some hurdles were encountered by one of the team and since the management wanted to keep a hard delimitation between the front-end and the back-end, resources were not moved around to help. And since the situation did not resolve, the product team was moved to other tasks and the time to answer grew longer.
This stalling resulted in the project collapsing onto itself when this rewrite was necessary to help the company grow into new segments. Instead the failure pushed to drop the project and keep developping on the old stack.
TL;DR: When doing a split, consult with the team members, make sure you have a strong plan and don't be too strict with it. The benefit of being able to hire more efficiently can be outweighted by the difficulty of communicate.
Top comments (0)