In Continuous Delivery the authors talk about the danger of ultimate configurability…

Configurable software is not always the cheaper solution it appears to be. It’s almost always better to focus on delivering the high-value functionality with little configuration and then add configuration options later when necessary

…and from my experience when you take this over configurability to its logical conclusion you end up developing a framework that can hopefully just be 'configured' for any number of 'front ends'.

This seems to be quite a common thing to do across organisations and typically the decision about what needs to go into the framework is made before there's been much/any development on the applications which will make use of said framework.

In addition the framework is typically built by a different team to the ones who are going to be working on the applications which make use of it.

As a result it's very difficult for that team to know exactly what they should be building so we'll typically end up with something that is overcomplicated for the situations it's actually required for.

In my mind the problem that we create for ourselves is the same as when we try to write a massive piece of code all in one go instead of driving it out through examples.

We try to imagine how the code might be used rather than knowing how it will actually be used.

Udi Dahan talks about favouring use over reuse and I think this is the ultimate example of not doing that.

A more effective approach would be to develop those websites/front ends individually and then let the shared 'framework' evolve from there.

That way we know that we've extracted some shared ideas because we needed to rather than because we thought we might need to.

Even then we need to be careful about what we share between applications because often it might be best to just accept a bit of duplication to avoid the implicit dependency created between teams.

From http://www.markhneedham.com/blog/2010/08/21/ultimate-configurability