Der Fluch der Abstraktion
Mittwoch, April 14th, 2010Ich gebe zu, ich bin ein Fan von Techniken zur Komplexitätsbeherrschung. Das liegt wohl auch daran, dass ich sehr viel mit sehr komplexen Systemen zu tun habe und ständig auf der Suche bin, wie diese zu steuern sind. Allerdings fällt mir auch immer wieder auf, dass diese Techniken so ins Extreme verzerrt werden, dass sie genau das Gegenteil bewirken: einen starken Anstieg der Komplexität in jeder Beziehung.
Im Informatikstudium bekommt man Abstraktion beigebracht. Man lernt, große Dinge in seine Bestandteile aufzulösen und dann einzeln anzugehen. Das beginnt mit Trivialem wie Quicksort und endet bei der Model Driven Architecture. Und das ist auch gut so. Die Abstraktion ist ganz klar eines der wichtigsten Werkzeuge der modernen Informatik und der modernen Systementwicklung. Was einem allerdings nicht beigebracht wird, ist Maß damit zu halten.
Im Seminarraum meiner damaligen Arbeitsgruppe hing ein handgeschriebenes und ausgeblichenes Schild. Auf dem Stand “Fünf Stunden Perl programmieren ersetzt eine Stunde Nachdenken”. Was zunächst wie die scherzhafte Kritik an einer Programmiersprache aussieht ist bei genauerem Hinsehen viel mehr: es ist die Kritik an einer Verselbstständigung der Abstraktion. Und genau da liegt eine große Schwäche bei vielen Leuten, die eine systematische Ausbildung der Informatik hinter sich haben: die Technologie verkommt zum Selbstzweck. Wer hat nicht schon einmal Quellcode gesehen, der sich in endlosen Klassenhierarchien vererbt oder Datenmodelle, die jedes ach so kleine Datenpäckchen noch externalisieren und ein an sich einfache fachliche Probleme zu Datenmodellen mit dutzenden Entitäten aufblähen?
Fragt man dann nach, warum die Modelle denn so sind wie sie sind, bekommt man meistens “Erweiterbarkeit” an den Kopf geworfen. Oder “Änderbarkeit”. Oder “Vereinfachung”. Spätestens hier wird dann aber auch schon durch das reine Nachfragen selbst dem abstraktesten Architekten klar, dass etwas schief läuft. Diese “Verkomplizierung im Namen der Vereinfachung” oder auch “spekulative Verallgemeinerung” ist eine sehr verbreitete Krankheit in vielen vielen Softwaresystemen. Sie führt zu sehr schwer zu wartenden Quellcodes und deutlichen Mehrkosten bei jeder Art von Veränderung und Erweiterung. Damit erreicht sie dann genau das Gegenteil von dem, was eigentlich beabsichtigt war – und das ist das Tragische daran.
Allerdings befällt dieses Problem nicht nur Software an sich, sondern auch IT-Standards oder auch Entwicklungsprozesse. Dieses “Overengineering” kann man beispielsweise sehr gut bei den WS-*-Standards wie SOAP, WSDL oder auch BPEL beobachten. WSDL ist da ein sehr gutes Beispiel: prinzipiell lässt sich damit jede Art von Schnittstelle auf Basis jeder Art von Technologie beschreiben. Aber wird das auch eingesetzt? Mir ist es nicht gelungen auch nur einen einzigen Fall zu finden, in dem WSDL nicht zur Beschreibung von SOAP-Web-Services auf Basis von HTTP oder SMTP zum Einsatz kam. Die beim Design von WSDL berücksichtigte Unabhängigkeit von jeder Art von Dritttechnologie wird überhaupt nicht genutzt! Allerdings hat sie WSDL sehr viel komplexer gemacht und damit schwerer einzusetzen und damit im Endeffekt teuerer. Dass man bei einer so innovativen Technologie wie Web-Services damit quasi das gesamte Konzept auf die Kippe stellt nur weil man die “ultimativ allgemeine” Lösung finden möchte ist ein Nebeneffekt. Und dass dieser tatsächlich zuschlagen und einen gesamten Standard ins Abseits katapultieren kann, ist am Besipiel von UDDI sehr schön zu beobachten.
Aus meiner Sicht ist ein guter Entwickler und ein guter Architekt nicht nur jemand, der Abstrahieren kann, sondern auch jemand, der die Grenzen der Abstraktion erkennt. Er muss in der Lage sein, fachliche Bedürfnisse gegenüber technischen Möglichkeiten abzuwägen und die “richtige” Lösung zu finden – nicht die technisch perfekteste, sondern die technisch und fachlich eleganteste. Einfach die Lösung, die KISS ist.
Warum heißt die größte Kaffeegröße bei 
