When to add new project to solution

netprojects-and-solutions

I'm tidying up my company's Version Control Guidelines. One of my tasks is to determine how solutions should be organized in a very broad sense.

I have somewhat come to my own conclusion that one broad requirement to document is that, for the most part, CSProj/VBProj projects should live on their own all at the same level in a branch.

However, there are a measureable number of projects that aren't independent, and are tightly coupled to another. For instance, a Unit Testing project has no business by itself since it only exists in support of one other project. So it can (and should) be directly added to a solution with the project it supports. Same with an individual UI who's sole existence is to test one project. Or an implementation test project… and probably similar examples.

So my goal is to mandate, in a way, that projects should not be added directly to a solution except in such examples.

Disclaimer I'm not saying that one application cannot have a solution with multiple projects having been "Add Existing Project" to the solution. But in those cases, each of those projects should be addable/removable because they exist all at the same level of a namespace or folder organization.

This would be easiest if there was some documentation I could find with a history of better wording. But any searches I do just end up with How-To tutorials to add projects to a solution. There are no Best Practies that get into this.

Best Answer

Hmm, trying to mandate how to factor a solution into projects is sort of like mandating how to factor a problem domain into objects in OOP. Good developers know how to do it. Bad developers don't. It is a bit of an art, and an acquired skill, yet is subjective enough that I would avoid mandating too much. I may have 6 different developers who are all bright and experienced and they may factor a solution into projects differently. Everytime someone in one of my clients sets out to create a guideline, it seems that it is all the buzz or a week, then developers go back to doing what they do, and forget about the guidelines.

That said, I don't mean to say it is a useless effort. I think it is assumed that you will factor the individual layers of a particular architecture (such as a Database Drive MVC Web Application) into projects that make sense (like Domain, Data Access, Service Layer, Web Layer, Test Project), but beyond that, you have to ask yourself:

  1. What defines reusable? If it is reusable, with a distinct subject matter, factor it out. If you can envision an appopriate name for the assembly / dll that describes the assembly's subject matter or use, then it is a candidate for a project.
  2. If you can't envision a name for it, besides "Common" or "Tools", then possibly it still belongs in a separate project, but possibly a common shared project for stuff that doesn't fit, but is still reusable. Combine it into an existing common project with the same level of (or lack of) dependencies.
  3. Is it something you can assign to an individual developer? An artifact that you can turn into a robust, reusable library, and even eventually stabilize it so that you don't rebuilt it on the same schedule as your solution? It is a project, at least.
  4. What is maintainable? Too many projects can get out of hand and become a mental or visual burden. If I find myself forgetting where something is, it is probably not in the right place. If I find myself with a screen full of collapsed project nodes, the visual load may also be a bit high for productivity, but not always. Larger, more complex solutions tend to have higher mental and visual load.
  5. At the very least, every project should have a README.txt with a description of what it is.

A certain level of project "factoring" is good to keep a wide, shallow structure. Just like it is bad practice to write HUGE methods or classes, it is bad practice to write HUGE projects. But how can you mandate this, unless all your solutions are the same size and complexity?

Also avoid trying to find a problem for the solution, and instead, make sure there is really a problem, before mandating a solution. Instead, focus on enabling developers to be more productive with automation, productivity tools, simplified company policies, reduced paperwork requirements (cut out redundant time-keeping, etc.) and those things may help as much as the guideline.

When you hire good people, they figure it out anyway. Make sure you really have good people. Processes never fix bad people, but processes do hinder good people.

Related Topic