4 ms·

A team of full stack devs tend towards whatever they fancy when handing out JIRAs, and the separation is still usually front or back-end. It becomes an unoffici

A team of full stack devs tend towards whatever they fancy when handing out JIRAs, and the separation is still usually front or back-end. It becomes an unofficial silo anyway. The full stack advantage is for sudden departures: the project doesn't completely stop because people can fill in with mediocre code. A disadvantage is that you don't have specialists and risk more technical debt that can't be enforced by linters/testing. The reason this debate will never end is because it's never anchored to how the business sells and delivers products. Full stack is better for shorter product life cycles. Specialists are better for longer-running products and monoliths. Code quality really doesn't matter if the product disappears. The key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?"

BjoernKW 8y ago
The early days of web development up to roughly the end of the 1990s technically were full stack. It's just nobody called it that at the time. It's only by the early 2000s and the advent of architecturally complex, heavily back-end-leaning frameworks such as J2EE or JSP that front-end and back-end diverged. These frameworks had their benefit compared with the fast-and-loose way web apps often were developed before but they also introduced new problems. Apart from inherent architectural issues these frameworks introduced a new crop of developers to web development that was at least somewhat averse towards how front-end development is done on the web. To this day, I still know developers who loathe JavaScript, CSS and HTML because "they're not the proper way of doing things". Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Probably that's because with desktop applications there's usually only a single language you're dealing with.
- zozbot123 8y ago
  > Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Many GUI applications are actually based on a client-server pattern that mirrors the "front-end" v. "back-end" distinction. Often the "server" is a separate CLI app, or even a daemon/service with no interaction with the rest of the system other than via the platform IPC (COM, DBus, whatever). Consider the traditional large-scale "pattern" of desktop apps, viz. Model-View-Controller. The Model is back-end, the View-Controller pair (which is often tightly coupled anyway) is front-end.
- Novashi 8y ago
  Desktop and web development also got to ignore responsive design for a long time, and that revolution added serious complexity to HTML/CSS/JS and browser engines. You could slap a minimum desktop resolution on your product and call it a day.
  - zozbot123 8y ago
    HTML/CSS were engineered to be device-independent and to separate styling from the underlying semantics, from day one. Properly understood, "responsive design" is a triviality; all good design is responsive design.
    - Novashi 8y ago
      >HTML/CSS were engineered to be device-independent and to separate styling from the underlying semantics, from day one. These were business trends, not mechanical limitations. >Properly understood, "responsive design" is a triviality; all good design is responsive design. I have no idea what you mean by this. Responsive design means for a page to respond to different viewport constraints by re-arranging elements and making rules for different breakpoints that you choose to support. None of that is trivial unless this is another "it's not a hard CS problem so it's trivial" argument.
Illniyar 8y ago
"A team of full stack devs tend towards whatever they fancy when handing out JIRAs, and the separation is still usually front or back-end. It becomes an unofficial silo anyway. The full stack advantage is for sudden departures: the project doesn't completely stop because people can fill in with mediocre code. A disadvantage is that you don't have specialists and risk more technical debt that can't be enforced by linters/testing." The idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both. Much like a backend developer could specialize in certain areas, so can a full-stack one. "he key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?" The term is defined by web technologies. In other areas we have different names - devops is a similar merging of separate roles (At least in some interpretations of the loaded term). I've been in orgs where the job of the DBA was left for developers. In many IOT companies the hardware guys also do low level software. Game development in smaller shops tend to mix tons of roles into a single person. Just because we don't have a name for it doesn't mean it doesn't exist.
- Novashi 8y ago
  >The idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both. Either front/back specialist can google things these days and "do" both sides. If the only goalpost is simply "doing" front or back end, then that just backs my argument that fullstack is kinda BS. The impression I've always been given is that fullstack was good at both, not simply "able to write something that works" in both. This qualification is important because... >Just because we don't have a name for it doesn't mean it doesn't exist. ... the name for it has always been "doing extra work without getting appropriate compensation".
  - iends 8y ago
    What does "good at both" even mean? Where I come from it's "good enough given our time and resource constraints" and generally that's a business decision and not a technical one.
ryanbrunner 8y ago
To add a counterpoint to your evidence, I think an important part of why full-stack tends to be a thing and that front-end / back-end silo less than other disciplines like infrastructure and security is that front end and back end developers more often have a symbiotic relationship. In a fully siloed world, where front-end developers never touched the backend and vice versa, both groups would be completely unable to deliver value or do much of anything useful on their own. That's definitely not true of the examples you provided.
- pseudalopex 8y ago
  Fully siloed infrastructure and development teams can't deliver value on their own either. You can have specialists without silos.
mr_toad 8y ago
> The key evidence to me that full stack is mostly BS is that it only crops up in web roles. Scientific computing / Data Science / Machine learning is an area that benefits from people knowing the full stack. Siloed environments, where the scientists don’t talk to the engineers and the engineers don’t talk to ops are especially poisonous to this type of work. Research and science requires a lot of trial and error and the compartmentalised waterfall style of development doesn’t work well.

