The Mythical Man-Month revisited.

One of the most intriguing stories published about culture’s influence on collaborative engineering projects can be found in “The Mythical Man-Month” by Professor Frederick P. Brooks. His book is a classic within Computer Science and also goes by the moniker “TMMM”.

Numerous empirical studies on software engineering projects have referenced TMMM, and every research paper in the relatively new Empirical Software Engineering [ESE 2011] discipline within computer science, starts with quoting it. How come?

Published in 1975, TMMM still provides valuable insight into why certain software projects are destined to fail from the beginning and what we can do to avoid a letdown.

A prime example showcasing the success which can be obtained by applying the knowledge in this book can be found through Microsoft Windows Vista and Windows 7.

Microsoft Research’s ESE used Brook’s wisdom to study what impacts quality of software produced by globally dispersed, culturally diverse teams. They not only studied, but applied their findings and the success attained by Windows 7 far exceeds the negativity surrounding Windows Vista.

Let’s take a look at TMM Chapter 7 “Why Did the Tower of Babel fail?”

According to the Genesis account, the tower of Babel was man’s second major engineering undertaking, after Noah’s ark. Babel was the first engineering fiasco.

The story is deep and instructive on several levels. Let us, however, examine it purely as an engineering project, and see what management lessons can be learned.

How well was their project equipped with the prerequisites for success?
Did they have:

• A clear mission? Yes although naively impossible. The project failed long before it ran into this fundamental limitation.

• Manpower? Plenty of it.

• Materials? Clay and asphalt are abundant in Mesopotamia.

• Enough time? Yes, there is no hint of any time constraint.

• Adequate technology? Yes, the pyramidal or conical structure is inherently stable and spreads the compressive load well.

Clearly masonry was well understood. The project failed before it hit technological limitations.

Well, if they had all of these things, why did the project fail? Where were they lacking? In two respects – communication, and consequently, organization.

They were unable to talk to each other, which led to a failure in coordination and a subsequent break in workflow. 

From these events, we gather that lack of communication led to disputes, bad feelings, and group jealousies. Shortly after, the clans began to move apart, preferring isolation to wrangling.

The Tower of Babel project failed due to lack of collaboration. Cultural differences between the teams working on the project led to a lack of communication and consequent lack of organization required to get the job done.

So how does this relate to large global corporations and their employees? How does it relate to different "corporate clans" like IT, Marketing, Sales, etc. which are eventually spread across the globe?

Simply put: Communication and organization are two sides of the same coin. One cannot expect good communication within an inadequately structured organization.

According to Conway’s Law, “Organizations are limited to produce artifacts that reflect their communication structure”.

Good collaboration tools can ease the situation, but cannot resolve it. One cannot improve communication without imposing changes in organization.

When Microsoft Researchers found that physical distance doesn’t affect post-release fault rates, but distance in the organizational chart does [Nagappan et al (2008), Bird et al (2009)], Microsoft changed the structure of its development organization, which led to a superior quality product, Windows 7.

What would be needed to conduct similar empirical studies at your corporation to find the optimal organizational structure to drive down post-release fault-rates in your software systems? And what do you do to ensure the clans in your globally dispersed work force keep talking to each other?

Tl;dr

Have fun, -joke

[ESE 2011] "Empirical Software Engineering" in: American Scientist, 2011. http://www.americanscientist.org/issues/feature/2011/6/empirical-software-engineering/1

[Nagappan, et al (2008)],The Influence of Organizational Structure On Software Quality: An Empirical Case Study, January 1, 2008.
https://www.microsoft.com/en-us/research/publication/the-influence-of-organizational-structure-on-software-quality-an-empirical-case-study/

[Bird, et al (2009)], Does distributed development affect software quality? An empirical case study of Windows Vista, August 1, 2009.
https://www.microsoft.com/en-us/research/publication/does-distributed-development-affect-software-quality-an-empirical-case-study-of-windows-vista/

Disrupting the way how customer data enters large traditional corporations ("Kings of Analog")

