This likely isn't the first time you've seen a headline addressing the full stack developer debate, but it's one that warrants attention. Let's talk about how this role can become a crutch for companies and why you might want to avoid it.

The backstory

Traditionally, companies hired developers and operations people to fill very specific roles. Orchestrating a software project consisted of everyone passing tasks to the person with the relevant expertise. The typical project consisted of several people solving widely different problems. This could include front-end developers, backend developers database administrators and system administrators. Each team member knew their specific area inside-out, and maybe even a little bit outside of that. But just because someone knew a little bit about another area, that doesn't mean they took on an additional role. You would have never seen a UX designer fiddling with a database table or PHP developer trying to use tables in a Web page.

And then things changed.

About five years ago, Facebook's Carlos Bueno posted The Full Stack,  encouraging many companies to start looking for “full stack” developers. But wait, what exactly is a full stack developer? In a nutshell, it's exactly what it sounds like: Someone who's expected to know it all; a Jack of all tech, so to speak. This person is supposed to understand each layer that makes up the entire development stack from the database all the way up to the UI. Sounds great, sure, but there's a reason this concept eventually failed; it was a crutch for bad communication.

The problem

Developing a single, highly used Web application is an enormous undertaking. The process, when done right, requires multiple workers with expert-level knowledge, who can communicate effectively throughout the project. To put it simply, there's no way one person could possibly know how to handle each piece of the stack. It seems to me that companies were attempting to save a failing project. Maybe the front-end guys were constantly arguing with the backend guys about performance.  Maybe the database guys wanted all the logic in the database rather than in the code, and perhaps the system administrators were complaining about it using too much memory on the server.

Rather than working toward better team communication, companies turned to the idea of someone who could do it all. It's a dreamy thought, for sure-I can certainly see the appeal. But that doesn't make up for the fact that it doesn't work so well in the real world.

The solution

A successful team consists of experts at each layer in the stack; people who can effectively express their goals, and can also understand the goals of the rest of the team. Bad communication is a common reason for failed projects.

The solution involves getting back to a more traditional method of handling projects. It involves letting go of this idea that there's one person out there with enough skill to replace an entire team. Companies, supervisors and team members should all work together on better communication.