The 6 Blind Men and the (Software) Elephant revisited, with an excursion to Mona Lisa
An exercise in modeling by capability
Jörg Heitkötter (joke)
@hiimjoke
EXECUTIVE SUMMARY
Modeling is an iterative process that combines and recombines partially accurate and partially inaccurate ideas into an abstract description of “the subject matter (aka domain) of our modeling exercise”. This description then needs to be refined until it forms a model of “the subject matter of our modeling exercise” that can be used to test hypotheses on “the subject matter of our modeling exercise”. Without iteration, the resulting model is as useless (wrong), as the individual observations of the six blind men in the traditional Indian fable used to illustrate the point in this essay. In software engineering this methodology is known as IID (iterative and incremental design) and dates back to the early 60ies. It’s evolutionary nature also forms the foundation of the recent agile software development movement and its best known methodology called SCRUM, which is just a relatively “new” (1999) member of a family of similar processes and methodologies that exists for decades like RAD (80ies), DSDM (90ies), XP (90ies) and FDD (90ies). The umbrella organization for all these methodologies is the Agile Alliance (agilealliance.org) formed in 2001 to promote IID, i.e. adaptive evolutionary strategies over the single-pass document driven waterfall model of “requirements, design, implementation” [8]. [Ed- HOLY CRAP! YOU LOST THEM AT THE FIRST PARAGRAPH!!]
Keywords
Model, iterative process, evolution, recombination, genetic algorithm, evolution strategy, meta-heuristics, agile, IID (iterative and incremental development), SCRUM, RAD (rapid application development), DSDM (dynamic systems development methodology), XP (extreme programming), FDD (feature driven design), DDD (domain driven design).
“More fundamentally as I argued above, software is very hard to visualize. Whether we diagram control flow, variable scope nesting, variable cross-references, data blow, hierarchical data structures, or whatever, we feel only one dimension of the intricately interlocked software elephant.”
— Frederick P. Brooks, Jr. “No Silver Bullet:Essence and Accidents in Software Engineering” (1986)
“Domain-driven design (DDD) is an approach to developing software for complex needs by deeply connecting the implementation to an evolving model of the core business concepts”.
— Wikipedia (2011)
1. INTRODUCTION
This essay is about modeling and software engineering, for the creative act of writing software is no more than building a model of reality inside a computer. This write-up is basically a “rip-off” or a “mash-up” using the terminology of web 2.0 marketing droids. It is based upon a talk presented by Eric Evans in 2009 [1], who is usually better known for his work on DDD (domain driven design).
The idea presented here is to remind all of us of the fact that perfect models do not exist. Perfect models done right the first time do not exist doubly so, as Douglas Adams might have put it.
Modeling is an iterative process that combines and recombines partially accurate and partially wrong ideas into an abstract description of “the subject matter of our modeling exercise”. This needs to be refined until it forms a “working model” that can be used to test hypotheses on “the thing we want to model”, i.e. its domain. Software engineering is nothing but modelling iteratively inside a computer.
Without iteration, the resulting model is as useless (wrong), as the individual observations of the six blind men in the traditional Indian fable used to illustrate the point in this essay. Only the continuous recombination of diverse observations will form a good “working model.”
This should be no big surprise, since evolution works very much the same way and the outcome of evolutionary processes have proven to be real successful over the past few million years. We can learn a lot from mother nature but observing how “she” does it and so we extend Eric Evans example of the six blind men and the (Software) elephant by an evolutionary process to model a model, i.e. Leonardo da Vinci’s famous model, “Mona Lisa”.
2. MODELING AN ELEPHANT
In the following we will reprint the poem by John Godfrey Saxe (1816–1887) of the famous Indian legend, as published on the Internet [3] and show how 6 blind men model an elephant by capability, which interestingly enough, produces a morale and an unexpected result.
Prelude
It was six men of Indostan
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind.
Iteration 0
The First approach’d the Elephant,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
“God bless me! but the Elephant
Is very like a wall!”
Iteration 1
The Second, feeling of the tusk, Cried, -
“Ho! what have we here
So very round and smooth and sharp?
To me ’tis mighty clear
This wonder of an Elephant
Is very like a spear!”
Iteration 2
The Third approached the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up and spake:
“I see,” quoth he, “the Elephant
Is very like a snake!”
Iteration 3
The Fourth reached out his eager hand,
And felt about the knee.
“What most this wondrous beast is like
Is mighty plain,” quoth he,
“Tis clear enough the Elephant
Is very like a tree!”
Iteration 4
The Fifth, who chanced to touch the ear,
Said: “E’en the blindest man
Can tell what this resembles most;
Deny the fact who can,
This marvel of an Elephant
Is very like a fan!”
Iteration 5
The Sixth no sooner had begun
About the beast to grope,
Then, seizing on the swinging tail
That fell within his scope,
“I see,” quoth he, “the Elephant
Is very like a rope!”
Postlude
And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!
MORAL (Conclusion)
So oft in theologic wars,
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean,
And prate about an Elephant
Not one of them has seen!
3. MODELING MONA LISA
So while we’re at complex systems modeling by software, here is another great, visual example of what IID can achieve.
A couple of years ago, I came across an interesting book entitled “Essentials of Metaheuristics” by Sean Luke [5]. You may not find it interesting, since it is full of non-trivial math and algorithms in a meta language and stuff. It is very interesting for me since it references my “mostly academic work” from over 20+ years ago. [Ed.- Remove: And I even made it into the credits of the printed version, and what else makes you feel better on a day when you know your name is mentioned in a footnote in a book that hardly anyone will ever read?]
The book is really a series of lecture notes by Sean since he’s a Professor at George Mason University, Washington. Sean was a fellow student, when I was a student of evolutionary computation, and the different schools of thought in this new field from around the world were connecting, via the Internet, created lecture series and shared academic wisdom to combine the different ideas of Genetic Algorithms, Genetic Programming, Evolution Strategies, etc. And then there was this one funny guy known as “joke” who was mostly famous for editing the monthly updated frequently asked questions document for the comp.ai.genetic newsgroup, which over time evolved into a book entitled “The Hitch-Hiker’s Guide to Evolutionary Computation” [6]. This “joke” was me.
Now, life moves on and while I used top hang out in Telecoms, I peeked from time to time into my old scientific projects and see how far that field of research has come and how it has changed, i.e. evolved. So when I looked at the cover of his book, while at the same time I was searching for a good visualization of what “modeling” really means, I was immediately struck by the idea to reuse the book’s cover image.
Sean uses a so-called (5 + 1) Evolution Strategy as the modeling algorithm, to approximate the face of Mona Lisa as printed in Wikipedia, using a set of fifty polygons which most closely approximate the original image, the output is depicted in Figure 2.
Note that the (5 + 1) simply means a population of 5 individuals that breed one offspring which is then evaluated against a fitness function that describes the goal of the evolutionary search: In this case the parents are polygons and the offspring is a new polygon that has a shape and color and position derived by recombination of its parent polygons and thus adds to the previously existing image, if it add in a “positive sense,” i.e. the resulting image is closer to the original Mona Lisa image, then the offspring replaces the least fit parent, if it does not add any value it is disregarded (it dies). Then the next iteration starts. Thousands of such iterations breed the solution depicted below.
The original idea to model Mona Lisa using an evolutionary (iterative) algorithm, is not Sean’s but Roger Alsing’s, who even published a software package, so you can try this visualization on your PC at home [7].
4. CONCLUSION
By looking at figure 1, reprinted from [3], we can conclude: Although each of the 6 blind men had no idea what they were “looking” at, or what they perceived was anything close to an animal, leave alone an elephant, the combined capability description of the blind men comes close to the real thing.
There is no such thing as a perfect model. There are only some useful models.
Modeling is a highly iterative exercise that combines and recombines diverse partially correct or even completely wrong ideas. This process will result in a good “working”, i.e. useful model over time,when the correct fitness fucntion is applied.
Time and several iterations are all you need (and love).
They are the essential ingredients to produce something that works. So if we allow a modeling exercise to grow a useful working model, we should have enough patience to let the magic happen.
5. AFTERTHOUGHT
“Incremental development — grow, not build, software. … the building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be accurately specified in advance, and too complex to be built faultlessly, then we must take a radically different approach.
Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built.
So it must be with our software systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms. Then, bit-by-bit it is fleshed out, with the subprograms in turn being developed into actions or calls to empty stubs in the level below.
…The approach necessitates top-down design, for it is top-down growth of software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grown organically out of what is already there.
… One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build. The same benefits can be realized on large projects as on small ones.”
— Frederick P. Brooks, Jr. “No Silver Bullet: Essence and Accidents in Software Engineering” (1986)
ACKNOWLEDGMENTS
Thanks to Michael van Acken for sending me week-end emails for over 20 years now, containing many useful excerpts and links from the books we all should have read. (But never had the time to read.) And special thanks to Eric Evans for coming up with this idea in his 2009 InfoQ talk on software architecture [1,2].
ABOUT THE AUTHOR
Jörg Heitkötter (joke) is a C programming philosopher, hands-on computer scientist and a free software hacker supporting the GNU project even before 1992. He served as Webmaster, head of Research & Development, CSO, Snr. Manager of IT Systems Engineering, Enterprise Architect and DevSecOps Evangelist in the Internet & US Telecoms industry. He became a SCRUM Master in 2010. A Lean Six Sigma black-belt in 2012, and Certified SCRUM Product Owner in 2018. He’s recently changed industires and currently helps build a Multi-cloud strategy (AWS, Azure, etc.) in the banking sector.
REFERENCES
[1] Eric Evans, (2009). “Strategic Design: Responsibility traps”. Eric discusses the need for strategic thinking on how early design decisions have a major impact on the organization and the entire development process. He uses the lens of DDD Strategic Design principles (emphasizing “Context Mapping” and “Distilling the Core Domain”) to show how to avoid strategic failures and achieve strategic successes. Winning strategy starts with the domain. http://www.infoq.com/presentations/design-strategic-eric evans
[2] Eric Evans, (2003). Domain driven design: Tackling Complexity in the heart of Software, Addison-Wesley.
[3] The Blind Men and the Elephant. Copyright © 1998–2008 by Duen Hsi Yen, All rights reserved. Illustration: © 1999 by Jason Hunt. http://www.noogenesis.com/pineapple/blind_men_elephant.h tml
[4] Wikipedia: Blind men and an elephant http://en.wikipedia.org/wiki/Blind_Men_and_an_Elephant
[5] Sean Luke (2009). Essentials of Metaheuristics, Lulu, available at http://cs.gmu.edu/~sean/book/metaheuristics/
[6] Jörg Heitkötter and David Beasley (1994). The Hitch-Hiker’s Guide to Evolutionary Computation. https://github.com/jheitkoetter/hhg2ec/blob/master/hhg2ec-7.1.pdf
[7] Roger Alsing, Genetic Programming: Evolution of Mona Lisa. http://code.google.com/p/alsing/downloads/list
[8] Craig Larman and Victor R. Basili (2003). Iterative and Incremental Development: A brief History, pp 47–56 in IEEE Computer. http://www.highproductivity.org/r6047.pdf
