If you use design patterns and create projects with some reusable components, you could be building a Framework and not knowing it. You could unaware that if you did x or y, you could get even more benefit out of it. I have been building frameworks for a decade in various small and large companies, and this is an accumulation of things out there, that I feel are very important in building a Framework.

1. Convention Over Configuration David Heinemeier Hansson
2. Works out of the box Brian Foote Joseph Yoder
3. Fine grained objects Don Roberts, Ralph Johnson
4. Hotspots and Frozenspots- Wolfgang Pree - Don Roberts, Ralph Johnson
5. Coalescent Patterns Jonathan Crossland(Composite patterns - GoF)
6. One Voice or (Too Many Cooks spoils the..)
7. Prototyping Applications
8. HarvestedFramework Martin Fowler
9. FoundationFramework Martin Fowler
10. Three Examples Don Roberts, Ralph Johnson
11. White-Box Frameworks Don Roberts, Ralph Johnson
12. Black-Box Frameworks Don Roberts, Ralph Johnson
13. Framework Utilities Shai Ben-Yehuda
14. Systematic Generalization Jian Tang
15. Low Surface to Volume Ratio Brian Foote Joseph Yoder
16. Style of Use - Kent Beck in Implementation Patterns
17. Flexible Foundations - Brian Foote Joseph Yoder


If you take your knowledge of these things and apply them into your everyday software design and development, you will be building better software in no time. However be warned, this takes time to understand, and it takes time to get better at balancing these rules together to make frameworks.
Related posts for a better understanding on how to use these heuristics in your everyday developments.

The Every Project Framework - Introduction
The Every Project Framework - Part 1
The Every Project Framework - Part 2

1. Convention over Configuration

Convention over Configuration, but not necessarily without configuration. Convention over Configuration is a simplification mechanism for software which uses standards and conventions to do something out of the box, but still allowing customization. This makes it simpler to get things up and running quickly.

2. Works out of the box

A Framework should always attempt to be "in a runnable state" from the get-go. Not too much configuration, if any. No extensions required. All is there, and all will work, until you decide to intervene. However, a Framework is not an Application and there should always be that distinction. As of yet, there is no actual definition for software framework, that is good enough to define the edges of it. Therefore its difficult to separate application from framework.

3. Fine grained objects

Splitting, refining and making objects smaller until it makes no sense any more to do so. This provides smaller units of extensibility possibilities. Fine grained is important in all development. Rather have small units of function, aggregated to a higher level of ability, than large God objects.

4. Hotspots and Frozenspots

Hotspots are the basic units of extension. It is the extension points, albeit methods, interfaces or other, we use all kinds of means to providing extension and modification of conventional behaviour.
Frozenspots can be thought of as the fixed, core of the Framework. These parts are either fixed structurally or fixed because of a Domain requirement.

5. Coalescent Patterns

Since even the GoF state the 'c'omposite is not to be confused with 'C'omposite, I prefer to use the term Coalescent Patterns. Coalescing patterns is what we do no matter the application or framework we build. However, it is even more important to choose the correct Design Patterns in a Framework. Refactoring a Framework after it is being used is generally not that uninteresting nor is it trivial.

6. One Voice

Too many cooks do spoil a design. Consistency and simplicity is vital in a Framework. Many people can spot flaws, but only one should finalize the decision. Those decisions should be technology and not business based. This is where you will find some of the tension in a Framework project. However it is known that compromise of two great ideas, mostly leads to one very mediocre one.

7. Prototyping Applications

Have a few applications that are being built on the Framework, by people 'outside of the development team' is invaluable. Listen especially to the questions they get wrong, or section in the Framework they seem to misinterpret. These are the muddy areas, that need work. But also creating prototype applications by 'members of the team' will also be valuable in understanding nuances.

8. HarvestedFramework

In short, you build "Applications", while trying to keep things generic and common, which you refactor and refine into what is the Framework part. In my opinion this is better than FoundationFramework.

9. FoundationFramework

Build a Framework by building requirements from inspecting other applications, and then common requirements are implemented as a Framework before any Application actually uses it.

10. Three Examples

This is basically the same or a merging of HarvestedFramework and PrototypingApplications. As it suggests you should build the three applications yourself.

11. WhiteBox Framework

Use FactoryMethod and TemplateMethod. Use Inheritance, by supplying overridable methods.

12. BlackBox Framework

Rely more on Interfaces and object composition.

13. Framework Utilities

A Framework should also contain utilities, code generation, cookbooks, recipes, and reference documentation. I large Framework 'must' have code generation to support the complexity and increase levels of reuse.

14. Systematic Generalization

The idea that working from the top down is better. It is similar to HarvestFramework where you generalize and extract out from an Application.

15. Low Surface to Volume Ratio

Control and do more with less. A simple interface controlling a large set of useful functions is more adoptable than complex controls that do less.

16. Style of Use

In the book, Kent describes three main styles of use: instantiation, configuration and implementation. This is uncannily similar to my Quest to define a Framework, but from a slightly different angle.

17. Flexible Foundations

Allow flexible foundations that allows what would traditionally be immutable to be mutable. Allow and facilitate architectural changes by "selectively exposing the internal architecture".