If you create software with some reusable components and utilize design patterns, you could be building a Framework and not even know it. You could unaware that if you did x or y, you could get even more benefit out of your software. With a few tweaks in your design and architecture from the start, your code could resemble and have benefits from Framework related methods.
I have a keen interest in reuse and specifically frameworks. I have been building frameworks of various sizes and guises for a decade, and this is an accumulation of heuristics out there, that I feel are very important in building a Framework. I have assembled them here in a short list.

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
18. Deploying Patterns - Jonathan Crossland

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. One large flaw in Microsoft.NET Framework currently is the lack of convention within the configuration functionality, which quickly creates 'config-hell'. There must be a balance. (see Works out of the box)

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. There are two interesting sides to this, both have problems, but the finer grained solutions always win over over course grained code.

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. A good framework pays particular attention to patterns and broadcasts them loudly.

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. The WhiteBox is a fundamental concept in software frameworks and has its place.

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".

18. Documenting and Deploying Patterns

Frameworks must be supported, developers advised, and the system taught. Frameworks can have considerably large learning curves, and the appropriate level of support should be given. Just simply writing it is not enough. A framework should have one or more of the following patterns WritingReference, WritingRecipe, WritingCookbook , Self-Describing, DeployWithSupport, DeployWithSampleApplication, DeployWithTraining, DeployAsIntegration

---

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, it takes lots of practice to achieve a balance between these rules

Related posts for a better understanding on how to use these heuristics in your everyday software development.

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


My D4 Software Frameworks outlines further patterns for creating software frameworks.