Suppose you have a number of products, or a number of applications, that share some common functional needs. It seems obviously reasonable to create a separate team to build those functions in common. Often these grow to become known as a framework, and the product or application teams are expected to use it.

It’s a seductive concept, but don’t do it. Why not? I can think of several reasons.

The first is that good frameworks aren’t built before being used. Instead, they’re extracted from successful products or applications. For anything of size, there are bound to be subtleties that you won’t get right until you try it for real. If you’re building a framework first, you’re delaying that first real trial. If the team using the framework is different from the one building it (as things are usually arranged) there’s significant delay for improvements needed by actual use. And that assumes the application team knows that the framework could and would be modified to accommodate them. Most often, they’ll just live with the problems.

Another reason is that your framework will never justify its cost as an internal product. When frameworks are built for sale, they have a large customer base depending on them, or they go off the market. Internal frameworks do not have that large customer base, and can never pay back enough to cover the inefficiencies of working that way. Instead, you’ll have taken the best and brightest of your developers for a framework that can’t turn a profit, starving your actual product of talent.

If you want to build an internal framework, build it from actual use. Put those best and brightest developers on the front lines of customer need, where they can do the most good. Distribute them among your application teams. Have them talk with each other, determining the common needs, and extract the framework as they go. They can act as Component Stewards, guiding the framework development and also guiding the use of it. They can then be in a position to know when the application should adjust to the framework, or the framework should accommodate the application.