The code is the truth, but it is not the whole truth

Share/Bookmark

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.

Share/Bookmark

This entry was posted in Code, CQL, Grady Booch, Truth. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://www.pethersolutions.com/ custom web design

    Understanding the what’s and why’s of code is about looking at how the code is used. Tools can certainly help analyse it, but I find properly written behaviour-focused unit tests are also invaluable to this end.

  • john

    Grady Booch has a lot of good thoughts on software design.custom web design

  • http://www.designsoftstudios.com Windows Application Develpoment

    It is not the truth but its being the most important part of the truth..Good post for software Engineering…

  • http://http:www.designsoftstudios.com Windows Application Develpoment

    It is not the truth but its being the most impotant part of the truth..Good post for software Engineering…

  • Manoj Waikar

    Thanks again Patrick for an interesting post on the spiritual :) / business side of the software and for the gem that “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.”

    I haven’t yet got any signs and was unnecessarily struggling to find one, but then later realized the futility of that approach. Thanks for asserting my understanding and please continue posting on such stuff.

  • Steve Py

    Assessing “The whole truth” is one of the things that attracted me to aspects of BDD.

    I loathe documentation because more often than not it lies about what not just what the software “actually” does, and it often even falls out of sync with what the software is supposed to do.

    My design is expressed both in code, and in the unit tests that I write to assert the desired behaviour. Tests based on behaviour expose rationales and intentions and they are easier to keep in-sync with the implementation.

    Understanding the what’s and why’s of code is about looking at how the code is used. Tools can certainly help analyse it, but I find properly written behaviour-focused unit tests are also invaluable to this end.

  • http://codebetter.com/members/Patrick-Smacchia/default.aspx Patrick Smacchia

    >Grady Booch has a lot of good thoughts on software design

    That’s the least we can say :o)

  • http://bjarte.com BjartN

    Grady Booch has a lot of good thoughts on software design, this being one of them.

  • http://twitter.com/BlackTigerX Eber Irigoyen

    not only is it not the whole truth, but those truths can change over time

    http://ebersys.blogspot.com/2009/11/software-ever-changing-truths.html