We're about to start with a new software and there are mixed opinions on the organization of software. I'd be delighted to hear what others might have to say in regard to the presented options as well as what other consideration one might refer to when making such a decision.
- Hierarchical approach
- Interchangeable approach
Approach #1 would consist of a single solution in VS with a number of projects connected to it (such as Utilities, Service, Exporter, Gui etc.). Everything would be in a single collection and the same root directory (for the solution file) and subdirectories (for the project files), so to speak.
Approach #2 would be constituted primarily of a set of projects, not related to each other (other than the references, of course), while the solution's (or solutions', would we desire to create different setups for different deliveries) purpose would be solely to refer to the (external) projects collecting them in the GUI. There would be n+1 directories (one for each project's file and an additional one for the solution's file, or solutions' files later on).
We've discussed the matter and listed the advantages of each approach and, although agreed on the facts, the team's members are not on the same page regarding which one to choose. We're a very democratic organization, so the decision needs to be persuasive to everybody (or at least a vast majority) and there won't be any from-above order from the boss. There's no prior code base and the financial consideration needs not to be addressed.
Which approach is preferable? Which is more of a commonly applied standard in the industry? What considerations might one take to ensure the rigidity of the choice?
It's also fully possible that our current project will be subject to the situation described in this question - both being the one that "borrows" projects from elsewhere as well as being the one that the projects are "borrowed" from.