Framework Development

posted on 2005-06-21 at 09:50:42 by Joel Ross

Ben Carey has a question about frameworks, and is seeking feedback about how we keep our frameworks clutter-free.

I've worked on a couple of frameworks, and I've seen both the good and the bad in them. The bad usually results when the framework isn't tightly controlled. What I mean by that is that everyone has the opportunity to modify the framework, even if they don't have an understanding of what the framework is for.

You see, this is a concept that not everyone grasps. Developing a reusable framework is a different process than building an application. The framework needs to be generic enough that it handles all situations and easy enough to use that it doesn't hinder development. By adding one-offs to frameworks, you decrease the generalness of the framework and make it harder to use - you have to work around the one-off implementation.

So how have we controlled this in the past? On one project, we had a solid team that understood what should go in and what shouldn't go in. It was pretty easy to maintain. But on another project, we actually created a separate repository for the framework, and only gave a few developers access to the framework code. Part of the build process created an installer that the rest of the developers could install and reference in their projects. What got into the framework was tightly controlled.

In practice, that is. When I left the project, the framework was pristine (in my opinion), but eventually, developers who didn't have the framework mentality got a hold of it, and I've heard that it's gotten to be a bit more than it was intended to be.

The moral of the story? Ensure the proper people control the framework, and that they are firm about how it's maintained. Once you get into a position where the framework is getting messy, it's tough - near impossible with large applications - to get back to a fresh state, so ensure it doesn't happen in the first place!

But we know it happens, so how do you get back? I think you have to take the painful task and have someone who (again) knows what the purpose of the framework is. Then, they have to go through it and remove any code that doesn't belong there. There isn't a magic solution here - you're going to break things. The code that gets pulled out is relied on, and therefore must be integrated back into the system in other, more appropriate places. It's painful, but necessary.

Categories: Development