Full stack teams vs. full stack developers
Saturday, 6 August, 2022 — software
The idea of a “full stack developer” is an insane fantasy, given the complexity of modern software. That’s why we have full-stack teams. Every skill needed to get an idea into our customers hands is represented on the team by at least 2 ppl, & everybody teaches everybody else
This is true-ish. But, it’s far from an absolute, and accordingly, the sentiment is incomplete (Twitter’s design inherently limits nuance.). In my mind, the distinction is in where and how teams invest in complexity and specialization.
What do I mean by that? It breaks down a few different ways:
- Teams with very complex application stacks and deployment mechanisms likely need a lot of internal specialization within the team
- Teams with simpler application will more likely have “full-stack developers” or, what I think is the more applicable term, generalists
- Teams can outsource a lot of complexity to limit where they need specialized knowledge
- Teams frequently insource a lot complexity out of aspiration vs. necessity
Here’s where I see some differences between insourcing and outsourcing from a team. I’ll use a Rails application as an example:
- If the Rails application is a monolith, using server-side rendered HTML, deployed to Heroku, I think the team can primarily be composed of Rails generalists with some specialization for CSS and HTML and also for Rails performance optimizations.
- If the app instead uses a heavy front-end JavaScript framework like React, the team will likely need a specialist in JavaScript and React
- If the app uses other distributed systems within the application or has more complex job processing needs, the team will likely need a specialist in asynchronous job processing, publish/subscribe buses, and job repeatability/idempotency
- Moving towards further complexity, the application is deployed to a cloud provider with Kubernetes, maybe there’s a discrete database vs. using a hosted solution, and the team is now looking at needing specialists conversant in those topics as well
Particularly in the last case, an on-team specialist may not necessarily be a person responsible for maintaining a consumed service. My own team closely matches that last bullet point, but no one on the team is managing our Kubernetes or Google Cloud infrastructure. Our company’s systems engineering team is directly responsible for those items, but our team-based specialists are familiar with how to successfully use those services.
In the first case, we’re looking at a pretty good range of potential teams. Everything from hobbyist applications to solo or paired founders on up to small companies or well-focused teams in a larger engineering organization.
Other things a team may insource vs. outsource:
- Continuous integration
- Code quality metrics, linting, and automated feedback
- API documentation and publication
The overwhelming issue I see with Holub’s sentiment is the assumption that applications and therefore teams need that complexity and the specialization that comes with it. I agree that some teams do, but I suspect many teams don’t. Accordingly, those teams would be better off not taking on that complexity absent very compelling technical and business reasons for doing so.