I'm helping to manage an external team who are starting to develop new versions of some existing products. Historically, this team has always used a model of a single project in a single solution for about 30 modules in Visual Studio which go together to produce a deployable build.
This is having a detrimental impact on build reliability and quality, because they don't always send us the most up-to-date source code. We're trying to press them to unify all referenced code in to a single solution, but we're getting some resistance - specifically they keep talking about interdependence between modules (read "projects" in Visual Studio) being increased if everything is placed in a single solution file. None of the code in the separate solutions is used elsewhere.
I insist this is nonsense and good development patterns will avoid any such problem.
The team in question also perform bugfix and new feature development on an existing product, the experience of which has been fraught to say the least and suffers from exactly the same problem of splitting over multiple solutions. We've been refused access to their source control (TFS), and the approach we're taking to unify the codebase is to try and at least reduce the number of missing updates and more than occasional regressions (yes, fixed bugs are getting re-introduced in to the product) by saying "send us a ZIP of the entire solution folder so we can unzip, open it in Visual Studio, and press F5 for testing". In terms of general structure and quality, the code is pretty poor and hard to support. This experience is why I'm intent on getting the working processes right as early in the development cycle as possible.
Is there something I'm missing? Is there ever a good reason to keep all that code separated out? For my money it would have to be so compelling a reason that it would be common knowledge, but I'm more than willing to concede that I don't know everything.