When the Stack is Stacked Against You

I generally market myself as a "Full-Stack" Developer.

It's an overused term, to the point that it risks falling into meaninglessness, like "Synergy". But I think there is an important distinction there, beneath the recruiting buzzword.

Web or web-connected applications (which is most software, these days), exist in a multi-layered stack of technologies.

In other words, there are distinct components, which use different libraries and even different programming languages. The user interacts with a "client" application on their device, usually either a mobile app or a web page. That client is in constant communication with a server over the internet, and that server communicates with a database to store and retrieve information.

For a team working on this kind of software, there are two common ways to divide up responsibility:

Specialist Teams

Developers work in teams which are specialized in one section of the stack. Frontend Developers take care of the user interface and client-side behavior, and Backend Developers take care of the server-side and database. Usually, they will not have any familiarity with each other's code.

In some large organizations, responibilities can be split even further. You can have User Experience Developers -> Frontend Developers -> Backend Developers -> Database Administrators, all owning distinct slices of the stack.

Generalist (Full Stack) Teams

On these teams, everybody is responsible for everything. This tends to be a more common system in small companies. If there's just one team of six developers in the whole company, it's not very practical to have frontend or backend specialists. If a project comes along which is mostly backend work, it's much better if any and all developers in the company are able to jump on it, rather than just the two backend guys. Generalist teams tend to have total ownership of a smaller number of projects.

Really, full-stack is a better description of team organization than of developer skills. While most Developers have a preference or a proclivity for one section or another, most of us are capable of doing work across the entire stack. We learn our craft by working on small, solo projects first, and solo projects are full-stack by definition.

Specialized teams have the advantage of deep knowledge. It's hard for one person to be both an expert in the latest javascript build tools and an Oracle maven at the same time. If your product is something as vast as say, Facebook, it's not feasible to have any one person be familiar with anything more than a small slice of it. For a product which never has more than a few hundred concurrent users, it's perfectly fine to use a vanilla database setup created by a non-specialist. A product with thousands or millions of users requires someone with deeper knowledge. He will need to make the database operate at maximum efficiency, and to coordinate between multiple instances.

I'm coming to suspect though, that specialized teams are at best a necessary evil.

Over-specialization is costly in terms of communication. A single feature typically spans the full stack: It will need a new page on the front end, which will need to contact a couple different API endpoints on the backend, which will require a new database table and new rows in several old tables. In a full stack team, this can be handled by a single person. On teams of specialists, it requires coordination between multiple people across organizational boundaries

Not only is this slower, it can lead to less than ideal designs. Database administrators will try to control as much of the application as possible by packing business logic into stored procedures. Backend Developers will try to render things server side which could be done much more efficiently on the client side, and frontend developers will sometimes store bits of data in local storage when they really ought to be persisted on the server.

It's sometimes a power play, and sometimes it's because when your only tool is a hammer, every problem looks like a nail.

But most often it's because it's the path of least resistance. If I'm on the frontend team, and I realize that I have one single solitary little counter which I'd like to store for later use, I might think, "It would be such a pain to get the backend team involved with this. It would mean meetings, and changing the requirements documents, and manager signoffs. It would be so much easier to just store it in the browser's local storage. That's not quite the proper way to do it, but it would work for 99% of users."

I think this illuminates the greater problem: That this division tends to make design of the software inflexible. If responsibility is split between a frontend team and a backend team, then neither team has the authority to make even simple changes in the design. It tends to give rise to an additional caste of architects and project managers, whose job is to coordinate between the frontend and backend teams. This creates yet another line of communication which has to be maintained.

I suspect that, even in fairly large-scale projects where it's necessary to have frontend or backend specialties, it's better for backend developers to have at least some familiarity with the frontend code, and vice-versa. The ideal, I think is for every individual to have a T-shaped distribution of skills: A little bit of everything, and deep knowledge of one thing.