Adam Smith vs. fullstack developers - and productivity in DevOps?

Question

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:

=====

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", 2013-2016)

Answer 1

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.

Answer 2

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.

Answer 3

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" 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 4

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.

Answer 5

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.

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 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); 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.

Answer 6

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.