By applying some of the superb mapping ideas of Simon Wardley, traditional corporations ("Kings of Analog"), that still answer faxes or phone calls or Emails or Email attachments can learn from the "Digital natives" (Google, Amazon, etc.), how data from customers should get to them.

We need to disrupt the way how data enters the "Jurassic IT parks", traditional companies still run in their backoffice, Hint: Smarthone Apps might be the answer.

Follow me...?

You can follow me on Twitter @hiimjoke

Autoimmunsysteme von Rechnernetzen (published in NZZ, 1999)

Von Jörg Heitkötter und Gerhard Weinreich
(eingereicht am 16.9.1999)

Systems that are based totally on mechanical principles, Newtonian thinking, tend to be very brittle. If something is slightly the wrong dimension, it tends to break. Biological Systems tend to have different properties. [..] Kevin Kelly has written about this; the Santafe Institute is about this. If we want to build large-scale systems that evolve, that have things that are more like immune systems, we have to look to a different intellectual tradition, not just to mechanical engineering and physics, but to biology and the evolution of natural systems, what we call complex adaptive systems, going forward. Those are the only sources we have of looking at the world around us, of understanding how these kinds of systems, with the properties that we want, emerged in nature.

--Bill Joy
(In a panel discussion at JavaOne 1999
with James Gosling, Bill Joy, Danny Hillis
and Greg Papadopoulos)

Technik und Natur erscheinen uns häufig unvereinbare Gegensätze. Dennoch liefert die Symbiose von Methoden eines Milliarden Jahre alten Trial-and-Error-Systems namens Evolution und modernen Computeranwendungen immer häufiger Lösungswege zu alltäglichen Problemen, die sich in ihrer komplexen Eleganz kein Ingenieur der Welt hätte ausdenken können. In Zukunft wird beispielsweise die Bedrohung unserer Rechner durch Computerviren im exponentiellen Maße zunehmen: Zum einen, weil die Anzahl der unbedarften Internetanwender steigt und somit die Wahrscheinlichkeit der Übertragung von Viren via Email und anderen Dateitransferdiensten; zum andern, weil es immer weniger Software gibt, die speziell für ein Betriebsystem konzipiert wurde. Dies führt zu einer Vereinheitlichung des Ökosystems, das Computerviren, -würmern und anverwandte, vagabundierende Programme zu ihrer erfolgreichen Ausbreitung benötigen.

Ein globales Datennetz, welches bereits John Brunner in seinem Science-Fiction-Klassiker von 1974 „Der Schockwellenreiter" beschrieb, wird der Nährboden der uns bevorstehenden Cambrischen Explosion der Computervirenvielfalt sein: das Internet. Dabei orientierte sich Brunners explorative Phantasie daran, daß bereits Anfang der 70er Jahre fähige Hacker Computerviren programmiert hatten. Der erste tatsächlich dokumentierte Virus namens BRAIN tauchte jedoch erst 1987 an einer amerikanischen Universität auf und infizierte Disketten mit Kopien seiner selbst. Ein Jahr später, also nur 13 Jahre nach Erscheinen des Buches, setzte ein Student namens Robert T. Morris, pikanterweise Sohn des damaligen Chief Scientist der US-amerikanischen NSA, die wissenschaftliche Fiktion in die Tat um. Das später als Internetwurm bekannte Programm, welches auf Grund eines Programmierfehlers vergaß, seine Kopie auf dem infizierten Rechner zu löschen, so daß sich der Wurm nicht nur von Rechner zu Rechner kopierte, sondern tausende von Kopien erzeugte, die sowohl neue als auch bereits infizierte Hosts infizierten; dieses Schneeballsystem brachte mehrere Hundert des damals circa 50.000 Hosts umfassenden Internets zum Zusammenbruch, da sie bald nur noch mit dem Erzeugen von Wurmkopien beschäftigt waren. Heute würde man das ganze wohl eine Internet-DoS-Attacke (engl. Denial of Service) nennen, bei der der Internethost seine eigentliche Funktionen nicht mehr ausüben kann, z.B. die Verwaltung des Festplattenplatzes, der CPU-Zeit oder die häufig feste Anzahl an TCP-Verbindungen.

