Chad Myers at Los Techies tries to get a discussion about why it’s bad to have to many projects: Project anti-pattern: Many projects in a Visual Studio Solution File Some of the consideration is about build performance. He is referencing microsoft blog posts… I know the lure of getting to drink coffee while waiting for builds, but you’re not getting paid for coffee ;) There is an article on O’Reilly about the cost of long development cycles: Dead Time (…code, compile, wait, wait, wait, test, repeat)
This is also reflected in the documentation on team development: Msdn: Team Development with Visual Studio Team Foundation Server: Chapter 3 – Structuring Projects and Solutions in Source Control They recommend you to keep it simple:
Keep the following considerations in mind when designing a project and solution structure:
…
From Brad Adams msdn blog: Perf trade off: lots of small assemblies or fewer bigger assemblies?? Puts it like this: fewer bigger assemblies are better
But he is talking about the performance of your applications. He mentions that they optimize for bigger assemblies. This is probably why visual studio is optimized this way as well.
Integration tests are immensely useful. However, the amount of time you spend on running tests is part of the above mentioned coffee time. If you are writing unit tests when testing your C# code this means less time spent being bored waiting.
Note that they are even factoring in the time it takes you to run the tests. Imagine the Dead Time if you need to test manually. Not to rant, but the Dead Time ratio would be even higher. It’s simple economics that by writing tests as part of your development cycle will make you more productive.
How often do you execute a build per day? Lets say that you do it every 30 minutes ca. If your build time is 1 minute. That gives you a 31 minute cycle. Divide 8 hours by this cycle and you get: 15.5. If the build time is 5 minutes that gives you: 13.7. That means you will be 12% less effective per day.
The above mentioned number is actually misleading. An experienced developer working with well known tools may be able to work in longer cycles thus avoiding a lot of the Dead Time. However, when working in areas you are relatively inexperienced in (only worked with for a few years) you will benefit from the possibility to do explorative coding if your build/test cycle is short. Michael Feathers touches on this issue in his post about the Urge to REPL, the Urge to test. REPL is simply read-eval-print-loop. It’s why you can be very productive when you use scripting languages. You can do explorative coding and get instant feedback without waiting for builds.
The numbers also suggests that monitoring your build time, test time can lead to greater productivity. Maybe not running all of the integration tests but letting a continuous integration server let you know if any of them fails.
Another important factor is: Instant gratification. The joy of seeing the result of your action in a short amount of time.
Partitioning Your Code Base Through .NET Assemblies and Visual Studio Projects
I Don’t Have Time for Unit Tests
Do you want to send a comment or give me a hint about any issues with a blog post: Open up an issue on GitHub.
Do you want to fix an error or add a comment published on the blog? You can do a fork of this post and do a pull request on github.
Comments