Software-Entwicklung: Evolution ist Mutation und Selektion.

Was hat Software-Entwicklung mit der Evolution zu tun?

Heute habe ich mit meinen Söhnen das großartige Museum für Naturkunde in Berlin besucht. Zwei Stunden haben wir an einer Führung durch das Haus teilgenommen und dabei von den größten erhaltenen Dinosaurierskeletten, wie den Brachiosaurus oder T.Rex, bis hin zu den in 250.000 Gläsern konservierten Arten eine umfangreiche Sammlung von Exponaten und Studienobjekten erlebt. Es war sehr beeindruckend. In jedem Fall war es einen Besuch wert.

Der rote Faden, der sich durch die Führung spann, war das Thema Evolution, die uns die wissenschaftliche Mitarbeiterin in immer neuen Beispielen sehr anschaulich und in einfachen Worten nahe brachte: Evolution ist Mutation und Selektion. Evolution ist ein stetiger und kontinuierlicher Prozeß. Mutation erzeugt stetig neue Varianten des Bestehenden. Kein Individuum gleicht völlig dem anderen. Selektion wählt aus diesen Mutationen die jeweiligen an ihre Lebensbedingungen am besten angepassten Individuen aus, die wiederum Nachkommen erzeugen und damit ihre Gene weitergeben, während die weniger gut angepassten Individuen weniger oder keine Nachkommen erzeugen und ihre Gene nicht gut weitervererben können.

Das erinnerte mich an ein Gespräch im Jahr 1981 mit Ken Thompson, der mit dem mittlerweile verstorbenen Dennis Ritchie, u.a. das UNIX-Betriebssystem erfunden und geschrieben hat. Beide arbeiteten damals bei den Bell Labs. Ken schrieb in seiner Freizeit Computer-Schach-Programme, wie ich damals auch, und sah mit seinem langen schwarzen Pferdeschwanz wie ein total cooler Hippie aus. Das Thema Schachprogrammierung war einer der Vorboten der Künstlichen Intelligenz zu der Zeit. Ich traf Ken in Travemünde bei einer der ersten Computer-Schach-Weltmeisterschaften. Wir haben uns den ganzen späten Abend über Softwareentwicklung unterhalten und er erzählte mir, mit welcher Taktik er vorging: Evolution.

Schachprogramme hatten damals eine Komponente, die Bewertungsfunktion genannt wurde. Die Bewertungsfunktion bewertete bestimmte Konstellationen und Stellungsmuster auf dem Schachbrett und diente der Gewichtung der verschiedenen Zugoptionen, vereinfacht gesagt. Das Fatale war dabei, dass die vielen Gewichte und deren Faktoren in der Funktion sich nicht berechnen ließen, sondern experimentell gefunden werden mussten. Kens Lösung dafür war verblüffend einfach.

Er ließ nach seiner täglichen bezahlten Arbeit, nachts auf den unbeschäftigten Rechnern des Bell Labs seine Schach-Programme mit jeweils unterschiedlichen Bewertungsfunktionen automatisch gegeneinander spielen. Am nächsten Morgen nahm er dann das Gewinnerprogramm, bildete aus seiner Bewertungsfunktion neue Mutationen und ließ diese Programme in der nächsten Nacht wieder gegeneinander spielen. Und so fort. Bis er eine gute Variante des Programms hatte. Smart und einfach. Eine echte evolutionäre Software-Entwicklung nach dem Prinzip „Evolution ist Mutation von Individuen und Selektion von erfolgreichen Individuen“.

Software-Entwicklung ist eine der komplexesten Aktivitäten im technologischen Bereich. Es ist eine Ingenieurs-Wissenschaft, die vorrangig aus der Erfahrung gespeist wird, und sich nicht wirklich mechanisch reproduzieren lässt. Es gibt einfach zu viele Faktoren, die dabei eine Rolle spielen. Das Ganze ist nicht wirklich berechenbar oder im Aufwand wirklich vorab kalkulierbar, was Auftraggeber nie hören wollen. Grobe Schätzungen sind das Maß der Dinge. Oder eben etwas willkürliche Deckelung von Budgets in Zeit und Geld. Es gibt im Laufe der Jahrzehnte im Software-Engineering unzählige Theorien, wie man es machen sollte, um ein gutes Ergebnis zu erzielen. Die Agile Softwareentwicklung ist aktuell in aller Munde.