Computerviren kann man im wesentlichen in drei Klassen einteilen: Dateiviren, Bootviren und Makroviren. Wenn ein Anwender ein mit Dateiviren verseuchtes Programm startet, wird zuerst der Viruscode ausgeführt und das Virus installiert sich selbst im Arbeitsspeicher, so daß es sich an Anwendungen hängen kann, die der Anwender in der Folge aufruft. Bootviren befinden sich in einem bestimmten Bereich einer Diskette oder einer Festplatte, der immer dann ausgeführt wird, wenn der Computer startet. In der letzten Klasse befinden sich die Makroviren, die unabhängig vom Betriebsystem sind. Deshalb können sie sich unglaublich schnell ausbreiten. Um die Ausbreitung zu forcieren, lassen ihre Schöpfer sie vorwiegend auf Microsoft-Produkte los, da dies die größte ökologische Nische im gesamten Ökosystem der unvernetzten Rechnerwelt darstellt.

Genau dies eben ist der Grund dafür, daß sich die Ausbreitung der Viren bisher in Grenzen hielt: daß sie sich nämlich nur in den jeweiligen Betriebsystemen ausbreiten konnten, für die eine bestimmte Software geschrieben war. Sie waren also auf ihre jeweilige ökologische Nische angewiesen, wie etwa dem Boot-Sektor oder der Partitionstabelle eines MS-DOS Festspeichers oder dem BIOS eines bestimmten Herstellers. Seit dem Auftauchen des ersten Microsoft-Word-Makrovirus namens „Concept" in Jahre 1995 und der darauf folgenden explosionsartigen Ausbreitung derartiger Viren ist abzusehen, daß irgendwann die herkömmlichen Methoden der Virenbekämpfung versagen, weil sie langfirstig zu ineffizient sein werden, um die exponentiell wachsende Menge der Viren erfolgreich zu erkennen und zu beseitigen. Aktuelle, populäre Virenscanner erkennen circa 50.000 Viren und deren Variationen. Dabei besitzt jedes dieser Schutzprogramme eine Datenbank mit den Fingerabdrücken oder „Signaturen" der bis dato bekannten Viren, die in raffinierte Bitmuster gepreßt werden, damit ein paralleles Überprüfen von Signaturen mehrerer Viren gleichzeitig möglich wird. Typische Signaturlängen betragen 16 bis 30 Bytes. Aus diesem Grunde können die besten dieser Scanner heute 10.000 Signaturen in 10.000 Programmen in weniger als 10 Minuten durchsuchen. Diese Datenbanken sind üblicherweise nach einem Monat veraltet, so daß immer mehr Hersteller wie z.B. McAfee dazu übergehen, kostenlose Updates der Datenbanken auf ihren Webservern im Internet anzubieten.

Zudem wird versucht, das Problem statt mit exakter Datenbanksuche mittels heuristischen Methoden anzugehen. Dabei verlassen sich die Programmierer auf die Tatsache, daß bestimmte Bitmuster in Form von Maschinencodeanweisungen besonders häufig in Viren verwendet werden. Diese Heuristik muß bei den meisten Virenscannern vom Benutzer aktiviert werden, da diese Methode auch zu Fehlalarmen führen kann. Anti-Virenprogramme besitzen zumeist zwei Ausprägungen: Der Benutzer aktiviert die Scanner, die alle Winkel des Computers nach Virusfingerabdrücken durchsuchen. Virenschilde werden üblicherweise automatisch beim Hochfahren des Computers geladen und legen sich um die wichtigen I/O-Routinen des Betriebsystems; sobald dieses eine verdächtige Virusaktion ausführen würde, wird das Virus gemäß den reichhaltigen Optionen dieser Softwaregattung behandelt. Dieser Artikel beschreibt nun im wesentlichen die logische Fortführung der Entwicklung vom batch-orientierten Virenscanner über den permament aktivierten Virenschild zum Computerautoimmunsystem.

