3 ms·

I've found the distinction kind of odd. As a so-called "full stack" developer, every project I've worked on in which the frontend and backend developers were c

I've found the distinction kind of odd. As a so-called "full stack" developer, every project I've worked on in which the frontend and backend developers were clearly delineated has led to a mismatch in needs between the two. The frontend devs asking for the API they need for the UI they want to achieve, and the backend devs having to predict the ways the frontend will need this data for now and in the future as the UI evolves and as the backend system is built out. The frontend devs are at the mercy of potential backend choices affecting the "feel" of the UI over time, and the backend devs at the mercy of their data model, infrastructure, and system design choices not meshing with the future needs of the frontend over time. I know the projects this sort of thing has gone bad for me on had other communication issues, but I still don't know if I could deliver a solid end product nearly as effectively without being able to jump into either end, understand the problems and desired outcomes, and be able to help both evolve in a maintainable and scalable way, together.

ozim 5y ago
I share the same experience. I would even go further and say that when you have clearly set boundaries between teams in functional terms it goes bad. Like "backend/frontend", "dev/qa", "dev/ops" ,"engineering/business". For me the most effective thing that I see are cross-functional product teams that have their own goal to ship things and all roles within that team. Unfortunately not all software can be built that way and there is a lot of productivity loss, because you might not have enough work for some roles. Like ops engineer you will need at the beginning to setup infra and then he might be helping out here and there, but it is not going to be full time job on one project. Then QA might have "quiet days" because devs will have to work on things for couple days before delivering something. I understand huge enterprise companies that they want to have "QA" "Dev" "Ops" just as a pool of reusable people, because they have to hire them full time and keep occupied. What I see in the wild is that there are some long running projects that evolve all the time and those can be such teams as described earlier. There are ad-hoc projects that might pan out or not, maybe it would be better to hire freelancers, see if project turns into long runner and if yes, hire a proper team to work on it. All of that requires unfortunately a lot of knowledge and work and a lot of political power inside of a company...

ozim 5y ago

I share the same experience. I would even go further and say that when you have clearly set boundaries between teams in functional terms it goes bad. Like "backend/frontend", "dev/qa", "dev/ops" ,"engineering/business". For me the most effective thing that I see are cross-functional product teams that have their own goal to ship things and all roles within that team. Unfortunately not all software can be built that way and there is a lot of productivity loss, because you might not have enough work for some roles. Like ops engineer you will need at the beginning to setup infra and then he might be helping out here and there, but it is not going to be full time job on one project. Then QA might have "quiet days" because devs will have to work on things for couple days before delivering something. I understand huge enterprise companies that they want to have "QA" "Dev" "Ops" just as a pool of reusable people, because they have to hire them full time and keep occupied. What I see in the wild is that there are some long running projects that evolve all the time and those can be such teams as described earlier. There are ad-hoc projects that might pan out or not, maybe it would be better to hire freelancers, see if project turns into long runner and if yes, hire a proper team to work on it. All of that requires unfortunately a lot of knowledge and work and a lot of political power inside of a company...