It's always good to have a foundation, right? I mean if you have a heap of projects going on or you work for a company that has a load of active or future projects then why not have a foundation? Foundations are good. I mean they promote DRY cross projects, reduce development time for many common tasks (logging, data access, etc.). Foundations can also provide a number of tools and technologies that are “approved” — that is they have been throughly researched and you aren't going to trip up over license issues, inexperience of the tech or shortcomings of the tech/tools.
The problem with foundations is that people start assuming they are some sort of magical framework that is supposed to do all the work. You wrong son! A foundation works best when it's a pile of techs/lightweight solutions to common problems. They don't work too well when you just get a big monolithic DLL that acts as an abstraction for other technologies. Abstractions are good for certain things but not everything. A big dll is also harder to document. How do you know whats in it bar using Intellisense or reflector? OK OK OK there should also be some sort of associated documentation that comes with it but keeping these two things inline is extra work. Extra work that doesn't get done — it's not funded work so why bother? Eh?
In our company we use this approach and it works from a technology perspective but from a people perspective it could be better. There is a general lack awareness of what is contained within the magical 3 dlls that get generated and as such less stuff get pushed into the foundation as it probably could. The current process works like so,
- Create a new Subversion repository for the project
- Branch the current Foundation (a Visual Studio Solution) repository for the current project
- Tweak the build step of the Foundation solution to dump it's dlls into the lib folder of the project
- Commit foundation changes to the project foundation branch
- Review and selectively merge changes into the trunk of the Foundation repository
Even writing the steps out and thinking about all the undocumented steps required to get this to work smoothly tells me that it is possibly more complicated than it has to be. In fact the merging back into the Foundation trunk doesn't happen as much as it should. In fact projects adding thing to their own branch of the foundation rarely happens cause it's a bit messy.
Another issue with this approach is that it only makes sense for bespoke code. I mean if you are building out a dll how do you tell people that “actually JSON.NET is our preferred JSON Serialiser”. It's not easy as the documenting and announcing of such things is in another document out in the ether.
An Alternative Approach
Modular. It's the future I tell thee! Discrete pieces of functionality that can run independently. This enables project to take the parts of the foundation they want and build a framework from it. Much like ender (http://ender.no.de/) is doing in the JavaScript world currently being able to take micro-libraries and build a macro-framework that suits your needs and just that. No risk of featureitis, evolve your framework as you need and be in complete control doing it.
Thats the plan but how do we achieve it? HINT: The answer, a partial one anyway, is in the title of this post. Well, first things first we would need to take our current foundation and modularise it. Along with that we'd probably need to ensure tests etc. are up to scratch (start on the right foot). Secondly we would need to change the delivery mechanism - no more branching and merging of codebases - too heavyweight. NuGet (nuget.codeplex.com) will help. With NuGet we could create packages from our modules, manage dependencies, document usage right in the package manifest, and expose these packages as a server and searchable package repository (a la nuget.org). Into this repository we could push all our approved technologies (researched and vetted previously) as well as new versions of our bespoke code. As time goes on this repository can grow and more people can add to it. Heck we can even make the submission process as easy as we see on nuget.org. Wunderbar!
So how would this affect how projects operate on a daily basis?
Well the mechanism for the typical usage is greatly simplified. The project pushes and pulls packages from a central package repo. People use the repo to search for things they need (JSON Serialiser, Micro-ORM etc) and if they don't find something they can then push a new package into the repo (or just suggest one). Self documenting use of 3rd party techs, all available all searchable.
Another advantage of this approach, and using NuGet in particular, allows us to bundle not just dlls but also transform files for configuration (web.xml etc.), javascript/css/other client side assets, project and solution wide tools (executable that can be run from the VS command prompt etc.) and even code samples and templates. This gives us a richer, more cohesive delivery mechanism for a foundation to a project.
Of course it's not all perfect. Urgent changes to bespoke code will need to be done the old fashioned way and pushed to the main server which is less than ideal but it's a bit of an edge case.
So whats not to like about this idea? Foundations not frameworks is the key here. Let the project create its own framework as that will work much better than imposing one upon them.
So this is a bit of a brain dump (some would say brain fart no doubt) as usual and I am open to suggestions and corrections. I've likely missed a few glaring problems with the new approach so let the critics loose and I'll try my best to address their concerns.
Next step - setting up a simple POC to test the general workflow.