Ein wesentliches Manko aller heutigen Methoden liegt in dem Umstand, daß sie erst aktiviert werden müssen, damit sie auf Virensuche gehen. Kein zeitgenössiges Betriebsystem besitzt ein eigenes im Kernel plaziertes Autoimmunsystem; diese Funktionalität muß durch Drittanbieter hinzugekauft werden. (Einzig die Entwickler der freien BSD-UNIX-Variante OpenBSD versuchen, alle bisher bekannten Sicherheitslöcher von unixoiden Betriebsystemen bereits bei der Kernelimplementierung auszuschließen.) Ein anderes Manko ist, daß heutzutage ein Wechselspiel zwischen Viren und Virenjägern stattfindet, das berühmte Hase-Igel-Spiel: Wenn ein Virus auftritt, müssen Programmierer ein Anti-Virenprogramm schreiben, um ihrer Herr zu werden. In der Zwischenzeit richtet das Virus dann allerlei zum Teil irreparable Schäden an. Dies ist derselbe aus der Biologie bekannte Vorgang des Wettrüstens im Verhältnis von Parasit und seinem Wirt. Dabei erfolgen irreparable Schäden durchaus nicht immer absichtlich: Kein Virus kann sich nämlich vermehren, wenn es den Wirt tötet. 

Daher fanden Viren durch das leicht zum Absturz zu bringende Windows 3.x wenig Möglichkeit, sich anders als über den Bootsektor von Disketten zu verbreiten; erst mit der stabileren Windows’95-Version erfolgte ein bedeutender Schub in der Virenevolution: die Makroviren. Diese setzen nicht mehr auf der Betriebsystemebene auf, sondern eine Schicht höher auf der Applikationsebene. Hierdurch werden diese Viren betriebsystemunabhängig; und Microsoft-Word-Viren können heute Macintosh-, PC- und UNIX-Rechner infizieren, wenn auf letzteren mit MS Office kompatible Programme installiert sind, wie eben das von Sun Microsystems übernommene Star-Office-Paket.

Das Form-Virus zum Beispiel, das einmal im Monat clickende Geräusche im Computerlautsprecher erzeugt, ist für alte PC recht harmlos, da es sich in einem Festplattensektor versteckt, der von früheren DOS Versionen nicht genutzt wurde; heutige Windowsrechner hingegen stürzen ab.

Aus diesem Grunde sehen sich die Computervirologen mittlerweile nach Methoden um, die effizienter sind. Hierbei haben sie sich angesehen, wie das menschliche Immunsystem Viren bekämpft. Die Forscher haben dann festgestellt, daß man einige Strategien des Immunsystems auf die Rechnerwelt abbilden kann. Für die Zukunft lautet also der Ansatz, daß die Bekämpfung der Viren stattfindet, indem man die Rechner mit einer Art Immunsystem ausstattet, das die Viren wie ein menschliches Immunsystem bekämpft. Die Firma Symantec hat angekündigt, im Herbst 1999 ein Antivirenprogramm anzubieten, das bereits Merkmale eines Immunsystems aufweist.

Das Grundproblem des Immunsystems kann auf die Aufgabe reduziert werden, Klassifizierungsmerkmale zu finden, um körperfremde von körpereigenen Substanzen unterscheiden zu können. Bei der Bekämpfung von natürlichen Viren funktioniert das folgendermaßen: Eine sogenannte T-Zelle besitzt Rezeptoren, mit denen sie die Oberfläche eines Objekts untersucht. Handelt es sich um ein körpereigenes Objekt, erkennt die T-Zelle es daran, daß sich an der Oberfläche ein bestimmtes Proteinmolekül befindet, das Bestandteil aller Körperzellen ist. Genau genommen untersucht die T-Zelle nicht einmal das ganze Proteinmolekül, sondern im Laufe der Evolution hat das Immunsystem gelernt, das Molekül an Hand eines relativ kleinen Ausschnitts, einem Peptid von der Größe 8 bis 15 Aminosäuren, zu untersuchen. Das ist auch geboten: So erspart es sich Untersuchungen, die sich in lebensbedrohliche Länge ziehen können. Hier finden wir auch gleich die Parallele zur aktuellen Anti-Virensoftware, die ja ebenfalls nur Fingerabdrücke, also kurze Sequenzen aus dem Virencode, zum Aufspüren verwendet.

