How is technical debt measured?

Determining software quality in general and measuring technical debt in particular is non-trivial. A lot of things need to be taken into account, such as:
o software architecture and design
o frameworks that are used
o coding standards
o system functionality, tests
o etc.
Complexity Map is used to visualize accidental complexity, so it uses the following definition:
Anything in which the actual application deviates from an (hypothetical) ideal application.
Although it is tempting to reject this definition, since it impossible to sharply define the 'ideal' application, this is beyond the point. The Complexity Map is not so much a tool for determining an exact position with regard to application complexity, but much more about showing the proper direction in which to guide code changes. It is a tool which helps to grow the maturity of developers and their development organization.
The Complexity Map application uses static code analysis to look at various key metrics to determine whether the application's stats are within acceptable bounds. Some examples of these metrics are:
o code complexity (cyclomatic complexity, npath complexity, etc.)
o code size violations (e.g. maximum method length, maximum file lengh)
o design-style violations
o explicit coding errors (e.g. equals/hashCode contracts, etc.)