Full stack developers - Do they really exist?

So I have to ask whether Adam Bertram, over on the Pluralsight blog really has a point to make or whether he’s just creating linkbait to drive traffic. (I hope it’s the former, since many of his other blogs are quite worthwhile.) For a start, Adam asks a simple question - the same question that I posed as my title - Full stack developers: Do they really exist?

Simple, question, simple answer - yes they do.

I know this without a doubt, for a very simple reason - I am one.

If your technology stack is the stack I know, then you can point me in the direction of your code base, describe your new feature or your defect and I’ll get the job done, regardless of the layer (or layers) that are involved. Whether you need a change to the user experience, to the service API, to a database query or somewhere in between, I’ll find the issue, make a recommendation and get the job done.

I won’t trace a performance problem from the UI down to the service layer and declare that it’s suddenly “some else’s problem” because it’s a server side issue and I’m a client specialist; nor will I design a server API in complete ignorance of how it’s being used, declaring that UX is a client side issue that doesn’t impact me.

Now, I’m not claiming to be an expert at everything - my UX work involves clients written in Windows.Forms, WPF and Excel; if you need a JavaScript guru, I’m not your guy. I’m competent at database design, but if you have need for extreme scale, I’m going to need to consult with my betters.

But this isn’t the debate that Adam Bertram wants to have - he gives his definition of a “full stack developer” near the end of his blog post:

this idea that there’s one person out there with enough skill to replace an entire team

This is a classic straw man argument - take the idea you want to discredit, equate it to something ridiculous and then point out how ridiculous it is. Easy.

And fatally flawed. Just read the comments on Adam’s blog post.

There’s no way that I - or any full stack developer - can replace an entire team - for there’s only one of me. A well functioning team will always out-perform and out-deliver a single person.

And here’s the real value in Adam’s post: not in the misplaced denigration of the full-stack developer, but in the very last sentence:

Companies, supervisors and team members should all work together on better communication.

A well functioning team - one with effective communication - is the team that will deliver usefully, on time and on budget. It doesn’t matter whether that team is made up of narrowly focused specialists or of full-stack generalists, provided the team has sufficient expertise across the full stack to get the job done.

Full-stack developers come into their own in situations where a full team of developers isn’t warranted and may well be too costly.

When you’re in the early stages of product development for a new startup and the entire company is two developers working in someone’s spare room evenings and weekends, you can’t afford to have anyone who restricts themselves to a single role.

When you have a multi-tier production system with two million lines of code and an ongoing (though minor) need for maintenance and feature enhancements, there isn’t enough work for more than one person, yet that person needs to be able to do anything required.

When you have a problem with your multi-million line system and the need for someone to find the root cause of the problem, you can’t afford to have someone who treats some parts of the system as “off limits” because they don’t understand the technology involved.

Lastly, if you have a well functioning team comprised exclusively of specialist experts, you’re likely to run into a balancing issue.

For example, you might have a whole heap of client side JavaScript that needs work and two front-end developers who are working evenings and weekends to meet deadlines, while your database developers take three hour lunches because they have nothing to do.

Adding a couple of full-stack developers into that team can dramatically increase the adaptability and flexibility of the team, empowering it to deliver more business value faster - and surely that’s the point.