Many projects don’t lead to a good solution

Chad Myers discusses an extremely common anti-pattern in the .NET world that usually annoys the shit out of me: too many projects in a solution. I've seen it way too many times as well. A lot of people really want to split everything up into a bunch of assemblies while there's usually no good reason whatsoever. Chad brings up a few issues about this approach, but there are more reasons not to like this.

For starters, i always feel like i'm getting lost in the Solution Explorer when i have to work with these kinds of solutions. Granted, i am a Mac user so that might have something to do with it. I gotta use Vista at work all day and after 3 weeks i still feel hopelessly lost in it. Anyways, easy navigation is very important to me. Especially for my productivity because every time i feel i'm wasting too much time looking for a specific file or a specific namespace of classes, it hurts my rhythm. And that rhythm is something you really don't want to get disturbed by stupid little issues when you're working on some interesting stuff. Granted, if the Solution Explorer was a bit nicer to use (Track Active Item sucks half the time, disabling it makes the other half suck) this probably wouldn't be so big of an issue, but still, it's important to me.

Secondly, many projects slows compilation time which hurts my TDD feedback loop. If you have a lot of projects in your solution your compilation time increases. If you're doing TDD, you're constantly adding/editing code and you're constantly compiling to run a couple of tests. The difference in compilation time between 3 projects or 10 really adds up, even for one day. It leads to frustration, which leads to me taking more breaks from coding. Again, this breaks my rhythm of coding.

And finally, i'm getting tired of developers using purely theoretical arguments to defend practices/approaches that have no practical merit whatsoever (on a side note: i call this the Intellectual Masturbation Syndrome). How often have you heard people say "oh but i want to be able to reuse these bunch of classes somewhere else later on without having references to all this other stuff as well". I've heard it far too many times, and i've almost NEVER seen anyone actually reuse one of those assemblies somewhere else. If you do need it somewhere else later on, split it up at that point. You actually have a valid reason to do so in that situation. But no earlier than that. Or the typical "i think every layer should be in it's own assembly". Yeah that sounds good and all, but i've never seen a real benefit to doing that. If you're worried about your developers using classes from layers in places where they shouldn't be using those classes, you probably have bigger things to worry about. How about teaching them why they shouldn't do that instead of just preventing them from doing it? If you don't trust your developers, they will always disappoint you. Trust them and more importantly, teach them.

So here's my recommendation: ONE project per physical deployment. That's right. A web application that doesn't use a remote service? One assembly. A fat client windows app? One assembly. A smart client windows app? One assembly for the client, one for each application-server deployment and one more assembly for types that are shared between the client and the server. So if you're hosting 10 services on one application server, just go for one assembly server-side. Add another project for your tests, and you should normally end up with between 2 and 5 projects in your solution, depending on how many physical deployments you have.

Btw, i'm currently using two projects for tests... i have a .Tests project, and also a .SlowTests project. Tests that use the file system or the database or anything else like that go in SlowTests. Everything else goes in Tests.