BjoernKW 8y ago

The early days of web development up to roughly the end of the 1990s technically were full stack. It's just nobody called it that at the time. It's only by the early 2000s and the advent of architecturally complex, heavily back-end-leaning frameworks such as J2EE or JSP that front-end and back-end diverged. These frameworks had their benefit compared with the fast-and-loose way web apps often were developed before but they also introduced new problems. Apart from inherent architectural issues these frameworks introduced a new crop of developers to web development that was at least somewhat averse towards how front-end development is done on the web. To this day, I still know developers who loathe JavaScript, CSS and HTML because "they're not the proper way of doing things". Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Probably that's because with desktop applications there's usually only a single language you're dealing with.

zozbot123 8y ago
> Furthermore, with traditional desktop applications you also usually have a full stack attitude, although again it isn't called "full stack" in that case. Desktop application developers are typically expected to be able to write both UI code as well as business logic and database access code. Many GUI applications are actually based on a client-server pattern that mirrors the "front-end" v. "back-end" distinction. Often the "server" is a separate CLI app, or even a daemon/service with no interaction with the rest of the system other than via the platform IPC (COM, DBus, whatever). Consider the traditional large-scale "pattern" of desktop apps, viz. Model-View-Controller. The Model is back-end, the View-Controller pair (which is often tightly coupled anyway) is front-end.
Novashi 8y ago
Desktop and web development also got to ignore responsive design for a long time, and that revolution added serious complexity to HTML/CSS/JS and browser engines. You could slap a minimum desktop resolution on your product and call it a day.
- zozbot123 8y ago
  HTML/CSS were engineered to be device-independent and to separate styling from the underlying semantics, from day one. Properly understood, "responsive design" is a triviality; all good design is responsive design.
  - Novashi 8y ago
    >HTML/CSS were engineered to be device-independent and to separate styling from the underlying semantics, from day one. These were business trends, not mechanical limitations. >Properly understood, "responsive design" is a triviality; all good design is responsive design. I have no idea what you mean by this. Responsive design means for a page to respond to different viewport constraints by re-arranging elements and making rules for different breakpoints that you choose to support. None of that is trivial unless this is another "it's not a hard CS problem so it's trivial" argument.

Illniyar 8y ago

"A team of full stack devs tend towards whatever they fancy when handing out JIRAs, and the separation is still usually front or back-end. It becomes an unofficial silo anyway. The full stack advantage is for sudden departures: the project doesn't completely stop because people can fill in with mediocre code. A disadvantage is that you don't have specialists and risk more technical debt that can't be enforced by linters/testing." The idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both. Much like a backend developer could specialize in certain areas, so can a full-stack one. "he key evidence to me that full stack is mostly BS is that it only crops up in web roles. Outside of web dev, people are still silo'd -- security people and systems developers aren't pulled off-task to go work on the company website. We're completely fine accepting their responsibilities in terms of the product. If you're a front or back-end web dev though, there's this constant pressure of "why haven't you learned to full stack yet?" The term is defined by web technologies. In other areas we have different names - devops is a similar merging of separate roles (At least in some interpretations of the loaded term). I've been in orgs where the job of the DBA was left for developers. In many IOT companies the hardware guys also do low level software. Game development in smaller shops tend to mix tons of roles into a single person. Just because we don't have a name for it doesn't mean it doesn't exist.

Novashi 8y ago
>The idea of fullstack isn't that you have no preference at all between backend or frontend, but that you can do both. Either front/back specialist can google things these days and "do" both sides. If the only goalpost is simply "doing" front or back end, then that just backs my argument that fullstack is kinda BS. The impression I've always been given is that fullstack was good at both, not simply "able to write something that works" in both. This qualification is important because... >Just because we don't have a name for it doesn't mean it doesn't exist. ... the name for it has always been "doing extra work without getting appropriate compensation".
- iends 8y ago
  What does "good at both" even mean? Where I come from it's "good enough given our time and resource constraints" and generally that's a business decision and not a technical one.

ryanbrunner 8y ago

To add a counterpoint to your evidence, I think an important part of why full-stack tends to be a thing and that front-end / back-end silo less than other disciplines like infrastructure and security is that front end and back end developers more often have a symbiotic relationship. In a fully siloed world, where front-end developers never touched the backend and vice versa, both groups would be completely unable to deliver value or do much of anything useful on their own. That's definitely not true of the examples you provided.

pseudalopex 8y ago
Fully siloed infrastructure and development teams can't deliver value on their own either. You can have specialists without silos.

mr_toad 8y ago

> The key evidence to me that full stack is mostly BS is that it only crops up in web roles. Scientific computing / Data Science / Machine learning is an area that benefits from people knowing the full stack. Siloed environments, where the scientists don’t talk to the engineers and the engineers don’t talk to ops are especially poisonous to this type of work. Research and science requires a lot of trial and error and the compartmentalised waterfall style of development doesn’t work well.