Monday, February 9, 2015

A Formula is Worth a Thousand Pictures: Dijkstra vs Buzan's Mind-Maps

A Formula is Worth a Thousand Pictures: Dijkstra vs Buzan's Mind-Maps

Problems with Pictures with too many details and Complexity
I had the opportunity to attend Tony Buzan's presentation of his famous Mind-Maps at the convention of Management Association of Pakistan held at Karachi in September 2014. Mind-maps became popular in Pakistan some years ago thanks to their use for pictorially representing the concepts in a summary page at the end of each chapter in many of the high school science text books for O/A Level students.  As Buzan was presenting the mind-map concepts, I was comparing them with my experience of graphs and pictorial representations for representing complex concepts, processes and relationships. 


Tony Buzan's opening discussion revolved around the famous adage "a picture is worth a thousand words" and how pictures of the concepts and their relationships in the form of graphs can help in understanding and communication of various phenomena. He also spent some time talking about the use of different colors for distinguishing different relationships. All this while, I was comparing this discussion with the major thrust of the great computer scientist Edsgar W Dijkstra for brevity, beauty and formalism which tries to take us to a much higher level than "picture is worth a thousand words". This is captured by Dijkstra's famous epigram: 
"A formula is worth a thousand pictures"!
Here I detail how I became convinced that graphs and pictorial representations such as Mind-Maps are just a first cut and a very raw representation of the complex ideas that we have in our minds. Limitations of such pictorial representations start becoming evident the moment you start labeling the concepts, then start labeling the arrows (relationships) that connect them, then start identifying all the many different kinds of relationships that may exist between these concepts, and then discovering cyclical structures that exist between them, and then start adding more and more variations of the concepts and their relationships and their siblings and descendants, and you soon find out that these diagrams become so cluttered, and the bubbles become so numerous, and arrows become so confusing that the initial understanding and excitement actually starts evaporating away. Add to this the number of different colors you are forced to use to manage these and the hierarchical layers you are compelled to introduce that you soon realize that diagrams are no longer helpful but are becoming more of a nuisance than a help, more of a chain that is pulling you behind, and less of a spring-board. You, then begin to appreciate the need for more refined methods for solving the complexity that exists in real life situations beyond the few bubbles, arrows and colors with which a mind map initially excited you. 

The hierarchy of representations is shown as a pyramid with physical models at the bottom, followed by the verbal models, followed by pictorial (or graphical) models with the top of pyramid containing mathematical models (also called formulas). 



A model or a representation of reality simply captures the features considered essential for the purpose at hand and ignores other numerous details. Physical models/representations are like the models one sees in ads who capture outer (physical) features of some typical stereotypes, or the dinky cars with which children play with, and which capture the physical (outer) physical features of some specific cars. Physical models often have the greatest amount of detail, but are inflexible as they can describe only a specific instance of reality. Next in flexibility are the verbal representations which are often expressed in natural languages such as presentations, prose or poetry. However, graphical and pictorial models have even greater brevity as represented by the adage "A picture is worth a thousand words". But the greatest brevity and preciseness is, of course, captured by mathematical models or formula that lie at the very top of the pyramid. To appreciate just visualize the immensity of power captured in such a short formula as E = mc2. This small formula captures the energy unleashed by a tiny atom in an atomic explosion and witnessed at Hiroshima. It can't get more simpler and direct than this! 

Hence, Dijkstra's comment "A formula is worth thousands of pictures". His camp believes that you resort to pictures when you are vague and unclear and have not yet crystalized your ideas. But, this realization is not easy to make by those who are just embarking on this journey of managing complexity and trying to identify simple, beautiful and precise expression. This is the quest of special people who think beauty is their business. See my post Beauty is Our Business: Mathematics, Excellence and the Great Dijkstra.

I now relate my personal journey as I transited from the pictorial models to the formula level of the pyramid above. 

My first exposure to pictorial graphs was the use of flowcharts in the 1980s to understand and document the flow of program control. During my internship at IBM Karachi in 1986, I programmed an Inventory Management System using BASIC. My supervisor at IBM was quite impressed with what I had made and asked me to document the program, which I did by profusely illustrating the program flow with many flow charts. [Ten years later when I met this supervisor, I was quite surprised to learn that he not only remembered my internship project but also the flow charts of the documentation!]. 
Spaghetti Code


1970s and 80s were the days in which "spaghetti" code was quite common, so called because the control flow moved from one part of the program to another in a mished-mashed manner resembling cooked spaghetti. This type of crisscrossing of the control flow could only be understood through flow chart diagrams that tried to explain pictorially what was happening. [Although anyone who has seen some huge flow charts containing thousands of elements know their limitation]. Programming languages in the 1980s were still using the notorious Goto Statement that was responsible for such mish-mash spaghetti type of code writing, and were slowly and painstakingly trying to do away with its "unstructuredness". This was despite Dijkstra's classic paper on "Goto Statement Considered Harmful" in 1968 that laid the foundation for the elimination of spaghetti code. This paper heralded the era of "structured" programming which would eventually make the use of flow charts irrelevant. Dijkstra was a firm believer of elegance and beauty which could only be represented by brevity and preciseness [often called "less is more"]. Another of Dijkstra's epigram about languages like COBOL that allow such shoddy thinking and its expression: 
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."
Please note that unfortunately COBOL is still in use! Bad habits die hard. Another of Dijkstra's epigrams: "The prisoner falls in love with his chains." Our familiarity and expertise of an inadequate tool can imprison us in our inefficiency. Often, we can not tear out of the prison of our incompetence because of the steep learning curve required to make the break with the chains of our past. 

