Gestern Nacht habe ich noch bei Fabian diesen Artikel gelesen, bei dem es sich um die Frage dreht, ob komplexe Probleme auch komplexe Lösungen nach sich ziehen müssen. Berufsbedingt dreht es sich hierbei um die Software-Entwicklung aber ich denke das ist auf viele andere Bereiche übertragbar. Ich hatte schon angefangen einen Kommentar zu schreiben, aber der wurde länger und länger und so dachte ich mir ich nutze mal die schöne Möglichkeit des Trackbacks und verfasse das direkt als eigenen Blogpost :).
Vielleicht sollte ich es gleich als kleine Warnung vorweg schreiben, dass ich ein glühender Verfechter für einfache Lösungen bin und es spielt dabei meiner Meinung nach auch keine Rolle wie komplex irgendein Problem ist. Dabei sollte zunächst einmal zwischen Komplexität (= Schwierigkeit) und Umfang (= Grösse) einer Problemstellung unterscheiden. Wobei Software-Projekte auch mit Leichtigkeit an ihrer Grösse scheitern können, aber das ist normalerweise eher auf organisatorische Probleme zurückzuführen. Aber ich komme ein wenig vom Thema ab ;).
Wie bereits im Artikel von Fabian beschrieben ist eine grosse Herausforderung die Problemstellung wirklich zu verstehen und auf die (wichtigen) Anwendungsfälle herunterzubrechen. Hierbei kann es durchaus sein, dass die echten Domain-Experten dazu nicht in der Lage sind, da sie einfach zu tief in der Materie stecken. Da heisst es dann erstmal nachfragen, bohren und graben bis klar ist, was denn wirklich die Aufgabenstellung ist und was die Software am Ende leisten soll. Hierbei ist ein iterativer Ansatz natürlich extrem hilfreich, weil damit der Anwender schon möglichst früh abgleichen kann, ob die Funktion der Software auch seinen Ansprüchen entspricht. Nur dann besteht die Möglichkeit bereits früh Veränderungen an der Funktionalität vorzunehmen, was deutlich schwieriger wäre, wenn der Kunde einfach nach einem halben Jahr eine Software vorgesetzt bekommt, die dann seinen Ansprüchen – vorne und hinten – nicht genügt.
An dieser Stelle versuche ich jetzt mal den Bogen wieder zurück zu spannen zur Überschrift: Einfach Lösungen bevorzugt. Eigentlich sollte es sogar heissen: Einfache Lösungen sind ein Muss. Denn so gut wie jedes Software-Projekt wird eigentlich immer nur komplizierter im Laufe der Entwicklungsphase. Es kommen neue Anforderungen vom Kunden oder gewisse Aspekte waren doch nicht so einfach, wie anfangs gedacht, es gibt Ausnahmefälle zu berücksichtigen, etc.. Wenn die Software-Architektur jetzt bereits von Beginn an sehr (zu) komplex angelegt war, sind die Probleme bereits vorprogrammiert, denn jede Erweiterung wird zur Qual, von der Wartbarkeit mal gar nicht zu reden. Einfache Lösungen spiegeln sich dagegen auch in einer einfachen Architektur wieder, welche Erweiterungen erlaubt ohne die ursprünglichen Konzepte über den Haufen werfen zu müssen und damit meiner Meinung nach auch eine tragende Säule agiler Software-Entwicklung ist, die ansonsten überhaupt nicht realisierbar ist.
Ok, ich komme einfach nicht umhin hier eine kurze Geschichte zu erzählen, die ich von einem sehr guten Kollegen habe, und an die ich immer wieder denken muss, weil einfach viel Wahrheit drinsteckt:
Ein Elefant geht durch den Wald und sieht einen Affen unter einem Baum stehen und nach einer Banane springen. Der Elefant fragt den Affen was dieser denn dort macht und der Affe antwortet er wolle an die Bananen ran. Daraufhin schlägt der Elefant vor, doch einen der Söcke zu nehmen, die auf dem Boden liegen und damit die Banane vom Baum zu schlagen. Doch der Affe antwortet: Keine Zeit, ich muss springen!
Das ist leider der Zustand in dem sich Software-Projekte viel zu häufig wiederfinden (im Grossen wie im Kleinen) und der Schritt zurück und ein Schnack mit Kollegen über das Problem bringt hier häufig die erwünschte einfache Lösung zutage. Doch wie gesagt, auch im Alltag springt man viel zu häufig, statt sich mal nach dem Stock umzuschauen ;).
Und bevor ich mich jetzt ganz anhöre wie Tom-Yoda starte ich lieber mal ins Wochenende, es geht paddeln auf der Sieg, wenn das Wetter denn mitspielt. Und wenn wir nicht absaufen gibt es natürlich einen Bericht an dieser Stelle :).
