After several years of incrementally building our framework one project at a time, customizing it for several television stations across Europe, we had considerable experience with framework technology at a technical as well as a managerial level [1]. While the decision to use framework technology is mainly evaluated positively, our experience shows that for many companies like ours, success depends on considerations beyond what can be found in the literature on framework technology. Our goal is not to build frameworks but to provide solutions to customers more efficiently and with higher quality. The details of using a framework as a strategic weapon in attacking a vertical market are largely neglected in the literature; so are the difficulties in evolving a custom application into a framework capturing the domain knowledge of a team of software engineers and domain specialists.

Our use of framework technology goes beyond the idea of selling, buying, and instantiating general-purpose application frameworks. We challenge the state of the art in framework technology. While adhering to the traditional dichotomy between framework engineering and application engineering [3], we take a more evolutionary approach by interleaving both activities, thereby requiring close interaction between framework developers and application engineers. Moreover, we challenge the idea that application building boils down to simply filling in the hot spots of a framework (see Schmid in this issue); in many real-world applications, like ours, customization is far more complex. Here we report on the problems that can be encountered when incrementally building a framework, including the lack of good reuse documentation, version proliferation, poor effort estimation, delta analysis, architectural drift, and overfeaturing. We also point out possible solutions for the future.