Some of the ideas are debatable, for example on page 46 they say:
...you cannot understand the beauty of a painting by measuring its frame or understand the depth of a poem by counting the lines...But at the same time it's obvious that you won't see the beauty of the poem looking on it's grammar, syntax or verse structure (these are more-or-less analogues for software design metrics), without actually reading and understanding the sense. That's why my conclusion is that for creating a harmonious software design it's necessary (but not sufficient) for the metrics to be harmonious, too.
...metrics can help to evaluate and improve designs, but those have to be meaningful metrics that are put in a context of design harmony...
What I liked most of all was the concept of visualizing software projects as cities. The metaphor includes classes as buildings and packages as districts. It is implemented in a tool called CodeCity. Some results of its work can be seen on Richard Wettel's page, who actually wrote it. Here is just one of them:
Though, there are few things which I think can make it even better:
- It would be great to see a color scheme based on the developers responsible for changes, for example, using svn blame (it can be useful for both "normal" and "timeline" views).
- Building base should be Sqrt(NOA), not just NOA - it will look more realistic. It also should have an option to scale building height to Log(NOM).
- Color scheme should be configurable - for example, it's hard to see some "outdated" buildings on the dark backgrounds.