There's been a drive towards "full stack developers" lately: http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/ http://www.laurencegellert.c

There's been a drive towards "full stack developers" lately: http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/ http://www.laurencegellert.com/2012/08/what-is-a-full-stack-... That said, most of human history has involved specialization, modularity, and abstraction driving greater productivity. So on one hand, you have work-silos, on the other you have the power of modularity. I think difference with software is that most of the productivity constraints happen at the interfaces. Teams need people that can integrate. They can be generalists, or specialists in a few areas. Earlier in your post you suggest: "But, as you know, many of these problems are either solved or non-existent in Big-Monolithic-App-land. So -- take the things that worked there and use them. Like I said, a common set of shared source code that handles all persistence means all apps can talk to each other using the same code. Changes don't break the chain. Stuff can be fixed in one spot. And so on." IME, multiple teams using the same library can be helpful (if voluntary) or a complete disaster (if forced). The incentives of the library maintainers are not always that of every team.