With the "agilification" of software development the idea of a full stack developer, a developer that masters all layers of application development has become increasingly popular with businesses.

What exactly this means is rather vague. In the narrow sense it's often used for a developer comfortable working on the front-end, the middleware and back-end, in other words someone who can write SQL, fiddle with Hibernate/Spring (or equivalent) and the JS framework being used. One could argue that full stack programmer might be a more accurate description.

Another definition is developers who have touched most areas of the stack at some point in their career and as such have an idea about what the application needs are and how the different parts should interact. This knowledge goes beyond just programming and includes topics such as systems (how to deploy, what to deploy on, hardware needs etc.), database design, security, privacy,... Suffice to say that this is knowledge acquired through experience which while wide isn't "deep" for all aspects, at least not on all topics (which would be practically impossible anyway).

As a matter of fact, in this sense a full stack developer might be an (oncoming) architect who just refuses to give up programming as is often required/implied when taking on the architect role.

Personally I think the former definition is much more common when (and sensible) so I'll assume that one in the rest of this article.

Benefits

There are a few obvious benefits to having a team of full stack programmers:

• everyone can work on any part of the application
• nobody ends up having total ownership of any part of the application
• there should be a better shared understanding about how the different layers work together
• it's much easier to plan your sprints if you can assume that everyone can do everything

I think the fourth one here is the real reason of the sudden popularity of full stack programmers. I mean, if, for example, you assign a pure back-end developer to a team and there's no back end work in the sprint (or inversely, there's so much its blocking other topics), then what are you going to do? Your sprint planning suddenly got way more complex.

Separation of concerns: API Design and implementation

Certainly the most common pitfall related to full stack development, and a bit of a pet-peeve of mine I must admit, I tend to see is that a single developer ends up implementing both ends of an API, for example a REST API. Either because they're told to do so or because they simply consider it to be faster than to discuss with colleagues first (though the argument for the former is often the latter anyway).

The result of this is often an API that isn't sufficiently generic since it was written towards the explicit use-case the developer had in mind while building it. These APIs are generally hard to modify when requirements change and can end up being entirely useless for any other purpose than the one it was conceived for.

Realistic?

Of course one might wonder how realistic it is to expect programmers to have deep practical knowledge about all parts of a stack.

Most modern applications consist of more than just the "old" trinity of front-end, middleware and back-end, heck even the front-end alone could consist of three or more entirely different "stacks" (Web, iOS, Android,...) using vastly different technologies and the backend might be a combination of various NoSQL and relational datastores!

How reasonable is it to expect people to master all of those?

I'd argue that most so-called "full stack developers" have some specialization but also have some understanding of other parts of the stack. This what I would expect from every developer, however practice has taught me that some developers actually are not interested in other parts of the stack so perhaps the term "full stack developer" is sometimes used as a means to filter out these people?

People with an interest in other parts of the technology stack are likely what most growing companies want (it might be more feasible to hide behind a singular specialization in a big multinational) and the more senior they get the more they will naturally be tending towards the second definition of full stack developer I gave in the opening section.

So...?

In the end I feel the term full stack developer has been abused to such an extent as to have been reduced to a meaningless buzzword. That the various definitions on the Internet vary so much should be rather telling: "full stack developer" is like "DevOps": a buzzword with little meaning left, or rather loaded with the whatever meaning whoever uses it loads it with.