So you've got some sort of framework, commercial or home-grown.
In the frameworks build or buy discussion, something that's not mentioned is how difficult it is to extract what can -- and what's worth copying -- for use in the next project. What to replicate and carry forward, and what to leave behind, is certainly not obvious. Getting it right the second time is surprisingly difficult.
Getting it right the second (or third, or fourth) time has a lot to do with several factors:
- The quality of the original framework elements,
- The degree the original elements are generic and properly/conveniently abstracted.
- The compatibility of the implementation from one project to the next.
Another issue worth mentioning is what can be updated, and what's worth updating, back into the original codebase from what's developed in the second, third, fourth application.
In this context, the "original elements" can be source code, functions or other micro or macro assemblies, documentation, metadata, or other identifyable elements of the development process.
Here are a few things that may help to repeatedly "get it right".
- Make sure you've got something that can be replicated, and that it's worth replicating. It may be obvious, but don't copy something that's not giving you really acceptable results in the first place.
- Work from a single, active framework template rather than from a copy. This way you ensure the template stays generic and don't unwittingly eventually create "n" more-or-less identical templates for "n" applications. This is hard to do and, quite frankly, most developers don't do this even when using a mature commercial framework.
- if you don't work from a single active framework template, then always keep the "root" application template in mind when enhancing your framework as you develop the current project.
Contributors: Steven Black (who thinks there is a world of undiscovered process patterns here that point to critical modes of success or failure)
( Topic last updated: 2002.12.31 05:17:23 PM )