Geeks With Blogs
Development In a Tesseract Observations and Developmental Experiences
Being an ultra-introvert, it always freaks me out when a comment I make brings me out from under the radar.

I posted on the list to a thread concerning the pro's and cons.  Jeremy Miller posted an opinion on my comment, and I followed up with a comment on the post.

As a reflection on all that,  I'd like to say that I think that in priciple I'm inclined to agree with Jeremy.  In practice, I'm stuck with the Framework that led to the post.

I believe that my ideas of what a 'Framework' should be is changing.  Jeremy talks about code generation and the templates and IDE productivity stuff, but I think that I'm going a different route myself, although it wouldn't be the first time I was wrong.

What I've been currently trying to do, with the help of the language enhancements (anonymous delegates, generics, lambda expressions, etc.) is get libraries of limited scope reusable objects that can be modified through the use of generics and delegates to perform instance specific work.

What I am working on right now involves a ton of reuse,  many of our systems are basically made up of building blocks that are identical in specification.  Our framework involved creating blocks of reusable objects, along with the rules of validation, that could be dropped into place.

For the first round of systems (which were almost identical), this worked very well; however, as more less similar systems were included, the framework started to show strain.  My original point was that the framework would have been able to be adapted or evolved into a better form, except that the development contracts were written in such a way as to preclude any further development on the system in question (a bad choice by program management).  Once we finally got the money in place to make updates to the framework, the enhancements are stretching the capabilities of the framework.

One of the biggest issues I've had recently was to try to convince a team not to use the system for a project that didn't fit well with the design intent with the framework, and they suffered exactly the fate that Jeremy mentions in his post and would have been better off starting from scratch. Posted on Thursday, January 10, 2008 12:46 PM Software Engineering | Back to top

Comments on this post: Framework Blues

# re: Framework Blues
Requesting Gravatar...
"however, as more less similar systems were included, the framework started to show strain"

I think that is fairly typical of frameworks. Perhaps the trick is in what you do at that your framework flexible enough that it can adjust to the new needs without breaking? Even if it can, should it?

In the end, it comes down to the age-old problem of achieving re-usability. The only way that has been shown to work is to "componentize". A framework is just *too big* to do this with.

The best you can do is ensure that your framework has many individual parts, each of which has potential for re-use. Even then, coupling is a big challenge. The part become dependent on each other (for good reason).

The final, missing piece of the puzzle is packaging (or componentizing). Only when you do this can you truly achieve re-usability across a broad range of projects.
Left by Steve Campbell on Jan 11, 2008 2:27 PM

Comments have been closed on this topic.
Copyright © Steven Mitcham | Powered by: