TIP: A framework should not have TechnicalDebt

TechnicalDebt coined by Ward Cunningham is a metaphor for a quick dirty solution and keeping score of it as debt.
Read more:
- Nick Robinson
- Martin Fowler

The most recent Framework I worked on, had tons of debt, because of reasons out of my control.
The accumulative interest became far too much, to make it properly viable.
At the extreme, the debt and interest that one pays, can detriment the ease-of-use, the flexibility and importantly the main goal of the implementation.

A Framework should be written with as little "debt" as possible. This means that "quick and dirty solutions" are not welcome within the framework.

This does not necessarily mean that it must be designed up front in its entirety, nor does it mean that it will not adapt to new requirements.

A framework can be harder to alter once in the field than any other type of system.
If the interest for a component was 5.5% then a Framework is right up there at the 30% mark.

If you look at it properly, the debt is often distributed in different areas or departments.
As an example, if a Web Application has no layers or components and all code including database access code is within the UI, then you will not have any debt to the Deployment department. If you have a component then part of the debt will be for the Deployment department.
In the case of a Framework, the debt often lies with the client or system using it.
A simple change in the Framework could snowball its way through the client code. If the debt is sky high, your framework may never recover its image.

You could draw a parallel between moving from VB6 to .NET Framework. Look at the resistance that many a developer gave in the early days. The "debt" was squarely on the developer.

But with the move from Framework 1.0 to 1.1, there was almost no debt to the developer whatsoever. A job well done by the .NET Team.