In Favour of Specialisation: A Constructive Case Against the Full-Stack Mandate
Date Published
It is respectfully submitted that the full-stack ideal, however attractive in theory, must be evaluated against the realities of human cognition and the complexity of modern software systems. The positive case is not for narrowness, nor for the abandonment of versatility, but an embracement of the 'T-shape' concept. It is for sustainable specialisation, well-designed collaboration, and a realistic appreciation of what most engineers can reasonably be expected to master. The goal should be durable productivity, not the myth of the interchangeable cog.
First, while some developers can become competent full-stack practitioners, the expectation that most can become so is rather divorced from reality. Full-stack development is not a single skill; it is a broad constellation of disciplines—front-end, back-end, infrastructure, data, security, testing, deployment, and domain knowledge. It is the rare developer who is genuinely polyglot, and rarer still is the developer who possesses sufficient depth across all these domains to work without introducing bugs, duplication, or technical debt. Artificial intelligence may assist with syntax and boilerplate, while to some extent engineering experience is transferable as supply system knowledge, architectural judgment, or the accumulated context that prevents subtle errors. AI can be a useful instrument; it is not a substitute for experience. However, this provides scant mitigation for context-switching.
Second, the cognitive sciences counsel prudence. As Sweller characterised it in 1988, cognitive load is “the total amount of mental effort being used in the working memory” [3]. Multiple psychological studies have shown that the cognitive burden of multitasking harms productivity [1][2]. Context switching has been estimated to consume anywhere from 20% to 80% of productivity depending on the number of concurrent projects [4]. A recent scientific study of software engineers’ perceptions found “that practitioners perceive task switchings are as disruptive as spontaneous and random interruptions, regardless of the source and type of the switching” [5]. The full-stack role, when it becomes a kitchen-sink role, multiplies contexts: one moment a database schema, the next a CSS layout, then the technical design of an API, then a deployment pipeline, then a security audit. Even the gifted polyglot cannot escape the limits of working memory. Attention is finite. The claim that such an arrangement increases productivity is, on the evidence, doubtful.
Third, the argument that full-stack development solves communication problems is a misnomer. It is said that if one person performs every role, there are no handoffs, no misunderstandings, no coordination costs. But communication problems are not eliminated by collapsing roles; they are often merely hidden or displaced. The analogy to medicine is instructive. We do not ask a surgeon to perform the operation, act as nurse, administer anaesthesia, and take the radiograph. We do not do so because the complexity of the human body demands specialisms, and because the cost of error is too high. Hospitals do not solve communication issues by denying specialism. They solve them through protocols, shared records, structured handoffs, and mutual respect for expertise - the very 'checks and balances' that we appear to have forgotten as a profession in our well-intended, but at times, reductionist and absolutist, pursuit of Agile that rather misses the objective. Software engineering, though different in kind, is similarly complex, even it is a form of applied discrete mathematics. If communication issues exist, the remedy is better communication, not the abolition of expertise.
Fourth, engineers with different disciplines are not interchangeable cogs. It is a mistake to treat them as such. Even if an individual engineer can turn their mind to many things, moving them between disparate domains causes cognitive switching. Attention is impacted. Productivity falls. “You build it, you ship it” may sound lean and empowering, but when it means one person must be the entire delivery team, it becomes a false economy. The surgeon does not become the anaesthetist merely because both work in the same theatre. The back-end specialist does not become the front-end specialist merely because both work in the same repository. Different disciplines require different knowledge, different tools, and different habits of mind.
The positive alternative is not to reject versatility, but to cultivate it within a structure that respects limits. Build teams of complementary specialists. Invest in the interfaces that make collaboration safe: documentation, automated tests, integration testing based on the Dev branch, continuous integration and delivery, observability, and clear ownership. Protect deep work by limiting concurrent projects and sequencing priorities predictably. Use AI as an augmentation, not as a substitute for judgment. The result is not less capability, but more sustainable excellence: higher quality, fewer bugs, less duplication, reduced burnout, and more reliable delivery.
In conclusion, the full-stack ideal may be a worthy aspiration for some, but it should not be a universal mandate. The evidence from cognitive science, the analogy to medicine, and the practical realities of complex systems all point in the same direction. The better course is to honour specialism, engineer communication, and design for sustainable productivity. It is respectfully submitted that a T-shape process is the positive, evidence-based way forward.
References
https://www.apa.org/research/action/multitask
https://www.usehaystack.io/blog/83-of-developers-suffer-from-burnout-haystack-analytics-study-finds
https://www.instructionaldesign.org/theories/cognitive-load/