Expending the effort on designing formal, hard system boundaries (within the same organization) tends to work less well in practice than it does in theory. The

Expending the effort on designing formal, hard system boundaries (within the same organization) tends to work less well in practice than it does in theory. The 'full-stack' trend serves to compensate for this deficiency by making individual devs feel ownership of a higher proportion of the overall product up and down the stack. As a related effect, it allows the firm to shuffle the devs where they're needed the most, theoretically not limited by their specialization in a particular area. This is a less cynical take than a popular post of mine a year back [1], in which I say: > The 'full-stack' trend is a reflection of rising, dare-I-say unrealistic expectations, one which the author supports by their recommendations in their blog post. By perpetuating the notion that the only 'true way' to be a good developer is to structure their lifestyle around understanding implementation details behind all the layers of a modern tech stack, they place an unnatural reverence on the mythos of hackerdom while ignoring that software development is not solely a creative pursuit. > As it stands now, 'full-stack developer' is a euphemism, which in hip new places means 'we want you to live and breathe code, because you will be given vague requirements and expected to deliver the entirety of the solution from the bits moving across the wire to the UI espousing the latest visual design language in less than a month', and in established places means 'we want an infusion of new blood to bring sanity to some legacy code and we're counting on you to debug and fix everything by yourself'. [1] https://news.ycombinator.com/item?id=12168195 https://news.ycombinator.com/item?id=12168195