7 ms·

I've never been convinced about splitting developers into front and back end. I see no reason why a decent developer can't build the front and the back end for

I've never been convinced about splitting developers into front and back end. I see no reason why a decent developer can't build the front and the back end for each piece of new functionality. This removes all the communication issues.

radicalbyte 11y ago
First: it's all about reducing latency. Split the work, implement in parallel then you'll ship in "half" the time. Second: Good developers are hard to find. Backend requires both good CS background (algorithms, security) as well as development skills. Frontend requires some feeling for design and can tolerate poor development skills.
- gkoberger 11y ago
  First: Read the Mythical Man Month Second: Don't insult front-end developers. I do both back and front, and I find front-end to require much more skill. Nobody notices if a backend feels slightly off, but it's very obvious when an interaction was built by someone who isn't a great front-end programmer. Both sides are necessary and difficult in their own way; they just require different skillsets.
  - StavrosK 11y ago
    > Nobody notices if a backend feels slightly off Oh you'll notice it in three months, when you have to write that new feature.
    - gkoberger 11y ago
      I was talking about end users, although having to rewrite bad code is true for both front- and back-end.
  - madeofpalk 11y ago
    > First: Read the Mythical Man Month Actually, that refers to adding more resources to _an already late project_. It explicitly mentions that starting out with more resources can speed up development. In saying that, 9 women can't make a baby in one month.
  - radicalbyte 11y ago
    > First: Read the Mythical Man Month I have, it's a brilliant book. Helped me greatly during my career. However it's about scaling an already broken (and late) project in a very naive way. Luckily we've learnt a lot since then - and it turns out that decomposing the problem into 4-6 person chucks and optimizing for minimum dependencies is a good strategy to close-to-linear scalability :)
    - dllthomas 11y ago
      "However it's about scaling an already broken (and late) project in a very naive way." If that's all you remember of it, you really need to reread it (and I find myself mildly skeptical that you did in the first place - although it could very well be that it's been long enough you thought those ideas were elsewhere). The title - and Brooks' Law - is about that, but the book covers a whole lot more. Including discussions of approaches to decomposing problems into <10 person chunks and optimizing for minimum dependencies.
- eyko 11y ago
  > Frontend requires some feeling for design and can tolerate poor development skills. It seems you're assuming front end developers are usually designers with some coding skills, or developers with some design skills, and neither is the case. A fairly complex app will most definitely have designers and developers in their front end team. I think the main reason for the separation is domain knowledge. You may have a lot of experience designing real time APIs, but no experience with web technologies. I've worked with a lot of good developers that still don't get HTTP status codes or the basic principles of REST APIs, but they're good developers nevertheless. And perhaps that's why the role of the full stack developer has become now more popular.
  - radicalbyte 11y ago
    We're talking about web developers, so what I'm saying is broadly true. Native development - and cutting edge web-based development - is a different beast. You start needing knowledge of threading, messaging, various architectural patterns etc. I'm actually recruiting for such a developer now - someone who wants to be top specialized front-end developer. They're just extremely hard to find (if you're interested in working on a complex SPA and are in, or want to move to NL, drop me a line! You don't need to speak dutch!). You're right about domain knowledge: there is just too much that you need to know to be able to be an effective "full stack" developer for anything approaching a complex system.
hoka 11y ago
one possible issue is that the site will be like a chimera, as everyone has slightly different styles of doing UI work and interaction code.
aiiane 11y ago
The same reason why often the servers themselves are structured to have separate frontends and backends - because they encompass different problem spaces, and specialization provides efficiency.
- erikpukinskis 11y ago
  "Specialization provides efficiency" is definitely not a general purpose truth. Specialization can just as easily cause inefficiency.
  - rimantas 11y ago
    Specialization provides loads of communication (or lack of it) between those specialist. Alas, every time the team I was on was doing some soul-searching it came up that the main problem was communication. Don't underestimate the effect of communication overhead and the cost of miscommunication.
