How does all of this get started? One idea expressed is that the developers determine that part of the design would work better as a framework and then start off on the path of building it. However as observed in this blog;
Frameworks do makes sense and generally you have to do them over and over until you get it right, you also need competition among the frameworks to iron out ideas. None of which is possible in a project where the goal is not the framework, rather solution to specific business requirements.
Of this thought it is the last sentence that is worth repeating. The goal of a project is to satisfy a specific business requirement and not to build components that maybe useful in solving other specific business requirements. The blog goes on to points out that as soon as developers get squeezed for time the framework (which is already not on a solid footing) will suffer. This brings us to another very salient point brought out in this entry.
It is very difficult to build a useful framework from a single set of requirements. The best frameworks typically have their roots in a cross section of applications that are all trying to solve approximately the same technical problem. The key word in that sentence is approximately. Each project will bring a slightly different set of requirements to the table and in doing so force the framework to change subtle ways. It is this change over time that will transform the supporting code into a true framework.
As for the sacred code theme in this blog entry, that seems to fall in line with the Lavaflow anti-pattern.