Don’t build a framework!

I’ve been helping folks with .NET for a little while now and one of the recuring themes I see, especially with larger organisations is the tendency to indulge in a lengthy and expensive framework building process.

Quite often I hear of the “productivity improvements” that teams are getting out of these frameworks. Its not uncommon to hear about projects taking anywhere between twice to ten times as long to achieve successful completion. It’s hard not to see where the attraction is right?

Martin Fowler has some excellent (and short) writing on the subject of harvested frameworks vs. foundation frameworks. So why am I making this post? Its simple, I want the IT services firms out there getting involved in these projects to focus on delivering products that relate to their customers core business – I want them to “wait and see” if frameworks appear. Keep it simple stupid.

About these ads

3 thoughts on “Don’t build a framework!

  1. Mitch Denny

    There is also an important distinction between identifying a pattern in your solution. Here you need to judge whether spending a very small amount of time abstracting out a very specific problem is worthwhile.

    But I guess thats a harvested framework :) At the end of the day you need to see a pay-off for every piece of code that you write, considering more code = more bugs (in general).

  2. Blair

    There has to be a little bit of irony in someone wanting to build a framework over a framework. Keep the posts coming.

  3. Scott McCulloch

    Hi Mitch – we have a foundation framework at CSC, because we do a ton of small projects which are very similar, after the many years of writing the applications (with very little componenet re-use), we took a look at the generic services we were providing in each, and built a core that we would take to each project – we have based a lot of those core services on providers.. fortunately a lot are in whidbey – but since its delayed then i guess we will keep ours for a while longer.

    Our framework also contains a lot of tools, codesmith templates, and a lot of helper classes for handlings things such as nulls, objects, skinning, database interactions. Of course a lot of these are either application blocks, sections of open source applications, or custom written.

    We just wanted a base to start from, to help provide consistency for our support environments mainly. We have found that the framework has provided some level of standardisation in the solutions we deliver – which can’t be a bad thing? We took about 4-6 weeks to write the framework with primarily 1-2 people.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s