Mich würde die Evolutionäre Softwareentwicklung interessieren. Natürlich sind die Rahmenbedingungen recht unterschiedlich zur vergleichsweise „simplen“ Schachprogrammierung. Es hätte aber seinen Reiz, darüber nachzudenken und Wege zu finden…

Für mich sind Agile Softwareentwicklung, Continuous Beta (oder auch Perpetual Beta) und Minimum Viable Product (MVP) in der Herangehensweise an eine gute Lösung nur Vorstufen einer Evolutionären Softwareentwicklung. Ließen sich diese Verfahren weiter verbessern, professionalisieren, automatisieren und vereinheitlichen? Können wir Software schreiben, die eigenständig lernt, sich ständig zu verbessern?

Ich glaube, das ist keine Utopie. Schließlich sind aus Mikroben Menschen entstanden. Nicht am Reißbrett von Ingenieuren, sondern in der Natur durch die Evolution.

RapidRabb.it startet heute neuen Prototyping Service im Web

Silvan T. Golega (Xing), Webentwickler, fleissiger BarCamper und Teilnehmer beim legendären ersten Startup Weekend, hat mit drei weiteren Freunden heute offiziell RapidRabb.it gestartet. Die erste web-basierte Software-Suite zur Erstellung und Evaluierung von Softwareprototypen. Silvan schreibt mir:

Mit RapidRabb.it können interaktive Prototypen für Software-Benutzungsoberflächen erstellt werden. Per Drag’n’Drop können einfach Wireframes von Seiten und Dialogen erstellt und zu Prozessen verlinkt werden. Diese Prototypen können zum Testen der Interaktion und Usability eines Produktes verwendet werden, als Spezifikation dienen und zur späteren Implementierung weiterverwendet werden. Der Editor selbst läuft im Browser, damit mehrere Nutzer – ähnlich wie bei Mindmeister oder GoogleDocs – gleichzeitig an Prototypen arbeiten können oder in Reviews Feedback geben können.

Ein Video zu den grundlegenden Funktionen kann man sich auf dem Demo-Video anschauen. Unter der Vorschau kann jeder den Editor ausprobieren, nur können die erstellten Prototypen damit nicht gespeichert werden.

Der RapidRabb.it Prototype Creator wird nach dem sogenannten Software-as-a-Service-Modell vertrieben. Die Monatslizenz für einen Nutzer kann direkt auf der Website zu einem Preis von 30 Euro zzgl. Mwst. erworben werden.

Gute Ideen werden belohnt. RapidRabb.it hat schon in der Vorbreitung im Aufbau des Unternehmens aus Berlin zahlreiche Auszeichnungen und Preise gewonnen. Die vier Gründer sind Universitätsabsolventen des Hasso-Plattner-Instituts in Potsdam sowie der TU München.

PS: Silvans zweiter Vorname, heisst überigens Tecumseh, kurz @tec genannt. Nomen est omen. Ein guter Name für einen Gründer. Viel Erfolg, Tec!

Potenzial-Matrix von Social Software in Unternehmen

Björn Ühss hat seine Diplomarbeit in „Social Software in Unternehmen“ geschrieben. Ich hatte das Vergnügen, vor einiger Zeit im Rahmen seiner Recherche ein längeres Telefon-Interview zu geben und heute seine Arbeit gegenzulesen. Da die Diplomarbeit mit Unterstützung von IBM erstellt wurde, ist sie noch nicht öffentlich verfügbar, aber Björn hat schon eine kleine Kostprobe in seinem Blog veröffentlicht, die ich dankbar bei mir ebenfalls zeigen darf – Eine Potenzial-Matrix von Social Software in Unternehmen:

Eine Matrix, die viel Raum für Phantasien über zukünftige Einsatzmöglichkeiten von Social Software in Unternehmen zulässt. Eine hervorragende Arbeit, Björn.

Vergleiche dazu auch meine Ausführungen von neulich zu Microblogging, Blogs, Wikis, Foren, Chats – Die Unterschiede.

Corporate Inhouse Social Software

Gestern hat mich Björn Ühss aus Wien für seine Diplomarbeit bei IBM interviewt. Sein Thema lautet „Nutzen von Social Software für Unternehmen anhand Best Practices verglichen mit IBM“. Dabei haben wir auch über die Zukunft von Social Software in (grossen) Unternehmen gesprochen, der klassischen Klientel von IBM. Björn meinte völlig zu recht, die Einführung von Wikis, Blogs und anderen Social Tools in diesen Unternehmen sei wegen der mangelnden Akzeptanz (im Management) sehr schwierig. Von Twitter ganz zu schweigen.

