Dekonstruktion und Askese in der Softwareentwicklung

Es gibt verschiedene Formen von Angelruten, aber die bekanntesten bestehen aus einer mehrteiligen Rute, einer Rolle, Laufringen, Schnur, Gewichten, Schwimmer und Haken. Mit dem richtigen Köder wird das Ensemble einsatzbereit und man darf auf einen ordentlichen Fang hoffen.

Die Einzelteile der Angel unterscheiden sich nicht nur in ihren Aufgaben, sondern auch in ihrer Wichtigkeit. Angelrute und Rolle sind praktisch, aber man könnte die Schnur von einem Steg aus auch direkt ins Wasser ins Wasser halten. Dann bräuchte man nur einen Handschuh, um Schnittwunden zu vermeiden. Wer die Schnur selbst hält, kann auch auf den Schwimmer verzichten. Ist der Köder schwer genug, fallen zusätzliche Bleigewichte an der Schnur weg. Bleiben am Ende nur Schnur, Haken und Köder übrig? Was davon könnte man weglassen?
Ganz einfach: alle drei. Einen Bestandteil der Angel habe ich noch nicht erwähnt: den Widerhaken. Klein und unscheinbar versteckt er sich an der Spitze des Hakens. Ohne ihn würde der Fangerfolg in weite Ferne rücken. Behalten wir nur den Widerhaken und ersetzen den ganzen Rest durch einen Stock. Etwas Übung, und wir können uns erfolgreiche Speerfischer nennen.

Was hat diese Betrachtung mit der Softwareentwicklung zu tun? Einfach alles! Software ist ein Werkzeug, um gegebene Ziele zu erreichen. Software besteht aus vielen Einzelteilen mit verschiedener Wichtigkeit. Manche Teile dienen der Optimierung, sind also praktisch, und manche dienen direkt der Zielerreichung, sind also essenziell. Und gerade letztere machen fast immer nur einen winzigen Bruchteil des Ganzen aus.

Dekonstruktion ist eine Strategie, um ein komplexes Gefüge so zu zerlegen, dass die Einzelteile separat betrachtet und bewertet werden können. Aus Sicht eines Softwareentwicklers zielt diese Bewertung üblicherweise auf Brauchbarkeit (Zweckerfüllung), Wartbarkeit und Fehlerfreiheit. Den späteren Nutzer interessiert aber vor allem ersteres. Von Wartbarkeit hat er keinen konkreten Nutzen und Fehlerfreiheit kann man nur naiv annehmen oder sich erhoffen. Interessiert sich ein Angler für den Durchmesser der Laufringe, die Mechanik der Angelrolle oder die Länge der Schnur? Nicht so sehr wie für den Fisch. Und Brauchbarkeit definiert sich für den Angler nicht nur danach, ob der Fisch gefangen wird, sondern auch wie schnell, wie häufig und wie sicher. Sind das tatsächlich ?nichtfunktionale Anforderungen?? Mit dieser etwas abwertend klingenden Bezeichnung konnte ich mich noch nie anfreunden. Es geht hier schließlich um das Unverzichtbare aus Sicht des Anwenders.

Askese ist ebenfalls eine Strategie, nämlich Beschränkung auf das Unverzichtbare. Indem alles weggelassen wird, was weggelassen werden kann, verringert man den Aufwand und bekommt ein besseres Aufwand-Nutzen-Verhältnis, was nichts anderes ist als Effizienz. Was wäre die kleinste vorstellbare Software, die die Zielerreichung des Nutzers möglich macht? Kann er mit dieser Software erfolgreich arbeiten und alle weiteren Entwicklungen als Optimierungen wahrnehmen?
Die Reduktion aufs Wesentliche bedeutet auch geringstmögliche Komplexität und Abhängigkeiten, und damit unterstützt sie ein Ziel des Entwicklers: Wartbarkeit. Was einfach ist, kann schnell nachvollzogen und auch einfach getestet werden. Was essenziell ist, muss besonders genau getestet werden.

Lesetipps:

Noch kein Feedback