Eine weitere wichtige Eigenschaft des Immunsystems ist die dezentrale Bekämpfung der Eindringlinge. Es gibt also kein zentrales Organ, dem Informationen übermittelt werden müssen, um dann für die Abwehrelemente Weisungen zu erteilen. Die Entscheidung, daß eine Substanz bekämpft wird, findet vor Ort statt.

Um die Frage nach einem Computerimmunsystem zu klären, benötigt man an erster Stelle eine Definition zur Unterscheidung von computereigenen und computerfremden Prozessen. Des weiteren müssen Methoden ersonnen werden, die das Aufspüren und Eliminieren gefährlicher, fremder Aktivität ermöglicht. Außerdem bedarf es einer Speicherung von früheren Virentypenmustern, einer Methode zum Erkennen neuer Infektionen und einer Methode zum Schutz gegen Autoimmunreaktionen. (Dieser Fall träte beispielsweise ein, wenn das Immunsystem nicht erkennt, daß sich ein User mal von einem andern Platz als seinem üblichen sich Zugang zum System verschafft.)

Die Unterscheidung zwischen computereigenen und computerfremden Prozessen muß einige legitime Änderungen des System berücksichtigen: Es muß gestattet sein, Dateien zu schreiben, neue Software zu integrieren, neue Anwender und Änderungen des Anwenderverhaltens zuzulassen. Gleichzeitig soll dieses Immunsystem aber unautorisiertes Ändern von Daten, virenbehaftete Software, unautorisierte Benutzer und Angriffe von Anwendern aus dem Systeminneren erkennen.

Derzeit formieren sich um diesen Themenkreis eine Reihe von speziellen Konferenzen, die sich mit dem Thema „Intrusion detection" (Erkennen von Systemeinbrüchen bzw. Systemanomalien) im Rahmen der Computer- und Netzwerksicherheit auseinandersetzen. Eine exakte Beschreibung der hierbei verwendeten und durchaus nicht trivialen Algorithmen würde den Rahmen diese Artikels sprengen. Besonders aussichtsreich erscheinen uns hier die Ergebnisse zur „distributed change detection" und „hidden markov chain"-Analyse der Computerimmunologie-Forschungsgruppe um Professor Stephanie Forrest an der University of New Mexiko.

Die Forschung auf diesem Gebiet ist bereits den Kinderschuhen entwachsen und wird üblicherweise als „Spielart" des Artificial Life betrachtet. Da Artificial Life jedoch eher mit einer „Wissenschaft der bunten Bilder mit häufig zweifelhafter Aussagefähigkeit" assoziiert wird, fristete die Computerimmunologie bisher ein Mauerblümchendasein. Man kann im wesentlichen zwei verschiedene Forschungsrichtungen beobachten. So betreibt Stephanie Forrest eher Grundlagenforschung und schaut sich an, wie weit man die Analogie zwischen einem menschlichen Immunsystem und einem Computerimmunsystem überhaupt ziehen kann. In dieser Gruppe arbeiten nicht nur Computerhacker und Sicherheitsexperten, sondern auch Mediziner, die eigentlich nur Computersimulationen von Immunsystemen implementieren wollten; denn was wir bisher verschwiegen haben, ist die relativ unbekannte Tatsache, das die Gesamtwirkungsweise unseres Immunsystems weitgehend unerforscht, um nicht zu sagen: noch völlig im Dunkeln liegt. Dennoch ist man bereits in der Lage, kommerziellen Nutzen aus dem rudimentären Wissen zu ziehen.

Institutionen wie das Virus-Forschungszentrum der IBM besitzen daher ein Hauptaugenmerk auf die praktische Umsetzung. Dort schaut man sich an, wie Wissen über das menschliche Immunsystem möglichst schnell auf die PC-Computerwelt übertragen werden kann. IBM kooperiert übrigens auf dem Gebiet der Virenbekämpfung eng mit Intel und Symantec, unterstützt aber auch das oben angesprochene Grundlagenforschungsprogramm. 

