Warum Lego nichts mit Softwareentwicklung zu tun hat [OOP 2009]

Laien Softwareentwicklung verständlich zu machen, ist nicht leicht. Helfen sollen dann Analogien. Beliebt ist die, Software mit einem Küchenrezept zu vergleichen. Doch nicht nur Laien haben ihre Schwierigkeit mit der Softwareentwicklung. Auch die Profis ringen immer wieder um Verständnis. So suchen auch die Profis nach Analogien. Beliebt ist bei ihnen die, Softwareentwicklung als Arbeit mit einem Lego-Bausatz zu sehen. Oder sie wünschen sich zumindest, dass es so wäre. Denn das Zusammensetzen von Lego-Bausteinen hat soviel mit Softwareentwicklung  zu tun wie Bambi mit einem Reh. Daran ändern auch wortreiche Beschwörungen wie die von James Noble auf InfoQ nichts.

Seine "Lego Hypothese" ist wieder einmal hübsch anzuhören - doch sie weist auch wieder in die falsche Richtung. Ich glaube, solange wir noch das Ziel haben, Softwareentwicklung wie ein Lego-Spiel werden zu lassen, solange stehen wir uns selbst im Weg zu einer einfacheren Softwareentwicklung. Genauso wie uns RPC à la .NET Remoting im Weg steht bei der Entwicklung paralleler und skalierbarer Software.

Was ist nun das Problem mit der Lego-Metapher?

Vom Offensichtlichen sehen wir einmal ab; Lego-Bausteine bieten keine Dienstleistungen, wie es Funktionseinheiten jeder Größenordnung - von der Methode bis zum SOA-Service - in einer Software tun. Lego-Bausteine sind also trivial.

Das Problem hat nicht mit der "Qualität" oder dem "Inhalt" von Lego-Bausteinen zu tun, sondern mit der "Lego-Form".

Problem 1: Feine Granularität

Da ist zum einen die uniforme Größe der Lego-Bausteine. Sie variiert zwar in gewissen Grenzen, aber in Bezug auf das, was aus ihnen am Ende gebaut wird, sind sie im Grunde alle gleich groß. Oder eben gleich klein. Lego bietet nur eine Granularität für den Bau. Ob es ein kleines Auto oder der Nachbau einer Kathedrale ist, alles wird aus kleinsten Teilen zusammengesetzt. "Container", um größere Teile unabhängig von einander zu bauen und später zusammenzusetzen, gibt es nicht. Lego kennt keine Abstraktionen.

Das ist keine Kritik an Lego. Der Erfolg von Lego ist von Abstraktionsmitteln unabhängig und ganz unbestritten. Lego soll nichts an seiner Ideen und seinen Produkten ändern. Nur sollten wir angesichts dieser Simplizität oder gar Trivialität des "System Lego" aufhören, darin einen Wegweiser für die Softwareentwicklung zu sehen. Lego kann uns viel lehren, zum Beispiel die Eleganz der Einfachheit oder den Nutzen von Standards. Aber in Lego steckt keine Botschaft zur Strukturierung komplexer, ständig in Veränderung begriffener Systeme. Die können wir nämlich nur planen, wenn wir sie auf unterschiedlichen Abstraktionsebene denken können, und bauen, wenn wir Bausteine ganz unterschiedlicher Granularität haben.

Lego-Bausteine sehen so aus, wie sie aussehen, eben weil sie keine vielfältigen Dienstleistungen bieten, sondern immer wieder nur Festigkeit in konstanter Form. Das war´s. Software jedoch ist anders, ganz anders. Und so ist es eine Illusion anzunehmen, vielfältige Softwaredienstleistungen ließen sich zusammenstecken wie triviale Lego-Bausteine.

Problem 2: Direkte Verbindungen

Lego-Bausteine sind "tot". Software hingegen "lebt". Nicht nur sind Software-"Bausteine" ständig in Aktion, Software insgesamt ist auch beständig im Wandel. Das bedeutet:

• Die Zahl der "Bausteine" in einem System ändert sich ständig.
• Die Zahl der Beziehungen zwischen den "Bausteinen" in einer Software ändert sich ständig.

Software als System von Funktionseinheiten mit vielfältigen Beziehungen ist kontinuierlich im Wandel begriffen. Sie unterliegt dauernder Umkonfiguration im Kleinen und im Großen. Das liegt in der Natur ihres Zwecks, der Lösung komplexer Aufgabenstellungen. Und das ist natürlich auch der schlichten Möglichkeit geschuldet, Immaterielles wie Software so flexibel "kneten" zu können.

