Warum Software grundsätzlich anders ist und daher agile Methoden braucht

Wir streben danach die Welt zu beschreiben. Über Jahrhunderte war eine bessere, eine realistischere, eine "richtigere" Beschreibung der Welt das Maß aller Dinge. Meilensteine wie Alexander von Humboldts "Kosmos – Entwurf einer physischen Weltbeschreibung" säumen diesen Weg. Die Beschreibung der physischen Welt hat jedoch Grenzen.

Lewis Carroll zeigt dies mit einem absurden Beispiel in “Sylvie and Bruno Concluded”:

“What do you consider the largest map that would be really useful?”
“About six inches to the mile.”
“Only six inches!” exclaimed Mein Herr. “We very soon got to six yards to the mile. Then we tried a hundred yards to the mile. And then came the grandest idea of all! We actually made a map of the country on the scale of a mile to the mile!”
“Have you used it much?” I enquired.
“It has never been spread out, yet,” said Mein Herr: “the farmers objected: they said it would cover the whole country and shut out the sunlight! So we now use the country itself, as its own map, and I assure you it does nearly as well.”

Auch Software, gerade Individualsoftware, hat die Aufgabe ein Stück Realität, eine Stück physische Welt abzubilden. Dabei stellen sich wichtige Fragen, jenseits der Verwechslung von Landkarte und Territorium. Was bildet man ab? Was lässt man weg? Gemeint sind hier nicht allein Entitäten oder Objekte, sondern gerade auch deren Eigenschaften, das Verhalten, die Möglichkeiten mit diesen zu interagieren. Sollte es nicht der Anspruch sein, die Realität so gut wie möglich abzubilden?

Die Ansicht, dass eine möglichst genaue Abbildung der Realität kein guter Weg ist, hat sich über die Jahre in der Softwareentwicklung durchgesetzt und wurde bereits vor Jahren beispielsweise in Domain Driven Design von Eric Evans festgehalten. Trotzdem stolpert man in Projekten immer wieder über Probleme, die auf fehlendes Verständnis des Unterschieds zwischen realen, d.h. physischen Dingen und ihren digitalen Abbildungen und Entsprechungen zu tun haben. Was macht Objekte der digitalen Welt, Medien, Software nun grundsätzlich aus, warum ist Software grundsätzlich anders?

Jaron Lanier schreibt dazu "What Makes Something Real Is That It Is Impossible To Represent It To Completion"

Reale Dinge sind also unmöglich vollständig repräsentierbar. Eine Software selbst ist vollständig, als Repräsentation der Realität wird ihr jedoch immer etwas fehlen (eine Eigenschaft, ein bestimmtes Verhalten). Daran ist nichts Schlechtes oder Falsches. Es charakterisiert Software einfach. Beispielsweise kann etwas so normales und alltägliches wie Geruch und der Geruchssinn des Menschen nicht in Software abgebildet werden. Software oder ein Objekt in einer Software hat also keinen Geruch als Eigenschaft. Dies wird so auch von jedem akzeptiert. Schwierig sind jedoch die Fälle, die Eigenschaften, die in einer Software möglich, jedoch nicht vorhanden sind, da sie nicht implementiert wurden. Oder Fälle in denen die Software sich anders verhält als man erwartet, da ein anderer Mensch mit anderen Erwartungen dieses Verhalten implementiert hat. Da es in Software keine physikalischen Einheiten, wie Gewicht oder Länge gibt, sind viele dieser Fälle nur schwierig objektiv zu entscheiden. Man kann daher vortrefflich darüber diskutieren, ob eine bestimmte Eigenschaft einer Software nun zu erwarten ist oder nicht. Genau dies ist der Grund für die Schwierigkeiten, die Spezifikationen von Software mit sich bringen. Schon in der Spezifikation wird immer etwas Wichtiges fehlen, denn wie sollte diese vollständig sein, wenn nicht einmal die Software, die sie beschreiben soll, dies sein kann. Eine Software beschreibt sich daher am besten durch sich selbst. Die Eigenschaften einer Software lassen sich in ihr, also im Quellcode nachlesen, mit technischen Experimenten (z.B. Software-Tests) überprüfen oder durch Interaktion mit der Software durch einen Nutzer erfahren.

Genau diese Einsichten stehen hinter und stecken in agilen Methoden der Softwareentwicklung. Statt eine unumgänglich unvollständige Spezifikation zu schreiben (und diese dann umsetzen zu wollen), wird Wert darauf gelegt funktionierende Software zu entwickeln und die Eigenschaften dieser Software laufend von Menschen auf ihre Tauglichkeit für den zugedachten Zweck zu prüfen.

Deshalb setzen wir auf agile Softwareentwicklung.

Zur Blog-Übersicht