Das Motto
Scatterware ist, den Entwickler in der Sprache entwickeln zu lassen, in der er für das vorliegende Problem zur besten Lösung kommt.
Die Idee
Grundlage für den Ansatz Scatterware ist die Erkenntnis, dass es für kleine Programmteile einfacher und robuster ist, etwas neu zu schreiben, als etwas Vorhandenes anzupassen.
Bei herkömmlicher Software-Architektur ist es meist nicht möglich, ein einzelnes Rädchen im Getriebe auszuwechseln - oft müsste gleich das ganze Getriebe neu erfunden werden.
Das Ziel von Scatterware ist es, ein mächtiges und deswegen unweigerlich hochkomplexes System aus möglichst kleinen, gekapselten Bausteinen zusammenzusetzen.
Die Herausforderung
Die Kunst besteht darin, pro Baustein nur ein Minimum an Schnittstellen entstehen zu lassen. Die Chance, eine Softwarekapsel erfolgreich neu zu schreiben, wird mit der Anzahl und der Komplexität der Schnittstellen geringer.
Ein Modul, das mit einem dutzend anderer Module eng verzahnt ist und das womöglich noch zwei vergessene, undokumentierte, aber wesentliche Seiteneffekte erzeugt, kann nicht neu geschrieben werden. Es kann aber auch nur mit sehr hohem Risiko überhaupt verändert werden. Es besteht die konkrete Gefahr, dass bei einer Ausspielung Störungen verursacht werden - selbst solche, die im QS-System gar nicht auftreten.
An solchen "Bugs durch Bugfixing" erkennt man, dass ein Softwaresystem an einem Punkt in seinem Lifecycle angekommen ist, an dem es sinnvoll wäre, ein komplettes Rewrite vorzunehmen. Das ist aber ein sehr mächtiges Vorhaben und selbst, wenn das Budget dafür zur Verfügung steht, muss immer noch das vorhandene System bis zur Fertigstellung des neuen Release gepflegt und gewartet werden können.
Scatterware kann erreichen, dass ein derart fragiles Softwareprodukt wieder beherrschbar wird.
Der Lohn
Wenn die Rechnung aufgeht - das heißt, wenn man ein System geschaffen hat, das aus lauter Einzelteilen besteht, die jeweils nur wenige, einfache Schnittstellen bedienen und die eine möglichst singuläre Funktion erfüllen ohne viel wenn und aber, dann lassen sich beachtliche Einsparungen erzielen.
Erweiterung eines komplexen Systems
Bild 1. Aufwände, die im Rahmen der Weiterentwicklung eines großen Softwaresystems erbracht werden. Das Vorgehensschema ist: vorhandenen Code verstehen, verändern, testen, ausspielen, Bugs fixen.
Erweiterung einer komplexen Scatterware
Bild 2. Aufwände, die entstehen, nachdem das selbe System mehr und mehr zur Scatterware umgebaut wurde. Wie zu erwarten, fallen keine Zeiten mehr an für das Lesen von altem Code und die Aufwände zum Lesen der alten Dokumentation sind geringer. Das eigentliche Codieren, also das Neuschreiben einer Kapsel und ihr Test, dauern im Schnitt länger als der Einbau einer Änderung. Unterm Strich wird aber deutlich Zeit gespart.
Es zeigt sich weiterhin, dass auch der Einsatz zur Fehlerbeseitigung reduziert werden kann. Es klingt wie eine Binsenweisheit: je weniger man an vorhandenem Code herumdoktert, umso seltener kommt es an ganz unerwarteten Stellen zu neuen Fehlern. Das System wird insgesamt stabiler und wartbarer, die Dauer zwischen Feature Request und Fertigstellung ist verkürzt. Nicht zuletzt bedeutet das weniger Druck und Frust für die Entwickler. Sie haben mehr Spaß an der Arbeit und das macht sie produktiver.
Wem wäre es aufgefallen? Interessant war in diesem Fall die Erkenntnis, dass zuvor kein höherer Aufwand in das Verfassen von Dokumentation (inline und im technischen Handbuch) geflossen ist. Es herrschte retrospektiv aber Einigkeit, dass man zuvor wesentlich besser hätte dokumentieren sollen.
Fazit: Es wird in komplexen Systemen nie genug dokumentiert. Man sollte Software so konzipieren, dass die wenige Dokumentation ausreicht.
weiter mit einem Beispiel für Scatterware
Hinweis: das Zahlenmaterial hinter diesen Diagrammen entstammt natürlich keiner repräsentativen Studie, sondern lediglich einer einzigen Quelle von Entwicklungsarbeiten vor und nach der Einführung der hier beschriebenen Methoden.