So you develop a framework for a project, and it is great. All is good. It does what it needed to, and it does it well. Maybe a few unexpected requests come in, and you manage to incorporate them into the framework. You are very satisfied. Other people are impressed too. Co-workers on other projects start to notice, and they want to use part of your framework to make their own project easier.
Except...that part that they want to re-use has some dependencies on other parts of the framework, that they do not want. "No thanks", they say.
Sound familiar? Perhaps you have been the co-worker, asking after the framework? Was the framework wasted? Is re-use unachievable in your organization?
The fact is, the only way that re-use 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 parts become dependent on each other (for good reason).
The missing piece of the puzzle is packaging (componentizing). Only when you do this can you truly achieve re-usability across a broad range of projects. This is not as trivial as the word "packaging" implies. There is documentation, removal (or internalizing) of dependencies, retrofitting it into the existing system, versioning and deployment. There is also the challenge of letting others know it is available.
When your co-worker came and asked you for part of your framework, the sad truth is that it was already too late. Packaging takes time, and the other project needed its answer today.
Your organization needed to be more pro-active. It needed *someone* to notice the potential of the situation, and have the time and the resources to make something of it.
Friday, January 11, 2008
Subscribe to:
Post Comments (Atom)
1 comments:
Interesting post. You would think that an organization, or an open software project, would start by writing useful components, and then later tying them into a framework, but it often doesn't happen that way.
In fact, a lot of times projects build up huge tech debt by writing an overly coupled framework, then they must go through great pain to extract components.
I think there's a valid reason, though, that you see this trend. I think a lot of people like to do sort of a top-down design, and that leads them to start with a framework, and then they build functionality into the framework. I don't defend this approach too much, just trying to make sense of it.
Post a Comment