The term "full stack developer" has received a lot of attention lately. The thought is that the developer has strong knowledge of every level of the stack:
Business Logic/Service Layer
Going slightly further, the full stack developer is in tune with the customer's needs as well. Some have even included understanding the security and quality assurance aspects of each level. With all of this in place, the full stack developer becomes a one-stop-shop for solution development.
Is This Realistic?
The question becomes if a full stack developer is a realistic option. The answer depends on the developer's role and environment.
In a start-up or prototype environment, the full stack developer position is common. Often times these environments require flexibility and adaptability to change. Thus, if the developer has a strong understanding of all of the levels involved, they are more apt to accommodate the changes. It is important to note that the goal here is building the technology aspect of a given idea and not as focused on producing a production-ready solution.
Corporations may define full stack developers in a different way. One example would be from a Production Support perspective. Here, the developer would be responsible for an application that is currently in use and be expected to have an understanding of each of the layers mentioned above:
Server/Network items may be related to performance or software version concerns
Database/Data Model comes into play when updates are required to the application
The remaining levels are mostly tied to bug fixes and features/enhancements
So, a development manager in charge of supporting existing applications may refer to his team as full stack developers, based upon their day-to-day role.
Full Stack Developer vs. Enterprise Architect
A differentiator comes into play when comparing a full stack developer to the role of an enterprise architect. In my experience, the Enterprise Architecture team consists of individuals who specialize in the levels noted above. They are considered an expert for the level(s) they support. Rarely do they support each and every level.
Thus, when the development manager (in the second example above) requires a major change in the application, the Enterprise Architecture team is consulted. This is because the full stack developer is more of a "jack of all trades and a master of none" (or some). While they may have thoughts on how to handle the major change, they may lack the breadth of knowledge to formula the best solution on their own.
Partial Stack...isn't That the Real Answer?
Following that same (second) example, if no Enterprise Architecture group exists and there are no funds for external consulting, the development manager tends to pick the strongest person in each level and ask that they work together to formulate a solution. If those words are not actually directed as such, the team itself often reaches the same direction on their own. In this case, the full stack developers have become specialized partial stack developers in order to design and deliver the major change.
When faced with the reality of a major change, we often figure out where our strengths are within the team and allocate tasks accordingly. This comes into play not only with major changes, but also with code reviews and advanced troubleshooting. There is always that "go to" person for just about everything that has a challenging component. It is just human nature for us to figure out who the leader is and leverage that resource when needed.
The term full stack developer has received a lot of attention. I only provided a few examples and realize there are more examples out there. While we can reach a pretty good agreement of what is covered in calling someone a full stack developer, the degree by which they implement each level is dependent on their role and environment.
I would enjoy hearing your thoughts. Do you consider yourself a full stack developer in a way different than what I noted above? How is it working for you and your organization?
Have a really great day!