benjaminwootton 11y ago
Maybe on a small line of business app. On a big, widely used consumer facing app however, front end developers really come into their own. They have cross browser, cross device responsive design issues to contend with. Accessibility and graceful degredation. Performant JavaScript. They also need design skills. Very few people have deep skills in back end and front end.
- crdoconnor 11y ago
  I've seen plenty of projects with separate front end and back end developers fuck up because the front end developers try to solve "back end problems" on the front end and vice versa. This is the cause of an awful lot of technical debt, and "big, widely used consumer facing app" is the natural habitat of large technical debts.
  - madeofpalk 11y ago
    I've seen projects where a 'back end dev' has written CSS or other FE stuff and done a terrible job of it - just bad code. CSS and the DOM has it's own set of quirks and bits of required knowledge that good FE devs will all know quite well.
  - biokoda 11y ago
    No matter how you do it you can shoot yourself in the foot.
  - arethuza 11y ago
    I vividly remember a case where a really simple page in a system had become incredibly slow - on asking what had changed I was told "all we did was add a count of the number of users". Turns out the back end (they were micro-services - even though the term hadn't been invented at that point) didn't have a call for "total number of users" so the front end code (this was server side HTML generation - 10+ years ago) was getting a list of every user in the system and iterating over all of them in chunks and counting.
    - 11y ago
tragic 11y ago
It depends what you mean by front end, really. If you're working on a single page app type thing, I see no reason why the engineering shouldn't be done by the same people. Design, however, is a different matter. It's a whole other specialism, and while I'm sure there are people who are competent at both, my anecdatabase doesn't have many on file.
onion2k 11y ago
I've never been convinced about splitting developers into front and back end. There isn't any 'one true way' to do it. If a project is best built with a front end team and a back end team, then that's the best way to do it. If a project is best built with a team that does everything, that's the best way for that project. Mind you, I would add that "This removes all the communication issues." is completely wrong. Having one person write the code for both sides compounds the communication issues, because it means no one other than that developer knows anything about the system. If communication is a problem then resolve that problem as soon as possible by writing good API documentation and sharing knowledge among the team, because if you don't you'll end up with an unmaintainable mess of code that's eventually sunk by the weight of technical debt.
rifung 11y ago
It's possible a developer COULD do both, if they had the experience/training to do both. On the other hand it seems like there are many people who not only know how to do one or the other but actually only want to do one or the other. Of course there are other people who want to do both, in which case I think they usually apply to "full stacK" positions.
mdpopescu 11y ago
I'm a very good back-end developer. I hate front-end fiddly bits. I can do it, I just hate it. (If you live for seven levels of LESS code, more power to you.)
- vellum 11y ago
  > I hate front-end fiddly bits. Yes. A lot of back-end devs would rather chew glass than debug for four browsers, plus mobile devices.
  - crdoconnor 11y ago
    It is usually more susceptible to bugs than the back end. The combination of a lack of control over the environment your code runs in and javascript's weak typing give it that extra dose of fun.
    - sangnoir 11y ago
      In the same vein as your comment, I might as well say back end development sucks because the default MySQL datastore quietly drops strings longer than the field[1]. These days front-end =/= Javascript[2] by a long shot (maybe yours is, but blame the person who made that decision for your project). 1. I don't know if that's still true. If it is, then I'm glad I no longer have to deal with MySQL. 2. GWT had strong-typing since forever. Not that I'm endorsing it, but it's still front end. I do recommend TypeScript
      - DCoder 11y ago
        > the default MySQL datastore quietly drops strings longer than the field [...] I don't know if that's still true. If it is, then I'm glad I no longer have to deal with MySQL. That's still true, as I recall. To avoid this nonsense, you need to change the sql_mode - either globally in the server config, or only within your session by issuing an SQL query. Documentation: https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_traditional https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmod...
colund 11y ago
Martin Fowler discusses this in https://news.ycombinator.com/item?id=10197977 https://news.ycombinator.com/item?id=10197977
jdbernard 11y ago
I agree, but as hard as it is to find decent developers in general, it is even harder to find decent developers who have enough experience in both sides to be able to work in both environments effectively. Too often you have "full-stack" devs who are really just back-end guys writing JavaScript like Java, or vice-versa.
kzhahou 11y ago
For e certain class of problem, yes. But as complexity and ambition increases in the UI and backend logic, the necessary skillsets will quickly diverge.
ken47 11y ago
The theory has its roots here: https://en.wikipedia.org/wiki/Production_line https://en.wikipedia.org/wiki/Production_line https://en.wikipedia.org/wiki/Division_of_labour https://en.wikipedia.org/wiki/Division_of_labour Whether backend vs frontend is the right "seam" for division of labor depends entirely on the complexity of the systems at play, as opposed to some arbitrary generalization of all backends and frontends as you seem to be making here.

radicalbyte 11y ago

First: it's all about reducing latency. Split the work, implement in parallel then you'll ship in "half" the time. Second: Good developers are hard to find. Backend requires both good CS background (algorithms, security) as well as development skills. Frontend requires some feeling for design and can tolerate poor development skills.

gkoberger 11y ago
First: Read the Mythical Man Month Second: Don't insult front-end developers. I do both back and front, and I find front-end to require much more skill. Nobody notices if a backend feels slightly off, but it's very obvious when an interaction was built by someone who isn't a great front-end programmer. Both sides are necessary and difficult in their own way; they just require different skillsets.
- StavrosK 11y ago
  > Nobody notices if a backend feels slightly off Oh you'll notice it in three months, when you have to write that new feature.
  - gkoberger 11y ago
    I was talking about end users, although having to rewrite bad code is true for both front- and back-end.
- madeofpalk 11y ago
  > First: Read the Mythical Man Month Actually, that refers to adding more resources to _an already late project_. It explicitly mentions that starting out with more resources can speed up development. In saying that, 9 women can't make a baby in one month.
- radicalbyte 11y ago
  > First: Read the Mythical Man Month I have, it's a brilliant book. Helped me greatly during my career. However it's about scaling an already broken (and late) project in a very naive way. Luckily we've learnt a lot since then - and it turns out that decomposing the problem into 4-6 person chucks and optimizing for minimum dependencies is a good strategy to close-to-linear scalability :)
  - dllthomas 11y ago
    "However it's about scaling an already broken (and late) project in a very naive way." If that's all you remember of it, you really need to reread it (and I find myself mildly skeptical that you did in the first place - although it could very well be that it's been long enough you thought those ideas were elsewhere). The title - and Brooks' Law - is about that, but the book covers a whole lot more. Including discussions of approaches to decomposing problems into <10 person chunks and optimizing for minimum dependencies.