Dabei kam mir folgender Gedanke. Ich glaube, der Weg mit dem geringsten Widerstand die neuen Corporate Social Services, so nenne ich sie mal, einzuführen ist, sie auf den vorhandenen Messaging Servern aufzusetzen und diese um „soziale Funktionen“ aufzubohren. Was heisst das?

Man nehme einen Mail/Messaging Server von einem der beiden Marktführer, IBM Notes oder Microsoft Exchange, und bohre sie auf zu Inhouse Social Network Plattformen. Die Server enthalten ja schon mal alle Nutzerprofile des Unternehmens, Diese gilt es nun um relevante weitere userbezogene Daten zu erweitern. Die Grunddaten dazu gibt es überall im Unternehmen, insbesondere in den Organisations- oder Personalabteilungen. Je nach System und Ausprägung können diese erweiterten Profile im Active Directory (AD) und/oder im LDAP abgelegt und automatisch mit den Quellensystemen ständig synchronisiert werden. Diese „angereicherten Profile“ bilden die „Knoten“ des internen sozialen Netzes, dass es nun zu weben gilt.

Die „berufsbedingten sozialen Beziehungen“ zwischen diesen Knoten ist der „Social Graph“, den diese Mailsysteme noch nicht haben. Diesen Graph gilt es als Add-on den Servern hinzuzufügen. Relativ simpel am praktischten eben auch im AD oder LDAP. Und schon hätte man ein „Corporate Inhouse Social Software“ basierend auf den schon vorhandenen Messaging Servern. Warum ist das interessant?

Die Organisationsstrukturen von Grossunternehmen (10.000+ IT-Arbeitsplätze) werden flacher, verteilter und dadurch de facto vernetzter. Sie wandeln sich immer mehr von hierarchisch starren Strukturen hin zu flexiblen serviceorientierten Gebilden. Die Linien lösen dadurch natürlich nicht vollständig auf, aber sie werden komplexer. Es ist für den einzelnen Mitarbeiter nun viel wichtiger, aufgabenbezoge Beziehungen im  Unternehmen zu knüpfen und zu pflegen. Einfache Adressbücher, auch hierarchisch gegliederte interne „Gelbe Seiten“, reichen da nicht mehr aus, um den Anforderungen gerecht zu werden.

Unternehmen werden i.d.R. nicht ihre sensitiven personenbezogenen Daten in externe webbasierte Services wie LinkedIn, Xing o.ä. herausgeben. Webbasierte Services, die mittlerweile Alltag in der Web 2.0 Welt sind und die wir alle privat und viele auch berufsbedingt nutzen. Vorallem Freiberufler und Selbstständige. Aber die haben andere Anforderungen als (grosse) Unternehmen.

Im Gegenzug macht es auch keinen Sinn, sogenannte „White Label“ Lösungen dieser öffentlichen webbasierten Plattformen zu verwenden. Solche Lösungen bedeuten deutlich mehr Entwicklungs-, Wartungs- und Pflegeaufwand für die Softwarehersteller, dessen Geschäft es ja gerade ist, einen einheitlichen Dienst im Internet allen anzubieten. Jede Version für einen Kunden würde eine eigenständige Aufmerksamkeit (Entwickler) bedeuten. Das ist meist nicht wirtschaftlich für die Anbieter.

Eigenständige Inhouseprodukte wie beispielsweise das wikibasierte SocialText bringen uns in dieser Grössenordnung auch nicht weiter. Meist ist es so dass IT Abteilungen die Einführung zusätzlicher technologischer Plattformen, die schwer mit der restlichen Infrastruktur zu integrieren sind, scheuen wie der Teufel das Weihwasser. Zu recht. Denn das bedeutet Mehraufwände im Betrieb, Sicherheitsrisiken, Bedenken in der Kette der Verfügbarkeiten und mehr.

Deswegen finde ich meinen Ansatz eigentlich am attraktivsten. Man nimmt, was man schon hat und kennt, was sich bewährt hat und bohrt es nur auf. Und man muss nicht über so abstrakte Begriffe wie „Neues Web“, „Web 2.0“ oder „Cool“ argumentieren. Der Bedarf ist da. Ich bin schon mehrfach in grossen Intranetvorhaben nach solchen praktikablen Lösungen gefragt worden. So etwas kann man auch als Add-on Produkt entwickeln und vertreiben.