Front-end developer: Front-end developers create the code that produces a web design. They primarily work in HTML, CSS, and JavaScript. Some front-end developers will also create the site designs, graphics, and layouts — incorporating some of the UI/UX role.

Back-end developer: Back-end developers create the server systems and code that send data to a visitor’s browser and save data to the back-end for processing. They work in a server-side language that could include PHP, Ruby, Python, .NET, or any number of other programming languages, often a mix of them.

Database developer: A database developer is a specialized back-end developer. He creates databases, plans how data is stored, and tunes it all for maximum speed. There can be much overlap between the database developer and back-end developer. Small teams might have one person do both. Database developers work closely with database administrators, who are in charge of the day-to-day operations of the databases and keeping them running.

User-experience developer: User experience addresses how the site works for visitors. This often overlaps with graphic and user-interface design, but user experience developers typically have a different approach. They are more concerned with the workflows and tasks that a visitor will perform and less concerned with the visual design and artwork. For example, the add-to-cart and checkout processes would be critical for a user experience developer.

When you intend to deploy code which will be consumed by hundreds or thousands of users, it’s very important to get a handle on your skills.

Let’s say you’ve written a web application which has scaled well under stress, and you have received great feedback. Are you a master of everything you used in this stack? Or are you simply good at implementing the layers you needed to make things work together? Implementation alone is an entirely different skill, and an equally valuable one.

The supposed ‘full-stack developer’ combines all elements of front-end and back-end development layers. This person, for example, might create a new design, implement the front-end of the design in HTML and CSS, connect that HTML to the back-end servers, and create a database model to store that data.

Sounds great, but does this person really exist? And if so, is the full-stack developer well-equipped to serve the enterprise? Here are a few issues with the full-stack developer approach:

1. The time-efficiency problem

Under pressure to deliver technology rapidly and at scale, companies only seek to hire the most productive engineering talent: sizable updates or added features to web applications in the enterprise are expected to be delivered in months. In 2016, this seems to favor the programmer who knows more platforms; and with continuous stack expansions and changes, top-tier developers would need to identify and update themselves on entire frameworks and languages conceivably every single month. They would have to be constantly learning, and quickly – maybe too quickly for component reliability. Is this a reasonable ask of a developer who is supposed to be working only 8 hours a day? Does this developer exist?

People often underestimate the task of being up-to-date on knowledge on a single technology stack, let alone the visual design and user interface trends. There are only 24 hours in a day, after all. If a developer is expected to crank out code 8 hours a day, that doesn’t leave much time for updating his craft, including new uses of trending technologies outside of his current stack.

Even if you have a good time-management and functioning agile structures in place, the full-stack developer would still be very busy because he will be always required in different areas. This lack of time will likely contribute to negative performance and task overflow.

Another issue is an inevitability for vacations, and sick days. If the full-stack developer is as good as he perceives, he would be very difficult to substitute. This could generate critical project delays if full participation (that could not be achieved remotely) is required.

2. The specialisation problem

At the core of web application development fundamentals, favoring full-stack engineering over specialists inherently sacrifices performance quality. Having specialised experts in each layer of the stack allows for two important software development factors: more efficient task assignment on an on-going basis, and guaranteed reliability of components development.

Specialisation is a valuable programming asset, and one not easily attained. For full-stack engineers the constant switching gears between languages, frameworks, and platforms comes with a knowledge cost – and inevitably will cause delays via reviewing tutorials, checking educational resources, or just catching up with simple maintenance of regular tasks.

Furthermore, the full-stack developer might not have a clear grasp of project in its entirety due to lack of insight in some areas that only specialists have. However, in all fairness, in this respect the same can happen for specialists. They might have a lack of insight in the global project.

Here’s a quick example showcasing the value of specialists:

You need to increase the performance of your website. If developer A only knows about optimization he might make some mistakes that will break some other part of the site, he doesn’t even know that part even exists. If developer B has a wider knowledge he might know that doing X might break Y. Thus, the probability to make better job is for dev B.

Should you ever focus on recruiting Full-Stack developers?

Full-stack developers can complement an adequately specialised team by floating to the areas that need more help. For example, they might help on the back-end of a major new feature with deadline pressure and then move to the front-end to help create landing pages for an upcoming event. Some start-ups who don’t have the capital or access to specialists across their stack, reasonably seek out full-stack developers: developers that can be flexible with their time and maybe even learn new skills on the way. However, these programmers are extremely hard to come by and with technology stacks continuing to grow, they are increasingly rare.

So, what to do?

If you are so fortunate to have the resources and ability to identify and on-board a team of ‘true’ full-stack developers who could conceivably develop or maintain an entire product, great. However, we find it much more practical and productive to put multiple eyes from specialised skill sets on every assignment.

Full-stack developers – especially in the abstract – seem like an appealing option, but depending on your business context, specialisation is a more effective path.