eyko 11y ago
> Frontend requires some feeling for design and can tolerate poor development skills. It seems you're assuming front end developers are usually designers with some coding skills, or developers with some design skills, and neither is the case. A fairly complex app will most definitely have designers and developers in their front end team. I think the main reason for the separation is domain knowledge. You may have a lot of experience designing real time APIs, but no experience with web technologies. I've worked with a lot of good developers that still don't get HTTP status codes or the basic principles of REST APIs, but they're good developers nevertheless. And perhaps that's why the role of the full stack developer has become now more popular.
- radicalbyte 11y ago
  We're talking about web developers, so what I'm saying is broadly true. Native development - and cutting edge web-based development - is a different beast. You start needing knowledge of threading, messaging, various architectural patterns etc. I'm actually recruiting for such a developer now - someone who wants to be top specialized front-end developer. They're just extremely hard to find (if you're interested in working on a complex SPA and are in, or want to move to NL, drop me a line! You don't need to speak dutch!). You're right about domain knowledge: there is just too much that you need to know to be able to be an effective "full stack" developer for anything approaching a complex system.

hoka 11y ago

one possible issue is that the site will be like a chimera, as everyone has slightly different styles of doing UI work and interaction code.

aiiane 11y ago

The same reason why often the servers themselves are structured to have separate frontends and backends - because they encompass different problem spaces, and specialization provides efficiency.

erikpukinskis 11y ago
"Specialization provides efficiency" is definitely not a general purpose truth. Specialization can just as easily cause inefficiency.
- rimantas 11y ago
  Specialization provides loads of communication (or lack of it) between those specialist. Alas, every time the team I was on was doing some soul-searching it came up that the main problem was communication. Don't underestimate the effect of communication overhead and the cost of miscommunication.

benjaminwootton 11y ago

Maybe on a small line of business app. On a big, widely used consumer facing app however, front end developers really come into their own. They have cross browser, cross device responsive design issues to contend with. Accessibility and graceful degredation. Performant JavaScript. They also need design skills. Very few people have deep skills in back end and front end.

crdoconnor 11y ago
I've seen plenty of projects with separate front end and back end developers fuck up because the front end developers try to solve "back end problems" on the front end and vice versa. This is the cause of an awful lot of technical debt, and "big, widely used consumer facing app" is the natural habitat of large technical debts.
- madeofpalk 11y ago
  I've seen projects where a 'back end dev' has written CSS or other FE stuff and done a terrible job of it - just bad code. CSS and the DOM has it's own set of quirks and bits of required knowledge that good FE devs will all know quite well.
