Software Factories and Frameworks. How to maintain infrastructure code?

In a reaction to Davy Brion’s post about how to deal with common infrastructure code for multiple projects I’d like to share my take on said topic.  I already placed a brief comment on Davy’s blog but maybe I need to go in a bit more detail to make my point fully clear.

Davy lists these 3 options, each with its pro’s and con’s:

1. Infrastructure code as a separate project.  Binary dependency per client project.
2. Infrastructure code as a separate project.  Copy source code into client project repository.
3. No separate infrastructure project.  Each project contains its own infrastructure code.

If you place these options into following table, you get ‘more consistency over different projects’ on the left hand side and ‘more flexibility’ on the right hand side:

Option 1	Option 2	Option 3
Highest level of consistency Requires a lot of discipline in versioning and maintaining Has to provide many extensibility points for clients to implement their custom behavior Least flexible	Inconsistencies possible between client projects Still requires a certain level of discipline for maintaining different versions Also requires extensibility points for custom implementations A bit more flexible	Inconsistencies between client projects are as good as certain No need to maintain different versions No extensibility points required Very flexible

The question is:  What option would you take?

Easy question, not so easy answer!  My take would be not to pick a single option, but depending on a specific part of the ‘framework’, categorize that part into one of the 3 options.  So, in the following part of my post I’ll address these 3 options as category 1, category 2 and category 3 respectively.

Category 1 code should be (just my first thoughts, some of these points may be hard to implement):

• Ui paradigm independent.  Code in this category should not need to know whether the client project is an asp.net-, a winforms-, a wpf- or even a silverlight application.
• I’m thinking mostly interfaces and abstract classes here… Extensibility is key.
• Very generic code.
• Probably a relatively small code base.

Category 2 code should be:

• More concrete, but still reusable over different projects.
• I’m thinking default implementations here (e.g. an ActiveDirectoryAuthentication component, an EventViewLogger, an ASP.Net BasePage, etc.)
• If proven to be very stable (both in behaviour as in requirements) can possibly be moved to category 1.
• And vice versa: if proven to be unstable (i.e. changes quite often), move to category 3.

Category 3 code should be:

• Very specific for the client project.
• Ideally some components start their life cycle in this category, but are moved/refactored to category 2 if their reuse becomes apparent by taking on specifications of new client projects.

Now, how to organize these categories in assemblies, source control, etc. is not part of this post.  I just wanted to share my theorethical view on this.  Turning this into something practical is the next step…