empros gmbh - process & information management services
1009-chat Simplicity is the most difficult thing to secure in this world; it is the last limit of experience and the last effort of genius.

- George Sand

Komponententraum(a)

von Sascha Frick (November 03)
Objekte sind tot – es leben die Komponenten! Jetzt geht das Bauen von echter Software endlich flott über die Bühne. Ein Ewiggestriger, wer seine Anwendung mittels Quelltexteditor erstellt und sich vorab sogar eine Architektur bereit gelegt hat.

Zeigefinger aufgepasst: Klicken ist angesagt. So entsteht im Handumdrehen und nach ein paar hundert zurückgelegten Metern mit der – hoffentlich state of the art optical – Maus eine komplexe Anwendung, die sogar irgendwie funktioniert; Programming by Coincidence in neuem Gewand.

Geht es nach den Marketingleuten und den glaubenshungrigen Managern, dann brauchen Programmierer künftig vor allem dies: eine kurvengängige Maus und Komponenten, viele, viele Komponenten. Denn in dieser tapferen neuen Welt spielen Komponenten als wieder verwendbare Softwarebausteine eine zentrale Rolle. Einfach zu verwenden sollen sie sein, diese Komponenten, parametrierbar und flexibel noch dazu. Richtig hübsche schwarze Kästchen, deren Innenleben uns nicht interessieren muss. Ein tolles technisches Meisterstück mit einer klaren und einfachen Verwendungsschnittstelle ist so eine Komponente, selbstdokumentierend, fast beliebig austauschbar und skalierbar. Überhaupt hat eine solche Komponente lauter wunderbare Eigenschaften.

Ach, wäre doch nur die Hälfte wahr! Komponenten sind ja eine grossartige Idee, doch zwischen den vollmundigen Versprechungen der Werber und der tatsächlichen Komponentenwelt klafft ein grosser und tiefer Spalt. Denn für die meisten Komponenten gilt:
  • Sie sind schwierig zu verwenden 
  • schlecht dokumentiert 
  • entweder zu mächtig oder zu funktionsarm 
  • ihre Schnittstellen sind zu gross und widersprüchlich 
  • ihre Implementierung ist fehlerhaft und 
  • nur ungenügend oder gar nicht getestet.
Es ist schon erschreckend, wie viel Zeit in einem Projekt verloren gehen kann, nur weil eine Komponente wieder einmal nicht das tut, was sie tun sollte. Man gewinnt nicht selten den Eindruck, dass bei der Komponentenumsetzung sämtliche Grundsätze robuster Softwareentwicklung aussen vor geblieben sind.

Angesprochen auf diese Problematik, erklären die meisten Entwickler, dass das zwar ärgerlich aber kaum vermeidbar sei. Schliesslich sei Softwareentwicklung ein kompliziertes(!) und (zu?) schwieriges Unterfangen, und da sei das eben so.

Diese Haltung ist sehr bedauerlich, verhindert sie doch, dass sich etwas zum Besseren ändert. Nur wenn wir uns nämlich als Entwickler künftig weigern, schlecht oder nicht getestete, fehlerhafte und schlecht dokumentierte Komponenten überhaupt einzusetzen und uns aktiv gegen die grassierende Featuresucht zur Wehr setzen, kann die Situation verbessert werden.

Jede und jeder, der Software schreibt ist letztlich dafür verantwortlich, dass Qualität entsteht. Geben wir uns nicht mit teuren aber fehlerhaften „as-is“ Komponenten zufrieden, für die der Hersteller in der Nutzungsvereinbarung bereits jegliche Verantwortung ablehnt, weil ihm die Muffe geht, wenn er nur schon daran denkt, wie seine Komponenten im Feld den Dienst versagen könnten.

Und für diejenigen unter uns, die Komponenten schreiben: Nehmen wir die Herausforderung an, stabile verständliche und vor allem getestete Komponenten zu entwickeln, die tatsächlich Zeit sparen anstatt sie zu verschwenden. Nur so wird es letztlich möglich sein, den Komponententraum wahr werden zu lassen.