Our Career Columnist Adam Leffert\’s (www.leffert.com) response to this question.
I’m a full-stack contract developer.
Sometimes I’m hired to work as part of a development team. At those times, I may be working on only one part of the stack: web front end, database, etc.
As for “knowing every aspect”, of course it depends on the individual developer, and on how high you set the bar for expertise.
Anyone can call themselves a “full-stack developer”, so there are probably lots of bad ones out there. You could point to them having spread themselves too thin as the cause their lack of skill in one area. All professionals are responsible for knowing the limits of their abilities, so in these cases the dev either isn’t honest, or isn’t informed enough to know when they’re in over their head.
Full-stack developers are popular for two reasons:
1) For a small project, if the developer is very good, the arrangement can be extremely productive for the client.
I go to a meeting with the client. We discuss some area of the specification.
As soon as the issue is clear, I’ve already thought of the changes I need to make to the database, middle-tier code and UI to support this new understanding.
I go home, make the changes, test and deploy.
No broken API’s.
On a team, I’d have to have one or more meetings with the other developers. Maybe the db person doesn’t agree my my approach to solving the problem. We debate. Maybe they don’t want to do the extra work, or the new approach violates their concept of elegant db design. We may compromise. Maybe the db person has a different understanding of the goal of the feature.
Or the db person is in the meeting, too. Now we’re arguing in front of the client. So we decide to “take this one off-line” and it gets added to a list of issues to work out later.
You get the idea.
With larger projects, these frictions and communication issues are unavoidable. You can try to reduce them, but the challenge is always there.
2) I can work directly for a business client, without having to hire and manage a team.
I meet a businessperson who needs to create a web-based system to do X.
She describes the business problem. We design a solution. We agile our way through design, development, deployment, documentation and support.
I don’t have to gather a team of workers, manage them and charge the client extra for the time spent supervising them, or a rainy-day fund to pay for the times when one of the workers is going to flake out, quit, etc.
With the right developer and the right project, full-stack development can work very well.