… why putting everything together is damn hard.
The current situation…
At work we are currently working on a nice and big project. But sometimes we have to implementing smallish products on the side. They tend to look quite similar, they all share some common self-coded frameworks and they usually have some external libraries they depend on (Castle, NHibernate, EntLib, …). Then they have to be checked into SVN, they should be built and tested on our continuous integration, so an appropriate project should get created there, … Then we need a handful of Domain Objects to do some persisting, usually fairly simple stuff, some services that exposes the “server-side” and finally a GUI.
As you can see even if only setting up a simple solution that is under source control and using continuous integration, even that already takes three totally different tools too setup. Creating the solution in VS, doing a initial checkin via tortoiseSVN and going to your build server via remote desktop and tweaking the configuration files. During all this I tend to make errors, because I am still thinking about an interesting function in the nice and big project. And I am hurrying along, since I want to get back to it. So … I make small errors. Every projects looks the same, but is slightly different. And me being a physicist, I know that a small disturbance repeatedly applied can sometimes lead to severe consequences. 
So, now I created my basic simple solution, but it still lacks the Domain. So, I start adding a project for the domain, choose the right name in order to have a consistent , put all domain objects in the folder DomainObjects. Create the hmb.xml (first remember the syntax again), write the class, write the filtering, write the service, set up basic unit tests, …
I hear you scream: Tobi, all you need here is code generation. Ha, but that’s what I was waiting for, because that means … I need a FOURTH tool.
And we are not done here. Because now we get into the area of external dependencies and common frameworks. Do I put all external libraries in a lib folder under my solution? What about my frameworks? Do I include precompiled assemblies? How will bugfixes in those frameworks propagate into my solution? Will I have two Visual Studios open while improving the framework for the current solution, one for the framework and one for the solution? Or will I put a direct project reference into my solution? How will that decision affect continuous integration? So now I go for msbuild or NAnt. A fifth tool.
Hmm, now I ranted for a couple of pages – and the conclusion is: Even setting up a simple project and starting performing very basic coding tasks is a quite lengthy and errorprone process. BUT it is quite a lot of boilerplate code/configuration that varies very little between different solutions.
What do I want…
… which most likely not what I need! We all know that problem.
<insertion topic=”YAY for tooling”>
Give me six hours to chop down a tree and I will spend the first four sharpening the axe.
Abraham Lincoln
I am inherently lazy, well actually not lazy, lazy, but I strive to maximize my efficiency. If I know I will have to do a task more than three times and implementing a solution will cut the time in half that I will spend on doing said task, I am going to invest in that solution. Did you notice that I didn’t say how much time I invest in implementing that solution? Well sometimes, … No. Actually it never, EVER takes more time than brute forcing my way through the boring repetitive task. Ever! And it’s more fun and I learn a lot! Ha! So there you have it, three great points in favour of implementing tooling:
- … never takes more time than the boring repetitive task!
- … is fun!
- … teaches a lot! (sometimes how not to do it…)
</insertion>
Anyway, back on topic: I want to supply a product name, if applicable dependencies, one or more service names and associated domain objects.
Taking that information a tool automatically sets up a source tree, consistently adds those dependencies, creates the service, domain and tests for the service. It generates the build script necessary for an automated build and test, performes the initial checkin and adds the new project to the continuous integration server.
Right now I don’t see any way around improving on the tools we started writing ourselfs. Because I have not come across a tool that would do these tasks in an efficient way. Maybe I am mistaken?
I have looked at a long list of available tools, but it seems none of them have the capabilities to span across multiple problem domains. Plus most of the available tools have hidious addin APIs. Is it just me, or does anybody else share the feeling that XML is in no way suited for process-based, procedural scripting, such as build scripts. They tend to get very ugly, hard to read and maintain.
Well, do you have any suggestions?
Read on:
Assembly referencing versus direct referencing
And there is more: Be aware of long project names, or …