For me learning to program without drawing flowcharts was a challenge that I overcame through my experience of DBase programming with which I tried to design a few business applications before I left for USA for my MS and PhD. There I learned "structured" programming using ANSI C and C++. However, my PhD research involved working for around five years with a "graphical" environment for parallel programming called CODE under the supervision of James C Browne. Interestingly enough, this effort held a diametrically opposite position to Dijkstra regarding the use of graphs and animations for managing complexity. It took me about ten years after completing my PhD in 1994, and a failure of my software venture to understand the immensity of what Dijkstra was teaching us about the use of brevity and conciseness for managing complexity.    

The weakness of such diagrams was put in a stark and a scathing context for me by the memorable essay on "Data Flow Diagrams" by the computer scientist Michael Jackson's in his book "Software Requirements and Specification: A Lexicon of Practice, Principles and Prejudices". During this time I got extensive opportunity to work with another fascinating graphical modeling tool Rational Rose and UML diagrams. However, working with these in great detail told me that they become unwieldy for real life situations and you have to use the established techniques for managing complexity. And then came the experience of failure of my software house venture with investment of millions and in which I had invested six years of my life  [Need to post the case study]. This experience convinced me about the wisdom of Dijkstra's thoughts about elegance and beauty of expression on one hand and brevity and conciseness in our representations as detailed in my post "Beauty is Our Business: Excellence and the Great Dijkstra". I now relish this learning recalling Randy Pausch delivering this sentence in his famous Last Lecture: "Experience is what you get when you don't get what you want!" 

Coming to Mind-Maps, I think this is a good start for people who are trying to capture their initial thoughts in easy to remember manner. But, any real life situation is quickly going to get so complex that these tools would soon have to give way for the time tested field of problem solving that includes mastery of concepts such as abstraction: 

"Being abstract is something profoundly different from being vague." -- Dijkstra
Now when I look at diagrams and use of pictures for solving problems I am reminded that: 
"... if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself, Dijkstra would not have liked this, well that would be enough immortality for me." --- Dijkstra
All Dijkstra quotes are from IN MEMORIAM: EDSGER WYBE DIJKSTRA.

Also see:

12 comments:

  1. Very well written sir. In my opinion mind maps could be considered a good exercise for brainstorming and note taking. I have personally used them in my study life and still use them. They are helpful in giving the big picture in short period of time.

    I have used them with subjects like Economics and Law. I have taught Maths in school, but did not see a great application of mind maps in solving mathematical problems, though more organized approach such as flow charts were better alternatives

    ReplyDelete
    Replies
    1. Yes they are good as a first step of scratch pad jotting down of the concepts. However, for more rigorous work use graphical methods underlying which there is a mathmatical formalism such as "owl" type ontologies. As mentioned in my post, flow charts are good as long as we have at most 10-20 concepts. The moment you have ten thousands of these and you are done with pictorial views.

      Delete
    2. Had the very same question after reading it. Totally Agree. As I recently read "As the Chinese say, 1001 words is worth more than a picture." - John McCarthy.

      Delete
    3. Thanks for reading and commenting. This makes me continue to write.

      Delete
  2. Agreed! Its a wonderful piece of reading. Great job Dr Hyder

    ReplyDelete
  3. the script is very comprehensive and engaging, what i needed to know that in the end you were proposing both mind maps and real life problem solving with abstraction, with different levels of complexities of situations and issues to be solved, is that so ? well dijkstra was pro elegance and beauty in addition to brevity conciseness and preciseness, are these achievable in a single problem to be solved ???

    ReplyDelete
    Replies
    1. I think you may have found this post rather more tilted towards some core issues of abstraction in computer science.

      Tony Buzan's mind-maps help only during the initial phase of trying to understand a domain. The mind-maps and similar graphical models become unwieldy when detail and complexity increases.

      Your question whether beauty, elegance as well as brevity conciseness and preciseness are achievable in a single problem is a million dollar observation. If you go through the link of post related to Dijkstra's "Beauty is our business", you will see that not only he but all his disciples not only believe in it, but practice it, and have written books on this. I too have come round to become a believer in this philosophy of his as mentioned in that post, although my supervisor belonged to the opposing camp.

      Delete
  4. As my per my understanding the mind map is good technique for brainstorming. Almost people are using this technique but the method is different . As a teacher write some important points before lecture or we can give the example our PM who always has a Parchi (a piece of paper) during his meeting and addressing.

    ReplyDelete
    Replies
    1. I think this post makes it quite clear that Tony Buzan's mind-maps have a utility but only during the initial phase of understanding a domain. The post is about the need for more formal methods when complexity increases and the detail increases.

      Delete
  5. There we can find more of the probable provisions of values and these have almost influenced students around the globe to initiate their ideas regarding different objects.

    ReplyDelete
    Replies
    1. What has this to do with this post?
      What objects, what ideas, where????
      A promotion robot/

      Delete