Zielgruppen für Softwaretools

Hersteller von Produkten und insbesondere diejenigen die dafür werben, denken in Zielgruppen. So ist es offensichtlich, daß der typische Leser der ADAC Motorwelt sich für Treppenlifte interessiert. Werbung im Fernsehen muß hingegen die 19- bis 49-jährigen ansprechen, die die Zeit für Medien heutzutage eher im Internet verbringen. Genauso wird kommerzielle Software auch für bestimmte Zielgruppen entwickelt und angepriesen.

Entwickler sind ein zu vermeidendes Übel

Manager mit dieser Einstellung sind immer schon ein beliebtes Ziel von Toolherstellern. Bereits vor 20 Jahren wurden CASE-Tools mit dem Anspruch vertrieben, daß die Fachleute für die Geschäftsprozesse diese direkt eingeben könnten, ohne das ein "Entwickler" von Nöten sei. Bei diesen Tools meine ich immer zu merken, daß das Hauptziel bei der Konzeption war, es dem Vertriebsmitarbeiter zu ermöglichen, innerhalb einer halben Stunde eine Adreßverwaltung zusammenzuklicken, so daß die Manager, den dies vorgeführt wird, den Eindruck haben, sie könnten das auch.

Leider sind all diese Tools nicht annähernd so allgemein einsetzbar, wie die Phantasie der Nutzer potentieller Anwendungen reicht. Sobald aber etwas gefordert wird, daß die Toolentwickler noch nicht berücksichtigt haben, so sind komplizierte und schlecht wartbare Hacks an der Tagesordnung, die die vorgesehene Funktionsweise des Tools umgehen und die erst die vom Kunden gewünschte Funktionalität möglich machen.

Häufig sind derartige Tools auch schlecht in den Entwicklungsprozeß einzubinden. Wiederkehrende Aufgaben lassen sich nicht automatisieren, die Ergebnisse lassen sich schlecht in ein Konfigurationsmanagementsystem speichern und automatisierte Modultests sind auch nicht vorgesehen.

Die Behauptung, daß Programmierung nicht notwendig sei, erweist sich als Taschenspielertrick. Statt in einer Textdatei mit einem in einer Programmiersprache geschriebenen Programm ist dieselbe Information in einer Vielzahl von Menüs verstreut, so daß man rasch die Übersicht verliert, wo man was angepaßt hat. Das kann man schon ausprobieren, wenn man rasch mal eine "einfache" Access-Anwendung zusammenklickt.

Turings Fluch

Eine Programmiersprache nennt sich Turing-vollständig, wenn man damit alle denkbaren Programmieraufgaben lösen kann. Dazu braucht es nicht viel: Logische Verzweigung und Schleife reichen im Prinzip schon. Es gibt daher nur wenige Beispiele für Sprachen, die nicht Turing-vollständig sind. Egal, welches Werkzeug verwendet wird, als Entwickler kann man seinem Manager selten mit gutem Gewissen sagen, daß etwas damit nicht möglich ist. Man kann Texteditoren mit der C++-Template-Sprache schreiben, Datenbanksysteme mit Excel-VBA und Schachprogramme mit XSLT. Diese Sprache sind natürlich alle für etwas anderes gedacht und am Ende werden die Programme weder wartbar noch effizient sein, aber prinzipiell möglich sind sie doch.

Manchmal geht die Sache auch schleichend. BPEL ist dazu gedacht, Webservices zu einem Geschäftsprozeß zusammenzufassen, nicht dazu komplexe Algorithmen zu implementieren. Aber wenn man erst einmal eine Schleife und eine Verzweigung eingebaut hat, so gibt es kein klares Haltesignal, bis man doch den Algorithmus zusammengebastelt hat. Das Ergebnis ist dann sehr unübersichtlich, aber es ist da und läuft und es Bedarf einer mutigen Entscheidung, die Anwendung so umzubauen, daß dieser Algorithmus in einer geeigneteren Sprachen neu implementiert wird und das BPEL-Programm wieder wartbar wird.

Marketing-Nebel

Manchmal werden an sich nützliche Dinge durch das Marketing so verzerrt, daß sie nur noch für das sehr geübte Augen zu erkennen sind. Ein Beispiel ist das bereits letztes Mal erwähnte LINQ von Microsoft. Microsoft hat eine lange Geschichte von vergeblichen Ansätzen, einen eigenen O/R-Mapper herzustellen. Über Risiken und Nebenwirkungen solcher Tools könnte ich gelegentlich mal einen eigenen Beitrag schreiben, aber bei der Java-Konkurrenz haben sich diese Tools spätestens seit Hibernate etabliert. Also wurde LINQ als die ultimative Lösung für die Datenbankeinbindung in C#-Programme verkauft. Realisiert ist das ganze in einem Mix aus Spracherweiterungen und Bibliotheken. Ob der ursprüngliche Zweck wirklich viele überzeugt, wird die Zeit zeigen. Tatsache ist, daß einige nützliche Dinge dabei entstanden sind. Das attraktivste ist wohl die sogenannte "List-Comprehension". Diese ist bei Haskell- und Python-Programmierern seit langem bekannt und beliebt. Hier wurde aber eine Syntax gewählt, die vor allem Datenbankentwickler ansprechen soll, da sie an SQL angelehnt ist. Zum einen paßt diese Syntax recht schlecht in die übrige von C#, das doch eher von dem mathematisch knappen Stil von C beeinflußt ist als von dem an der natürlichen Sprache angelehnten von SQL. Zum anderen werden viele Entwickler übersehen, welche Möglichkeit hier versteckt sind.

Alternative Zielgruppe

Wahrscheinlich würde einiges besser, wenn die Entscheidungen für Softwaretools mehr von denjenigen gemacht würden, die sie auch benutzen müssen. Dies müßte dann aber auch zu den Anbietern durchdringen. Derzeit sieht es so aus, daß ein großer Teil der kommerziellen Softwaretools mit Blick auf Manager als Entscheidungsträger hin entwickelt und vertrieben werden. Besser sieht es manchmal bei Open Source Programmen aus, auch wenn hier immer mehr einen kommerziellen Hintergrund haben, der zu den gleichen Auswüchsen führt.