CFU's Technical Blog

So, you can see, for such small application, there are 22 projects and a few of them just contain only one interface file. I would say this is a ridiculous overkill today, but to be honest, I kind of liked it a few years ago. It made me feel it was well designed/ structured/separated, and I can proudly tell my friends that I am working on a huge enterprise system which has  dozens of projects.

After worked with a couple of systems having a lot of projects, I have completely changed my mind. One system I worked with, it has 3 Visual Studio solutions for server, client and some sort of infrastructure level stuff. The sever solution has more than 80 projects, client has around 50 and infrastructure has more than 20. It wasn't me who created so many projects in the first place. I said I liked many projects, but I wouldn't go that far. Having so many projects slows down everything, if I accidentally kick off a “Rebuild”, I would have to go and get myself a cup of tea, have a chat with every colleague in the office, and come back. The time wasted, actually isn’t the biggest problem, more important problem is, developers get frustrated with it, and frustrated developers don’t enjoy working on it, they will not try to recompile immediately after they make a change, they will not do enough tests, they will not check in quickly. For example, if a developer is to add a new feature into the system, he will only rebuild the system and test it after he thinks he has completed the task, instead of breaking down the task into a number of smaller ones, and targeting one at the time.  Another important problem is, the project structure should provide some sort of high level overview of the system, i.e. how many components / layers in the system, how do they communicate to each other. Try to get a good picture of a system from a hundred projects is like to figure out how a car works from its nuts and bolts.

Another system I worked with has about 60 projects. Not as many as the first one, but it has more complicated dependencies among the projects. I couldn’t even rebuild whole solution from Visual Studio, because there is some wired circular reference, and of course I couldn’t run from Visual Studio too. What I had to do is to build the individual project I have made changes, copy all the assemblies to a particular location and run it from there, if I need debug through, I had to attach to the process from Visual Studio. So if anyone thinks separated assemblies enforce separation of concerns or decoupling, I could tell you, no, it won’t help you do that.

So, how many projects I will have in a Visual Studio solution? I think for a small application, something around 5 should be enough. For a more complicated system, 10 would be still reasonable. 20 projects probably is the maximum for both a developer and Visual Studio to manage effectively and efficiently, so, I would be very carful and reluctant to go over 20.