- biokoda 11y ago
  No matter how you do it you can shoot yourself in the foot.
- arethuza 11y ago
  I vividly remember a case where a really simple page in a system had become incredibly slow - on asking what had changed I was told "all we did was add a count of the number of users". Turns out the back end (they were micro-services - even though the term hadn't been invented at that point) didn't have a call for "total number of users" so the front end code (this was server side HTML generation - 10+ years ago) was getting a list of every user in the system and iterating over all of them in chunks and counting.
  - 11y ago

tragic 11y ago

It depends what you mean by front end, really. If you're working on a single page app type thing, I see no reason why the engineering shouldn't be done by the same people. Design, however, is a different matter. It's a whole other specialism, and while I'm sure there are people who are competent at both, my anecdatabase doesn't have many on file.

onion2k 11y ago

I've never been convinced about splitting developers into front and back end. There isn't any 'one true way' to do it. If a project is best built with a front end team and a back end team, then that's the best way to do it. If a project is best built with a team that does everything, that's the best way for that project. Mind you, I would add that "This removes all the communication issues." is completely wrong. Having one person write the code for both sides compounds the communication issues, because it means no one other than that developer knows anything about the system. If communication is a problem then resolve that problem as soon as possible by writing good API documentation and sharing knowledge among the team, because if you don't you'll end up with an unmaintainable mess of code that's eventually sunk by the weight of technical debt.

rifung 11y ago

It's possible a developer COULD do both, if they had the experience/training to do both. On the other hand it seems like there are many people who not only know how to do one or the other but actually only want to do one or the other. Of course there are other people who want to do both, in which case I think they usually apply to "full stacK" positions.

mdpopescu 11y ago

I'm a very good back-end developer. I hate front-end fiddly bits. I can do it, I just hate it. (If you live for seven levels of LESS code, more power to you.)

vellum 11y ago
> I hate front-end fiddly bits. Yes. A lot of back-end devs would rather chew glass than debug for four browsers, plus mobile devices.
- crdoconnor 11y ago
  It is usually more susceptible to bugs than the back end. The combination of a lack of control over the environment your code runs in and javascript's weak typing give it that extra dose of fun.
  - sangnoir 11y ago
    In the same vein as your comment, I might as well say back end development sucks because the default MySQL datastore quietly drops strings longer than the field[1]. These days front-end =/= Javascript[2] by a long shot (maybe yours is, but blame the person who made that decision for your project). 1. I don't know if that's still true. If it is, then I'm glad I no longer have to deal with MySQL. 2. GWT had strong-typing since forever. Not that I'm endorsing it, but it's still front end. I do recommend TypeScript
    - DCoder 11y ago
      > the default MySQL datastore quietly drops strings longer than the field [...] I don't know if that's still true. If it is, then I'm glad I no longer have to deal with MySQL. That's still true, as I recall. To avoid this nonsense, you need to change the sql_mode - either globally in the server config, or only within your session by issuing an SQL query. Documentation: https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmode_traditional https://dev.mysql.com/doc/refman/5.6/en/sql-mode.html#sqlmod...

colund 11y ago

Martin Fowler discusses this in https://news.ycombinator.com/item?id=10197977 https://news.ycombinator.com/item?id=10197977

jdbernard 11y ago

I agree, but as hard as it is to find decent developers in general, it is even harder to find decent developers who have enough experience in both sides to be able to work in both environments effectively. Too often you have "full-stack" devs who are really just back-end guys writing JavaScript like Java, or vice-versa.

kzhahou 11y ago

For e certain class of problem, yes. But as complexity and ambition increases in the UI and backend logic, the necessary skillsets will quickly diverge.

ken47 11y ago

The theory has its roots here: https://en.wikipedia.org/wiki/Production_line https://en.wikipedia.org/wiki/Production_line https://en.wikipedia.org/wiki/Division_of_labour https://en.wikipedia.org/wiki/Division_of_labour Whether backend vs frontend is the right "seam" for division of labor depends entirely on the complexity of the systems at play, as opposed to some arbitrary generalization of all backends and frontends as you seem to be making here.