Was passiert, wenn ein Techniker die Verantwortung fuer ein Softwareprojekt erhält? Er laesst eine technisch perfekte, frei konfigurierbare Lösung entstehen.
Was kann daran schon schlimm sein?
Zuerst einmal: Es muss nichts daran schlimm sein. In einem gut Teil der Fälle ist aber doch etwas nicht richtig gelaufen: Das Produkt ist zu flexibel. Die ganze Flexibilität zaubert so viel Rauschen auf den Bildschirm, dass ein Anwender kaum mehr die wirklich wichtige Funktionalitaet findet.
Man kann ueber MS denken was man will, aber sie haben das Problem erkannt und bieten einen generischen Ansatz: In den Menüs werden erst einmal nur die am häufigsten benutzten Punkte angezeigt, erst nach einer Verzögerung klappt sich das Menü voll auf. Das löst nicht das Problem, mindert aber die Sympthome erheblich.
Warum geben sich Techniker keine Mühe, die Oberflaechen ihrer Software einfach zu gestalten? Besonders ist mir das bei Open-Source aufgefallen, offenbar fehlt dort der Kunde, der sagt: "Versteh ich nicht, machen Sie das mal einfacher."
Wieviel Zeit geht bei der Benutzung dieser hochflexiblen (kaum mehr bedienbaren) Programme eigentlich verloren? Könnte es sein, dass diese Zeit ein Vielfaches dessen ist, was man durch eine Umkonfiguration spart? Wie oft werden Konfigurationen denn wirklich geändert?
Da braucht man nur mal die Testgenerierung von Eclipse mit JUnitDoclet vergleichen. Bei Eclipse gibt es einen Dialog mit zig Optionen, daraus resultiert eine Menge Klicks und immer die Chance, irgend eine Einstellung vergessen zu haben. JUnitDoclet macht auf ein einziges Kommando einfach los, es hat ein Template und alles was nicht passt, wird später nicht compilieren. Nur über diese Sonderfälle muss der Programmierer nachdenken. Auch JUnitDoclet ist genau so flexibel konfigurierbar, aber es protzt nicht damit rum.
Und wenn die Konfigurierbarkeit einer Java-Anwendung so weit geht, dass man eigentlich nur noch XML-Dateien editieren muss, wenn Klassennamen in den XML-Dateien stehen und die Instanzen mit Class.forName(nameAusDerXmlDatei).newInstance() angelegt werden, dann hat man schlechte Eigenschaften zweier Ansätze kombiniert: Die statischen Typprüfungen sind ausgehebelt, man ist aber nicht so flexibel wie z.B. in Python mit seiner dynamischen Typprüfung. Man plagt sich mit Java, kann aber "leider" die Vorteile nicht nutzen. Das ist nicht pragmatisch!
Ich plädiere nun wirklich nicht gegen Konfigurierbarkeit, aber wie bei Medizin kann es auch ein Zuviel davon geben. Dessen sollte man sich bewusst sein, wenn man Konfigurierbarkeit einbaut. Leider ist Bedienbarkeit kein so gutes Verkaufsargument wie eine meterlange Liste an Features und der möglichst massive Einsatz von XML.
