Answers: <p>Adam Smith did not need to consider passing of information from one stage to another.  This is a critical part of any significant IT project.  So a fullstack developer has the significant advantages that:</p>
  
  <ul>
  <li>they don't have to talk to anybody in another department to get things done</li>
  <li>they don't have to wait for those other people to get around to it</li>
  <li>there's much less chance that something will get lost in translation between one layer and another</li>
  </ul>
  
  <p>For more on the importance of information passing in IT projects see Fred Brook's <em>Mythical Man Month</em>.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-19T07:29:15.780Z
Answers: Okay; but, I do not see without a fullstack pin maker wouldn't make pins by himself then?
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-11-19T11:58:36.183Z
Answers: @PeterMuryshkin: Don't compare fullstack developer with pin maker. You can maybe compare the makefile maintainer to the pin maker. A fullstack developer should be compared to a chef. A kitchen can work perfectly fine without a chef same as a dev team can work perfectly fine without a fullstack developer. But a chef can better improve the workflow of a kitchen because he understands everything from the soup to prep to how the kitchen should be kept clean. Same way as a fullstack developer can improve the workflow of a dev team
Answers: slebetman
Answers: CC BY-SA 3.0
Answers: 2017-11-19T11:59:18.240Z
Answers: @PeterMuryshkin Now, as to why a chef is the boss of the kitchen but a fullstack dev is not often the leader of a dev team, that's a question for another day
Answers: slebetman
Answers: CC BY-SA 3.0
Answers: 2017-11-19T14:30:38.617Z
Answers: In physical manufacturing the widget you make in one stage is essentially complete and relatively free of metadata.  In software development the metadata is more voluminous and vital.
Answers: chicks
Answers: CC BY-SA 3.0
Answers: 2017-11-18T21:06:23.743Z
Answers: 2017-11-18T21:06:23.743Z
Answers: chicks
Answers: <p>IMHO the answer has a lot to do with scale and resource availability.</p>
  
  <p>I believe Adam Smith's theory can only be applied at large scale - entire nations/economies in the original context, or, in the SW development context - large development teams.</p>
  
  <p>In a large team it is, indeed, more efficient to hire more specialized human resources:</p>
  
  <ul>
  <li>they aren't rockstars - often considered a danger sign in such large organisations</li>
  <li>they're typically easier to find, cheaper that those with wider expertise spectrum</li>
  <li>they typically don't raise attrition risks - for example they won't be unhappy because they only use a subset of their skills.</li>
  <li>in a (maybe weird) devopsy comparison the <a href="https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets">"cattle vs pets"</a> principle can be applied in such larger organisations, and for quite similar reasons. These specialized resources are, from the business perspective, literally just capita in human resource pools, which sizes that can be rapidly adjusted as needed, typically by hiring/firing.</li>
  </ul>
  
  <p>Oh, and such teams can only be functional if they are complemented by high-quality architect resources which would be necessary to split the product in the smaller, specialized tasks that can be addressed with the specialized resources.</p>
  
  <p>In smaller scale or even one-man teams (typically startups or even isolated smaller teams in larger organisations) it's ineffective or even impossible to use such resources and still get the job done:</p>
  
  <ul>
  <li>they simply don't have the budget/resources to hire the many different specialized resources necessary to cover the entire product development</li>
  <li>they actually seek/appreciate rockstars which can wear multiple hats and immediately switch roles with great flexibility, without incuring delays and additional HR costs</li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-19T17:27:13.237Z
Answers: 2018-03-07T12:47:01.733Z
Answers: 2018-03-07T12:47:01.733Z
Answers: Dan Cornilescu
Answers: <p>I consider myself as a fullstack developer on the basis of the following combination of responsibilities:</p>
  
  <p><strong>Front end and back end programming</strong></p>
  
  <p>I can do UI changes until some extent: write html, css (as a web developer) and in other hand in some extend provide data to the UI from database, provide it in a service etc. </p>
  
  <p>I leave testing, architecture and those aside, meeting customers may be added to the working description. </p>
  
  <p><strong>Opposite</strong></p>
  
  <p>The opposite for my point of view would be strict roles of UI guys and back end guys. </p>
  
  <p><strong>Conclusions</strong></p>
  
  <p>I don't see full stack really that full as you mentioned, more like a fancy expression like agile or cloud that in certain conditions just have to be mentioned to attract people's attention and the real implementation may vary vastly. At least about scrum and agile I have seen so many variations that the terms have run out of meaning. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-18T18:23:40.383Z
