Sunday, April 10, 2011

The 6 blind men and the elephant (with an excursion to Mona Lisa)

“More fundamentally as I argued above, software is very hard to
visualize. Wether we diagram control flow, variable scope
nesting, variable cross-references, data blow, hierarchical data
structures, or whataver, 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)

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 description then needs to be refined until it forms a “the subject matter of our modeling exercise” that can be used to test hypothesis 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 ( formed in 2001 to promote IID, i.e. evolutionary strategies over the single-pass document driven waterfall model of “requirements, design, implementation” [8].

Model, iteration, 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).

“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)


This essay is about modeling. It is basically a rip-off. It is based upon a talk presented by Eric Evans in 2009 [1], who is usually better known for his work on domain driven design. The idea presented here is to remind all of us on the fact that perfect models do not exist. Perfect models done right the first time do not exist doubly so, as Douglas Adams would 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 hypothesis on “the thing we want to model”. 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 elephant by an evolutionary process to model a model, i.e. Leonardo da Vinci’s famous model, “Mona Lisa”.


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.

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!"

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!


I recently came across an interesting book entitled “Essentials of Metaheuristics” by Sean Luke [5]. You will probably not like it, 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 15 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 ever reads?]

The book is really a series of lecture notes by Sean since he’s an Associate 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 documents for the newsgroup, which over time evolved into a book entitled “The Hitch-Hiker’s Guide to Evolutionary Computation” [6].

Now, life moves and while I hang out at Verizon, I peek from time to time into my old projects and see how far that field of research has come. 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 books cover image. Sean uses a so-called (5 + 1) Evolution Strategy as the modeling evolutionary 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 1.

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].

Figure 1: Evolving Mona Lisa using a (5+1) Evolution Strategy,
after a few thousand generations (iterations) [5].


By looking at the picture below, also re-printed 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. 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 model over time. But time and several iterations are needed. They are the essential ingredients to produce something that works. So if we allow a modeling exercise to grow a working model, we should have enough patience to let the "magic" happen:

Figure 2: The Elephant as described by 6 blind men, defining 6 capabilities.


“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 subprogams in turn being developed into actions or alls to
empty stubs in the level below.

…The approach necessitates top-down design, for it is top-down
growing 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 entinties
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)


Thanks to Michael van Acken for sending me week-end emails 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].


[1] Eric Evans, (2009). “Strategic Design: Responsibility traps”. Eric discusses the need for strategic thinking on how early design decisions have 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.

[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.

[4] Wikipedia: Blind men and an elephant

[5] Sean Luke (2009). Essentials of Metaheuristics, Lulu, available at

[6] Jörg Heitkötter and David Beasley (1994). The Hitch-Hiker’s Guide to Evolutionary Computation.

[7] Roger Alsing, Genetic Programming: Evolution of Mona Lisa.

[8] Craig Larman and Victor R. Basili (2003). Iterative and Incremental Development: A brief History, pp47-56 in IEEE Computer.

Friday, April 8, 2011

The software elephant re-visited: Lessons NOT learned from the past

25 years ago in 1986 I had just started my studies at Technical University of Dortmund, and worked on object-oriented analysis & design. I had a long reading list of articles but my favorite was by Frederic P. Brooks, Jr. a professor of computer science at the UNC. It was my favorite, since I studied computer science and biology and Brooks in his paper talked about growing software, instead of building it. He used a biological methaphor in a computer scientific context! I saw what I was intuitively doing in a different light...

Brooks is best known for his collection of essays on the art of software engineering, entitled "The Mythical Man-Month". He worked at IBM and is the father of the then state-of-the art computer operating system OS/360. Briefly Brooks like Don Knuth and a few other US professors were my heros of those days.
At that point in time, when I got to read some of these seminal papers, as they are called today in restrospect, I was somewhat undecided if I wanted to become a biologist or a computer scientist, and the article offered me a way to re-think what I was doing and combine both. I always had felt that both subjects somehow belong together, but only because I loved both subjects. Now I had a reason to continue with both.

I later dropped the idea to master in software engineering and turned to systems analysis since software was too much of a school of thought thing, with too many religious wars--while it lacked (and still lacks) a fundamental theory, which explains why software is intrinsically harder than hardware, and what we can do to solve this fundamental riddle. It is a bit like the grant unifying theory physicists search for in the past centuries but still nobody has any clue yet, if it exists.

System analysis has a nice fundament, i.e. pure mathematics, and the evil twin brother of pure mathematics, i.e. appplied mathematics or "numerics" (math that you need a computer to execute). And the complex systems analysis by evolutionary computation I spent almost a decade in, helped me a lot in combining both biology, computer science, numerics, computer graphice, super computers, etc. So it was time for a change the Internet had begun.

Now after another decade in building enterprise level software,  from Internet start-up to Global Communications Service Provider (CSP), I found myself drowning in maintaining legacy systems or at the helm to rescue multi-year software development projects from a status, also known as "death march". The idea here is to carry the resulting "dead horse" (a project in "death march" inevitably delivers), over the finishing line for project conclusion, proper financial accounting, and claim for "success"--

I have moved on to enterprise architecture. I thought this would be heaven, but woke up in HELL.

But the good thing is, I can now read the stuff I wanted to read over the last years, but never had the time to, since "dead horses" need a lot of heavy lifting... I just re-read the article by Brooks, and with 25 years more experience when I read it last time, I cannot understand why the wealth of knowledge compressed in such seminal writing is largely unknown and/or being ignored by today's generation of software developers, designers, project managers, and worst of all, those enterprise architects who advise the software development projects in large corporations with Power-points and Excel sheetsWe should know better, it is all out there for decades, just go and READ it! APPLY it! REDUCE the accidental artifacts in the process, so we can focus on the essence of the task ahead!

Brooks, Jr., F.P. 1986: "No Silver Bullet—Essence and Accidents of Software Engineering," Information Processing 86. H.J. Kugler, ed. Amsterdam: Elsevier Science Publishers B.V. (North Holland): 1069-1076. (Invited paper, International Federation of Information Processing (IFIP) Congress '86, Dublin, Ireland, September 1986.) Reprinted in Computer, 20, 4 (April 1987) 10-19. Also reprinted in The Mythical Man-Month, Anniversary Edition, Frederick P. Brooks, Jr., Addison-Wesley, 1995.
Now, pulling out my good old gauntlet, I started to write a series of essays. I know they will be useless, as were the essays of the real big shots above, but I know some of you will enjoy reading them, as much as I will enjoy writing them. And the process of writing gives me some peace of mind back, I was missing for many years, when I hardly wrote anything...

Enjoy! Have fun, -joke