One of the things that I commonly see in my job as a development consultant is customers that spend a great deal of time
and effort on building frameworks for their development projects. Martin1 and I were chatting about this the other day and based on our
experience the average framework seems to have the following requirements:
- It should be expensive and time consuming to build
- It should be come with little or no useful guidance, only minutely detailed API reference
- It should ensure that any product built on it contains a large number of bugs and performance issues
- It should be configurable to the nth degree preferably allowing the location of object instance creation
to be changed at runtime
I could probably go on, but you get the idea. Often the reason cited for needing a framework is to enable the product
to be developed by "stupid" developers by using "smart" developers to create an environment in which the "stupid"
developers can't hurt themselves with the sharp stuff. Now I daresay there are instances where this has worked and
there are also some excellent general purpose frameworks around, but the majority of examples that I see do not fall
into either of these categories (and often, it seems, you can switch "smart" and "dumb").
So what makes a good framework? Firstly I should preface this description with the assumption that I am talking about
.NET Framework applications. So in this case I think that a framework should really be little more than some utility
code (I can think of some common examples that I might post later) and guidance on how to use the .NET Framework to
achieve a particular class of task in a consistent manner. 'Consistent manner' here is defined as the pattern(s) that
an architect/designer has chosen as being optimal for a given situation having made decisions about the potential
tradeoffs involved.
What a good framework isn't is a large, super-configurable behemoth that mandates that developers have to write code in
a particular way and enables anyone with notepad and a basic knowledge of XML to render all of the assumptions made
during the development of the code invalid.
References:
- Martin Parry - http://www.cooboogler.co.uk