In a recent interview from Grady Booch, co-creator of UML, Grady said:

When Jim, Ivar, and I began our journey that became manifest in the UML, we never intended it to become a programming language. I think that there's a fairly narrow domain for which model-driven development makes sense but that we should return to the roots of the UML, which was to be a language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system—in short, a graphical language to help reason about the design of a system as it unfolds. Most diagrams should be thrown away, but there are a few that should be preserved, and in all, one should only use a graphical notation for those things that cannot easily be reasoned about in code. As I've also often said, the code is the truth, but it is not the whole truth, and there are things such as rationale, cross-cutting concerns, and patterns that cannot easily be recovered or seen from code.... These are the things for which a graphical notation adds value, and any such notation should be used only if it has predictive power or reasoning power (meaning, you can ask questions about it).

I especially cannot agree more with:

As I've also often said, the code is the truth, but it is not the whole truth, and there are things such as rationale, cross-cutting concerns, and patterns that cannot easily be recovered or seen from code....

The code is the truth, the code represents the whole asset of a software shop. But code base is a complex asset. Call them patterns, rationales, intentions or decisions, there are many valuable intellectual artifacts buried in a code base that cannot easily be recovered or seen from code.

This is something I realized in 1997 while trying for the first time to demystify a C++ legacy code base. I was angry! What, in 1997, we, the professional developers, haven’t any tooling to visualize code? I remember also, in the architecture department next door, the architects were spending days doing diagrams that had nothing to do with what actually the code was. Putting hands in the code was something considered with low value. It was let for fresh graduated like me.

Hopefully, the result of this period was the seed from where the idea of a tool such as NDepend came to me. Code Metrics, Treemap, Dependency Graph, Dependency Matrix, Instability vs Abstractness diagrams… are natural artifacts to shed light on all these precious intentions buried in the code. I especially like the word intentions that was often used by Bruno Boucard, a former colleague I have great respect for. The idea of a language such as Code Query Language came to me when the need to make all these intentions concrete and verifiable, was clear.

What we do is the result of what we did and who we met, no matter whether it was good or bad experiences. There is no such thing as: today, I gonna find an idea to make my own business. Good ideas come naturally along the way, through what, Paulo Coehlo, would call signs.