Answers: Thank you for aharing nevertheless it is not rxactly an answer to my question, but getting more precise on the term fullstack developer is welcomed
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-11-18T18:18:39.600Z
Answers: 2017-11-18T18:18:39.600Z
Answers: mico
Answers: <p>An important point to understand is that labour division doesn't always mean a different person per step.</p>
  
  <p>I'd take my own history in a car factory, I was on a seat assembly chain, to get a full seat with airbag, leather, head rest etc. the chain was split in 9 stages. We were 9 working on the chain. Each person was doing only one stage at a time, but every hour we were shifting on the next stage to avoid too much repetition. The workday was 8h long so we didn't get on each stage every day.</p>
  
  <p>This is exactly a labour division where you do only one step of the assembly at a given time, that doesn't prevent you to be able to do the full assembly.</p>
  
  <p>As already stated in other answers this is a little different than software development but I think this sheds light on why a Full Stack developer isn't mutually exclusive with labour division, someone with the abilities to handle the whole life cycle of an application is not required to do it all the time.</p>
  
  <p>Generally speaking when I hear FullStack developer I think more of someone able to code efficient back-ends and nice UI at the same time, in opposition with Front and Back Dev.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-22T03:35:20.847Z
Answers: Nice! I'd never considered that, but you're absolutely right! division of labour, is merely splitting the labour into incremental steps.
Answers: Jeremy Davis
Answers: CC BY-SA 3.0
Answers: 2017-11-21T09:06:01.290Z
Answers: 2017-11-21T14:46:35.347Z
Answers: 2017-11-21T14:46:35.347Z
Answers: Tensibai
Answers: <p>In short, I don't think Adam Smith was wrong, but I do think there are some serious differences between his model of labor division in manufacturing and silos in software development.</p>
  
  <p>First, the pin factory example (as far as I know) was merely hypothetical; although most modern manufacturing factories can trace their roots to this division of labor, I am unaware of any studies that have actually tested scientifically this hypothesis. </p>
  
  <p>Second, Smith was primarily concerned with manufacturing material goods; there are certain tangible outputs associated with material production that do not have similar analogs in software development. For example, in pin making, physical dimensions are important as a functional requirement; there's no obvious comparison to that in software.  This is important because tangible objects can be replicated through exact repetition; software development is never the same problem twice.  Developers develop common methods to produce predictable results, but you never code the same problem twice.  Any component developed in the stack has intricacies unlike physical components, and those intricacies have interactions beyond tangible measurement (height, weight, length, etc).  A pin pointer doesn't care how the wire cutter works, as long as the wire gets cut according to spec.  In software development, <a href="https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch" rel="nofollow noreferrer">the boundaries are never quite that clear</a>.</p>
  
  <p>Full stack developers are not expected to do all of the work themselves (they're not intended to be a single pin maker), but they are expected to be capable of understanding all of the elements of the stack and how those elements interact.  A full stack team should be comprised of <a href="https://en.wikipedia.org/wiki/T-shaped_skills" rel="nofollow noreferrer">T-shaped individuals</a> who specialize in one or more areas, but understand the spectrum (and may be able to step in at some level).</p>
  
  <p>Where I think Smith's work holds true in software development is in the area of context switching (or <a href="https://en.wikipedia.org/wiki/Human_multitasking" rel="nofollow noreferrer">multitasking</a>); if a single developer is responsible for all areas of development, it takes time to shift from responsibility to responsibility.  At scale, collaboration between team members with different experiences in the same product team can balance context switching and complex interactions.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-20T17:36:42.800Z
Answers: 2017-11-20T17:36:42.800Z
Answers: Stuart Ainsworth
Answers: <p>There are two types of work:</p>
  
  <ol>
  <li><p><strong>Exploitation</strong> - Well defined work that can be easily divided into well-defined stages, where each stage can be learned and mastered on its own and handover between stages does not require communication.</p></li>
  <li><p><strong>Exploration</strong> - Undefined work, which requires learning and experimentation to accomplish each stage and handover between stages requires massive amounts of communication of all learning and status of the project. </p></li>
  </ol>
  
  <p>Adam Smith concerns himself wholly with exploitation and not at all with exploration. The work done in <strong>Research &amp; Development</strong> departments of the industry is by its definition mostly exploration and so it is not covered in any way by Adam Smith.</p>
  
  <p>But we have seen that in later continuous improvement stages, which are partly exploitative work, the application of CI/CD can bring similar gains in productivity, which could in some way be probably traced down to Adam Smith by someone very imaginative.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-19T07:31:03.433Z
Answers: Especially given that many solutions and examples are there, as well as innumerous tools and components - all of them for free yet complex and diverde.
Answers: Ta Mu
Answers: CC BY-SA 3.0
Answers: 2017-11-19T04:47:13.860Z
Answers: 2017-11-19T04:47:13.860Z
Answers: Jiri Klouda
Body: <p>By Adam Smith, labour division can make you <em>by 240 times</em> more effective (on example of a pin factory producing pins in 18 steps).</p>
  
  <p><strong>Why then are multi-skilled roles are so in demand if this actually reduces productivity - or was Smith just wrong, why then?</strong></p>
  
  <p>Searches for "fullstack developer" still trend on Google, however apparently slower than two years ago:</p>
  
  <p><a href="https://i.sstatic.net/2a7ie.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/2a7ie.png" alt="enter image description here"></a> </p>
  
  <p>=====</p>
  
  <p>To sum up, a <em>full stack developer</em> would be able do virtually all the value chain (correct me if I am wrong):</p>
  
  <ul>
  <li>Discuss with customers and refine workable agile requirements for his part of the job</li>
  <li>Decide which architecture, tooling and components pick up - just give him a notebook</li>
  <li>Write code for frontend, backend, ingration, which is cross device compatile and does not requrire much testing, or includes it</li>
  <li>Profile and scape data, use Cloud AI/ML APIs for advanced features</li>
  <li>Write up required IaC code and rollout</li>
  <li>Be on call in case of error or sales processes</li>
  <li>Be aware of security relevant design, overall patching, migration and modernization</li>
  <li>Account time table in a scroutinized way to ease invoicing of the employer</li>
  <li>... did I forget anything?</li>
  </ul>
  
  <p>UPD - "<em>we need the productivity of specialisation but we don’t want the insular worldview of “extreme division of labour</em>”. (DevOps Guys, <a href="https://www.devopsguys.com/2013/09/24/devops-adam-smith-and-the-legend-of-the-generalist/" rel="nofollow noreferrer">"DevOps, Adam Smith and the legend of the Generalist"</a>, 2013-2016)</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-11-19T08:17:02.030Z
Comments: A jack of all trades is a master of none (ok maybe some).
Comments: Petah
Tags: <culture><project-management>
Title: Adam Smith vs. fullstack developers - and productivity in DevOps?
UserDisplayName: Ta Mu
ThreadText: # Adam Smith vs. fullstack developers - and productivity in DevOps?
  
  (Asked by: username_0 on 2017-11-18)
  
  By Adam Smith, labour division can make you *by 240 times* more effective (on example of a pin factory producing pins in 18 steps).
  
  **Why then are multi-skilled roles are so in demand if this actually reduces productivity - or was Smith just wrong, why then?**
  
  Searches for "fullstack developer" still trend on Google, however apparently slower than two years ago:
  
  [![enter image description here](https://i.sstatic.net/2a7ie.png)](https://i.sstatic.net/2a7ie.png)
  
  =====
  
  To sum up, a *full stack developer* would be able do virtually all the value chain (correct me if I am wrong):
  
  * Discuss with customers and refine workable agile requirements for his part of the job
  * Decide which architecture, tooling and components pick up - just give him a notebook
  * Write code for frontend, backend, ingration, which is cross device compatile and does not requrire much testing, or includes it
  * Profile and scape data, use Cloud AI/ML APIs for advanced features
  * Write up required IaC code and rollout
  * Be on call in case of error or sales processes
  * Be aware of security relevant design, overall patching, migration and modernization
  * Account time table in a scroutinized way to ease invoicing of the employer
  * ... did I forget anything?
  
  UPD - "*we need the productivity of specialisation but we don’t want the insular worldview of “extreme division of labour*”. (DevOps Guys, ["DevOps, Adam Smith and the legend of the Generalist"](https://www.devopsguys.com/2013/09/24/devops-adam-smith-and-the-legend-of-the-generalist/), 2013-2016)
  
  **Tags:** culture, project-management
  
  > **Comments:**
  > **username_1**: A jack of all trades is a master of none (ok maybe some).  
  
  ---
  
  ## 6 answers
  
  ### Answer by username_9 on 2017-11-19. Score: 12 | Accepted answer
  
  There are two types of work:
  
  1. **Exploitation** - Well defined work that can be easily divided into well-defined stages, where each stage can be learned and mastered on its own and handover between stages does not require communication.
  2. **Exploration** - Undefined work, which requires learning and experimentation to accomplish each stage and handover between stages requires massive amounts of communication of all learning and status of the project.
  
  Adam Smith concerns himself wholly with exploitation and not at all with exploration. The work done in **Research & Development** departments of the industry is by its definition mostly exploration and so it is not covered in any way by Adam Smith.
  
  But we have seen that in later continuous improvement stages, which are partly exploitative work, the application of CI/CD can bring similar gains in productivity, which could in some way be probably traced down to Adam Smith by someone very imaginative.
  
  > **Comments:**
  > **username_0**: Especially given that many solutions and examples are there, as well as innumerous tools and components - all of them for free yet complex and diverde.  
  
  ---
  
  ### Answer by username_2 on 2017-11-18. Score: 6
  
  Adam Smith did not need to consider passing of information from one stage to another. This is a critical part of any significant IT project. So a fullstack developer has the significant advantages that:
  
  * they don't have to talk to anybody in another department to get things done
  * they don't have to wait for those other people to get around to it
  * there's much less chance that something will get lost in translation between one layer and another
  
  For more on the importance of information passing in IT projects see Fred Brook's *Mythical Man Month*.
  
  > **Comments:**
  > **username_0**: Okay; but, I do not see without a fullstack pin maker wouldn't make pins by himself then?  
  > **username_3**: @PeterMuryshkin: Don't compare fullstack developer with pin maker. You can maybe compare the makefile maintainer to the pin maker. A fullstack developer should be compared to a chef. A kitchen can work perfectly fine without a chef same as a dev team can work perfectly fine without a fullstack developer. But a chef can better improve the workflow of a kitchen because he understands everything from the soup to prep to how the kitchen should be kept clean. Same way as a fullstack developer can improve the workflow of a dev team  
  > **username_3**: @PeterMuryshkin Now, as to why a chef is the boss of the kitchen but a fullstack dev is not often the leader of a dev team, that's a question for another day  
  > **username_2**: In physical manufacturing the widget you make in one stage is essentially complete and relatively free of metadata.  In software development the metadata is more voluminous and vital.  
  
  ---
  
  ### Answer by username_4 on 2017-11-19. Score: 4
  
  IMHO the answer has a lot to do with scale and resource availability.
  
  I believe Adam Smith's theory can only be applied at large scale - entire nations/economies in the original context, or, in the SW development context - large development teams.
  
  In a large team it is, indeed, more efficient to hire more specialized human resources:
  
  * they aren't rockstars - often considered a danger sign in such large organisations
  * they're typically easier to find, cheaper that those with wider expertise spectrum
  * they typically don't raise attrition risks - for example they won't be unhappy because they only use a subset of their skills.
  * in a (maybe weird) devopsy comparison the ["cattle vs pets"](https://devops.stackexchange.com/questions/653/what-is-the-definition-of-cattle-not-pets) principle can be applied in such larger organisations, and for quite similar reasons. These specialized resources are, from the business perspective, literally just capita in human resource pools, which sizes that can be rapidly adjusted as needed, typically by hiring/firing.
  
  Oh, and such teams can only be functional if they are complemented by high-quality architect resources which would be necessary to split the product in the smaller, specialized tasks that can be addressed with the specialized resources.
  
  In smaller scale or even one-man teams (typically startups or even isolated smaller teams in larger organisations) it's ineffective or even impossible to use such resources and still get the job done:
  
  * they simply don't have the budget/resources to hire the many different specialized resources necessary to cover the entire product development
  * they actually seek/appreciate rockstars which can wear multiple hats and immediately switch roles with great flexibility, without incuring delays and additional HR costs
  
  
  ---
  
  ### Answer by username_5 on 2017-11-18. Score: 3
  
  I consider myself as a fullstack developer on the basis of the following combination of responsibilities:
  
  **Front end and back end programming**
  
  I can do UI changes until some extent: write html, css (as a web developer) and in other hand in some extend provide data to the UI from database, provide it in a service etc.
  
  I leave testing, architecture and those aside, meeting customers may be added to the working description.
  
  **Opposite**
  
  The opposite for my point of view would be strict roles of UI guys and back end guys.
  
  **Conclusions**
  
  I don't see full stack really that full as you mentioned, more like a fancy expression like agile or cloud that in certain conditions just have to be mentioned to attract people's attention and the real implementation may vary vastly. At least about scrum and agile I have seen so many variations that the terms have run out of meaning.
  
  > **Comments:**
  > **username_0**: Thank you for aharing nevertheless it is not rxactly an answer to my question, but getting more precise on the term fullstack developer is welcomed  
  
  ---
  
  ### Answer by username_6 on 2017-11-21. Score: 3
  
  An important point to understand is that labour division doesn't always mean a different person per step.
  
  I'd take my own history in a car factory, I was on a seat assembly chain, to get a full seat with airbag, leather, head rest etc. the chain was split in 9 stages. We were 9 working on the chain. Each person was doing only one stage at a time, but every hour we were shifting on the next stage to avoid too much repetition. The workday was 8h long so we didn't get on each stage every day.
  
  This is exactly a labour division where you do only one step of the assembly at a given time, that doesn't prevent you to be able to do the full assembly.
  
  As already stated in other answers this is a little different than software development but I think this sheds light on why a Full Stack developer isn't mutually exclusive with labour division, someone with the abilities to handle the whole life cycle of an application is not required to do it all the time.
  
  Generally speaking when I hear FullStack developer I think more of someone able to code efficient back-ends and nice UI at the same time, in opposition with Front and Back Dev.
  
  > **Comments:**
  > **username_7**: Nice! I'd never considered that, but you're absolutely right! division of labour, is merely splitting the labour into incremental steps.  
  
  ---
  
  ### Answer by username_8 on 2017-11-20. Score: 3
  
  In short, I don't think Adam Smith was wrong, but I do think there are some serious differences between his model of labor division in manufacturing and silos in software development.
  
  First, the pin factory example (as far as I know) was merely hypothetical; although most modern manufacturing factories can trace their roots to this division of labor, I am unaware of any studies that have actually tested scientifically this hypothesis.
  
  Second, Smith was primarily concerned with manufacturing material goods; there are certain tangible outputs associated with material production that do not have similar analogs in software development. For example, in pin making, physical dimensions are important as a functional requirement; there's no obvious comparison to that in software. This is important because tangible objects can be replicated through exact repetition; software development is never the same problem twice. Developers develop common methods to produce predictable results, but you never code the same problem twice. Any component developed in the stack has intricacies unlike physical components, and those intricacies have interactions beyond tangible measurement (height, weight, length, etc). A pin pointer doesn't care how the wire cutter works, as long as the wire gets cut according to spec. In software development, [the boundaries are never quite that clear](https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch).
  
  Full stack developers are not expected to do all of the work themselves (they're not intended to be a single pin maker), but they are expected to be capable of understanding all of the elements of the stack and how those elements interact. A full stack team should be comprised of [T-shaped individuals](https://en.wikipedia.org/wiki/T-shaped_skills) who specialize in one or more areas, but understand the spectrum (and may be able to step in at some level).
  
  Where I think Smith's work holds true in software development is in the area of context switching (or [multitasking](https://en.wikipedia.org/wiki/Human_multitasking)); if a single developer is responsible for all areas of development, it takes time to shift from responsibility to responsibility. At scale, collaboration between team members with different experiences in the same product team can balance context switching and complex interactions.
  
  
  ---
  
  