3 ms·

I think it's not really a ideal thing for client-side work and server side work to be separated (this is more a talent constraint). The most efficient organizat

I think it's not really a ideal thing for client-side work and server side work to be separated (this is more a talent constraint). The most efficient organizations I have worked for are the ones that split themselves up into feature teams instead of strict front-end and backend teams. Otherwise, you end up with people waiting around for each other to make changes and that forces them to context-switch between different tasks (and everyone loses focus). Not to mention that the backend devs often dont get the interface 100% perfect the first time and you end up having to iterate over those changes - Which means more waiting around and more context switching (except if the required changes are minor in which case they can pair together). With feature teams, you give people ownership over a feature of the software and they are responsible for bringing it to completion. The great advantage of fullstack developers is that a single developer can work on a feature end-to-end - It gets rid of communication problems, greatly speeds up development and reduces the backend-frontend "blame game" factor that you often see in large companies. I like the way the article portrays people as concurrent processes but I think there is a fundamental difference between people and processes which affects things: People don't have perfect memory. When someone offloads a task to a different person and starts working on some new tasks asynchronously, when they come back to the previous task, they may not be able to resurrect all the old thoughts that they had the last time they looked at the same code (not the same level of depth). So they lose a bit of time getting back in the mindset.

justinhj 11y ago
Some backends are fairly sophisticated and require extensive domain knowledge from designing databases that can be scaled, caching systems, security issues and so on. On the client side you may need someone who is an expert in C#, in 3d rendering and geometry and in audio. Finding someone great at both is going to be very hard, and frankly not worth the benefits unless you have a very small team. That said I believe front and backend should work closely together. There is no reason that the frontend should be blocked because the API design can be figured out before the backend is written and the frontend can mock out the missing features until they are available.
- bitsai 11y ago
  "That said I believe front and backend should work closely together. There is no reason that the frontend should be blocked because the API design can be figured out before the backend is written and the frontend can mock out the missing features until they are available." Came here to say exactly this. At my current workplace, one of the very first steps in any project that involves both FE and BE work is for FE and BE engineers to get together and design the API. Once that's done, work can proceed on both sides in a largely asynchronous and independent manner. And one of the first things to be implemented on the BE is API endpoints with multiple mocks that can be requested by the FE, so the FE can start integrating with the endpoints as early as possible.
- matthewmacleod 11y ago
  I don't think you need to find people who are great at both, but you may want to find teams that are great at both. The impression I took from the comment you replied to is that there should be no front-end and back-end team, but instead 'cross stack' feature-oriented teams, including members who have knowledge of all parts of the stack and can work on all parts of a feature together.

justinhj 11y ago

Some backends are fairly sophisticated and require extensive domain knowledge from designing databases that can be scaled, caching systems, security issues and so on. On the client side you may need someone who is an expert in C#, in 3d rendering and geometry and in audio. Finding someone great at both is going to be very hard, and frankly not worth the benefits unless you have a very small team. That said I believe front and backend should work closely together. There is no reason that the frontend should be blocked because the API design can be figured out before the backend is written and the frontend can mock out the missing features until they are available.

bitsai 11y ago
"That said I believe front and backend should work closely together. There is no reason that the frontend should be blocked because the API design can be figured out before the backend is written and the frontend can mock out the missing features until they are available." Came here to say exactly this. At my current workplace, one of the very first steps in any project that involves both FE and BE work is for FE and BE engineers to get together and design the API. Once that's done, work can proceed on both sides in a largely asynchronous and independent manner. And one of the first things to be implemented on the BE is API endpoints with multiple mocks that can be requested by the FE, so the FE can start integrating with the endpoints as early as possible.
matthewmacleod 11y ago
I don't think you need to find people who are great at both, but you may want to find teams that are great at both. The impression I took from the comment you replied to is that there should be no front-end and back-end team, but instead 'cross stack' feature-oriented teams, including members who have knowledge of all parts of the stack and can work on all parts of a feature together.