I quit full stack development because, in many senses, it never seems to work out. In spite of this, the mythical promise of a full stack developer solving the world’s software development problems is alive and well. Why shouldn’t you become (or use) a full stack developer in most cases? The best analogy that I can think of is in the medical field.
Imagine you want surgery… would you go to a specialist or a general practitioner? I don’t believe that you need me to answer that question for you. Why would you want to do the same thing with your software development needs? If you want to develop code, for example, a mobile app, where do you go? Software development has many different disciplines, tools and experience requirements. You need to understand the difference between someone who knows Objective C and Visual Basic. Hiring a full stack developer is like saying “I want to hire a general doctor and have him learn about heart surgery one week and then brain surgery the next.” Can they hire a doctor to do that? Yes, they could, but the results would most likely be unpleasant.
MVP – Full Stack = Win!
One size doesn’t fit all. For prototypes of MVPs, full stack developers are the best! They execute quickly and get the product in front of users in record time. If you need to scale out a real product, peccadilloes of an MVP tend to be noticed more often and require more attention to detail. This is something that a full stack developer will typically run out of time to do.
Product – Full Stack = Loss!
We have utilized full stack development many times, but as professionals, we strongly advocate bifurcating these efforts into full-time backend, full-time front-end development. This allocation allows each developer to focus exclusively on their area and work quickly and efficiently. It also forces users of the API (for example, the front end team) to develop to well-documented standards. Writing UI code is hard. Writing backend code is hard. Let people focus instead of thrashing due to rapid context switching. When initially rolling a product out, developing to standards slows development considerably. Once a product is in use, however, developing to standards that actually move your development along faster and decreases errors.
What do developers think?
If the project is large enough, most developers will quickly agree. While everyone wants to be an expert across all disciplines, the tools aren’t there yet to allow for it. Let the backenders be backenders and leave the front end up to the UI guys/gals!