Lego-Bausteine hingegen werden im Zuge einer "Baumaßnahme" einmal aufeinander gesetzt und bleiben dann so. Weder verändern sich die Bausteine, noch verändert sich die Statik des großen Ganzen.

Deshalb ist es ausreichend, dass Lego-Bausteine direkt miteinander verbunden werden. Wir stecken sie unmittelbar aufeinander. Für die mit ihnen zu bauenden "Systeme" ist das genug.

Komplexeres jedoch, das wird seit jeher anders zusammengesetzt. Wo echte Dienstleistungseinheiten - im Gegensatz zu Stabilitätseinheiten - größeres bilden sollen, da sind die nicht direkt verbunden wie Lego-Bausteine. Echte Dienstleistungen stehen immer indirekt in Beziehung. Zwischen ihnen ist immer ein "Beziehungsvermittler", etwas Drittes, das sie zusammenbringt und -hält.

Stecker und Buchse, Schrauben, Nägel, Bolzen, Klemmen... es gibt viele Arten, Zusammenhalt herzustellen. Manchmal sind sie ganz einfach wie ein Holzzapfen, manchmal komplex wie ein Router. Aber immer ist ihre vornehmste Aufgabe zu verbinden. Nicht mehr, nicht weniger.

Ganz grundsätzlich unterscheiden wir in komplexen Systemen also zwischen den eigentlichen (Teil)Dienstleistungen und ihren Verbindungen. Wir koppeln Funktionseinheiten explizit und damit indirekt. Lego hingegen koppelt implizit und direkt.

Diese direkten Verbindungen zwischen Lego-Bausteinen sind für mich das k.o. der Lego-Analogie. Wannimmer wir sie beschwören, suggerieren wir mehr oder weniger subtil, dass direkte, implizite Verbindungen zwischen Funktionseinheiten genügen würden, um komplexe Softwaresysteme zu bauen. Das ist weitreichend kontraproduktiv. Solche Suggestionen vergiften das Nachdenken über Software und erzeugen früher oder besser Schmerzen. Denn wo direkt und implizit verbunden wird, da ist das Resultat starr. Und das bedeutet, Veränderungen sind schwierig; sie erzeugen Schmerzen, weil sie immer wieder die inhärente Starrheit überwinden müssen.

Eine bessere Analogie

Wenn Bauteile, Baugruppen, Module, Subsysteme von komplexen Systemen immer indirekt verbunden sind, um sie effizient fertigen, separat prüfen und flexibel zusammenbauen zu können, dann sollten wir unsere Analogien danach wählen, wenn wir welche brauchen. Statt uns immer wieder nach einer Lego-Softwarewelt zu sehnen, sollten wir eher nach Stabilbaukästen oder Elektronikbaukästen schielen.

Wenn schon eine spielerische Analogie, wenn schon Bausatz, dann so. Sie führen vor, wie aus kleinen Teilen größere werden durch indirekte Verbindungen.

Software ICs sind eine tauglichere Zielvorstellung als Software Lego-Bausteine.

Natürlich sollten wir dann auch danach in der Softwareentwicklung handeln. Die passend gewählte Analogie sollte uns etwas sagen; sie sollte rückwirken auf uns. Wir sollten definieren, was für uns explizite und indirekte Verbindungen sind. Denn Verbindungen haben wir viele und in vielerlei Ausprägungen:

• synchron/asynchron
• lokal/verteilt
• single-/cross-platform

Nicht, dass es dazu noch keine Ideen gäbe. DI, WCF, REST, ESB sind einige Akronyme in diesem Zusammenhang.

Doch ich glaube, dass uns noch ein echter Konsenz darüber fehlt, wann wir wie Software-Bausteine zusammenfügen. Ganz davon zu schweigen, was denn die Software-Bausteine sind, die dann so verbunden werden. Reichen Objekte und SOA-Services? Nein, ich denke, sie sind nur der Anfang.

Objektorientierung allein bewegt sich tatsächlich auf der Lego-Ebene. SOA-Services hingegen sind sehr große Bausteine, die vor allem asynchron, verteilt und cross-platform verbunden sind. Dazwischen liegt aber  noch ein weites Feld, dessen sich zumindest der Hype nicht bewusst ist. Das müssen wir beackern. Nur dann kommen wir raus aus dem Hypothesenstadium und hinein in echte, skalierbare Software-Bausteinpraxis.