this post was submitted on 19 Aug 2023
1 points (100.0% liked)

Experienced Devs

3961 readers
1 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

founded 1 year ago
MODERATORS
 

What is your opinion about full-stack teams? I'm referring to teams where the desire is for every member to competently contribute at every point in the stack.

  • Do they work?
  • What has been your experience?
  • Does team size and/or experience level inform your opinion?
  • Do you notice an increase/decrease in quality?
  • Do you notice an increase/decrease in team and product cohesion?
top 4 comments
sorted by: hot top controversial new old
[–] [email protected] 0 points 1 year ago (1 children)

It works, but not better than having each team member specialized in one subject. It just works, but it has it's own pros and cons:

my experienceIn my specific experience, when you talk about "full-stack" I don't only think about one "FE-BE-DB" project, but also another projects which are part of the company products (i.e. embedded products, testing infrastructure, cloud engineering...).

Pros:

  • For management, it reduces the "cost" of a team member quit, because the rest of the team can quickly and easily cover up his tasks.
  • For management, it's easy to assign a feature, they can peek anybody.
  • It makes developers to understand how the different parts of the projects communicate which each other, their impact and how they work.
  • Works better for startups where projects and teams are small and agile and usually the projects are MVP.

Cons:

  • Developers who specialize (or really like to specialize) in a specific subject, naturally won't last in this team more than 1-2 years (guaranteed).
  • Features quality and velocity, at the beginning, slightly drops, a bit more bugs occur. Overtime it will be better depends on the team members learning curve.
  • You won't have someone that masters a specific subject if you'll need one.
  • Doesn't work good on enterprise, where there are lots of huge projects, and the product is stable and full (not only MVP).
[–] [email protected] 0 points 1 year ago (1 children)

I think there's a benefit to having at least some "specialized" full stack devs. I happen to be one. I do mostly backend, which is technically my job, but occasionally I will pick up a front end ticket or one that incorporates back and front end.

Being able to see and understand how all the pieces fit together can be really helpful. If your entire team is made up of specialized devs, they tend to solve problems only with the tools they know. In my limited experience this frequently materializes as too much business logic in the UI or improperly implemented database integrations.

But I think the real value that full stack devs bring to these situations is not so much in the code that they can write but in the insight they can offer during the planning phases by helping the BA or whoever's writing the tickets, clarify who's responsible for what and how something should be implemented if it may not be clear to the dev working ticket.

[–] [email protected] 0 points 1 year ago
[–] [email protected] 0 points 1 year ago

So I've worked places where a user story is the only kind of story and one developer is responsible for every part of the stack for a given story. It didn't work as well as dividing responsibility between front end and back end specialists. I think full stack is a leadership role to figure out the API and integration, but I'm not sure that's even necessary given good communication.

Does it work? Sure.

My experience? I have rarely had a completely healthy team with good leadership and good developers. My experience has not been as good on full stack - it primarily creates different silos so you still don't have interchangeable developers. But I can't say with the right team firing on all cylinders wouldn't succeed.

Team size? Everywhere from 5 to about 20 with full stack being the case at the biggest and smallest. The biggest team was basically segregated by application so each app was siloed to a developer or small group. That was the absolute worst, though I guess the devs were largely happy because there was essentially no code review or supervision.

Quality and team cohesion were so variable I would hesitate to attribute that to full stack devs. Product cohesion was the absolute worst on the larger team of full stack because everyone solved every problem in a unique way and often differently between different apps due to better developer knowledge or different original developer and tech debt. But that was a poorly managed team altogether to be honest. It feels true but all I have is anecdotes.

So overall I'm not convinced it's a good idea, but I'm curious to see the other replies.