Natürlich kann man Teile eines Autoimmunsystems für Rechnernetzte im Quellcode auf diversen Servern des Internets finden, so zum Beispiel die GNU cfengine, die an der Universität von Oslo entwickelt wurde, und das Thema aus der Sicht der Netzwerksystemadministratorensicht betrachtet. So unterscheidet cfengine computereigene von computerfremden Prozessen anhand vorkonfigurierter Templates-Tripwire von Professor Gene Spafford, der vor allem durch seine brillante Analyse des Morris-Internetwurms von 1987 bekannt wurde. Spafford war übrigens auch einer der ersten, der wissenschaftliche Aufsätze über Computerviren in Proceedings der damals eben erst von Chris Langton am renommierten Santa Fe Institute initiierten Wissenschaft des Artificial Life veröffentlichte. Inzwischen besitzt Spafford einen eigenen Lehrstuhl für Computersicherheit an der Purdue University. Ein anderes Beispiel ist COPS von Dan Farmer, einem Stundenten Gene Spaffords und Coautor von SATAN, dem wohl bekanntesten Internet-Security-Scanner-Tool, welches samt Netscape-basiertem HTML-Frontend bereits 1994 erhältlich war.

Die Notwendigkeit einer Änderung der herkömmlichen Antivirenbekämpfung ist einer der Gründe, warum das Security Lab der UUNET Forschungs- und Entwicklungsabteilung die Entwicklung auf diesem Sektor aktiv begleitet. Sichere private und öffentliche Netzwerke sind bereits heute gern gefragte Kundenprojekte, die durch das Internet Solution Center von UUNET abgewickelt werden. Hier sind insbesondere die Firewallinstallationen zu nennen, die immer häufiger auch eine „Viruswall"-Komponente beinhalten. Um die biologische Analogie noch einmal zu bemühen, wird hier dem Netzwerk eines Kunden eine Schutzhaut, sprich: Firewall übergezogen, deren Schutzmechanismus wiederum mit aktiven Komponenten (die man als Lymphknoten bezeichnen könnte) verstärkt wird, indem zum Beispiel Emails vor der Auslieferung in die Inbox eines Nutzers auf Viren überprüft und ggf. gesäubert sowie HTTP-Anfragen nach malitiösen ActiveX-Controls durchsucht werden.

Mit der Einführung der Anti-Virensoftware, die Anlehnung an die Funktionsweise des biologische Immunsystems nimmt, ist das Ende der herkömmlichen Anti-Virenprogramme eingeläutet, nicht jedoch der Verbreitung von Computerviren an sich. Bereits im nächsten Jahr soll die zweite Version der Software von Symantec erhältlich sein; und in Zukunft planen die Hersteller, in Abständen von 18 Monaten neue Versionen einzuführen. Man muß kein Hellseher sein, um der gesamten Branche exzellente Wachstumsaussichten zu prophezeihen.

Copyright (c) 1999 Jörg Heitkötter und Gerhard Weinreich. Alle Rechte vorbehalten.

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)

 
EXECUTIVE SUMMRAY

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 (agilealliance.org) formed in 2001 to promote IID, i.e. evolutionary strategies over the single-pass document driven waterfall model of “requirements, design, implementation” [8].

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

1. INTRODUCTION

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

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

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 comp.ai.genetic 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].

4. CONCLUSION

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.

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

6. ACKNOWLEDGMENTS

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


8. REFERENCES

[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. http://www.infoq.com/presentations/design-strategic-ericevans

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

[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.
http://code.google.com/p/hhg2ec/

[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, pp47-56 in IEEE Computer. http://www.highproductivity.org/r6047.pdf

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

hhg2ec-The Guide on a stick...?

I did it. Just finished the first draft version 0.1 of hhg2ec on a stick, using the DokuWiki on a stick framework in conjunction with Html2DokuWiki conversion tool. It is now checked in at Google code http://code.google.com/p/hhg2ec/ and you can use Mercurial to check it out: hg clone https://hhg2ec.googlecode.com/hg/ hhg2ec

2016 update: After closure of Google code in 2015, the guide moved to GitHub. Check it out at http://github.com/jheitkoetter/hhg2ec/

Enjoy! Have fun, -joke