 |
(12.05.05 07:15)
Softwareentwickler sind irgendwie die geborenen Optimisten, zumindest, wenn es um die Umsetzung von Leistungsmerkmalen für eine Software geht. Es kommt nämlich immer wieder vor, dass sie beim Schreiben von Software in einen wahren Featurerausch verfallen und getragen von einer schon fast kindlich naiven Zuversicht, Leistungsmerkmal um Leistungsmerkmal umzusetzen gedenken, die bei realistischer Betrachtung entweder den Termin oder Budgetrahmen oder schlimmstenfalls beides sprengen. Oder die Entwickler setzen Lösungen um, die auch die erdenklich seltensten Fälle abdecken können, obwohl überhaupt nicht klar ist, ob diese Ausnahmen je zum tragen kommen werden. Nicht zuletzt deswegen weisen XP-Verfechter immer wieder auf das YAGNI-Prinzip hin. Es soll helfen, sich auf das absolut Notwendige zu beschränken, um zu verhindern, dass Zeit und Geld für Dinge verschwendet wird, die man so vielleicht nie brauchen wird.
Leider wird YAGNI oft missverstanden und behauptet, damit werde dem kurzfristigen Drauflosimplementieren Tür und Tor geöffnet, weil man sich nicht mehr um tragfähige Konzepte bemühe und so riskiere, bei neuen Anforderungen grosse Teile einer Lösung ersetzen zu müssen. Würde man YAGNI in diesem Sinne praktizieren, dann wäre das sicherlich problematisch. Aber YAGNI heisst nicht, dass wir uns nicht um änderungsfreundliche Entwürfe bemühen, die sich leicht an geänderte oder neue Anforderungen anpassen lassen. Im Gegenteil, YAGNI zwingt uns dazu, einfache Lösungen zu suchen, im Wissen darum, dass Anforderungen selten lange stabil bleiben und Änderungen im Code daher unausweichlich sind. YAGNI heisst nicht, einfach irgend etwas zu tun, das irgendwie funktioniert. Es bedeutet vielmehr, beim Abwägen zwischen dem Machbaren und dem absolut Notwendigen für eine Lösung tendenziell letzterem den Vorzug zu geben. Gute, einfach verständliche und erklärbare Konzepte sind dabei zwingend. Ebenso wichtig ist aber der Wille, Anforderungen kritisch zu betrachten und zu hinterfragen und den Mut zu haben, höflich stur zu sein und bei Bedarf, Nein zu sagen. Dies gilt insbesondere bei technischen Anforderungen, die häufig mehr auf diffusen Vorlieben, Vorurteilen oder Wunschvorstellungen in Bezug auf verfügbare Technologien und Trends beruhen als auf tatsächlichen Erfordernissen. Aber auch bei den fachlichen Anforderungen ist Mitdenken angesagt. Denn häufig werden auf fachlicher Ebene Lösungen entworfen, die einfach betriebliche Abläufe mittels Software zementieren anstatt eine durch den Einsatz von Software mögliche Verbesserung zu erzielen.
Leider sehen es viele Entwickler nicht als ihre Aufgabe, sich auf die nötigen fachlichen Diskussionen einzulassen. Sie definieren sich vielmehr als Vollstrecker und Implementierer von fachlichen Konzepten mit Hilfe von Softwaretechnik; die Fachvertreter sollen gefälligst ihre Arbeit tun und klare Anforderungen liefern. Warum soll der Entwickler sich nun auch noch um die fachlichen Probleme kümmern müssen? Er hat ja schon genug mit der technischen Umsetzung zu tun! Und schliesslich gibt es doch noch die so genannten Business-Analysts, deren Aufgabe es ist, sich um das Fachliche zu kümmern. Der Softwareentwickler kümmert sich um die Technik; Arbeitsteilung eben. Das gäbe doch nur ein Riesendurcheinander, wenn die Softwareentwickler nun auch noch munter in den Reigen der Anforderungsdiskussionen einstimmen würden.
Arbeitsteilung ist ja eine gute Sache; aber die zunehmende Spezialisierung und die daraus folgende Einengung des Blickwinkels gepaart mit einer Art von Fliessbandmentalität, bei der die Probleme wohl dosiert und präpariert von Spezialist zu Spezialist gereicht werden, verhindert – so fürchte ich - ein interdisziplinäres Zusammenarbeiten. Und wer als Entwickler glaubt, er komme an der kritischen Auseinandersetzung mit der Fachdomäne vorbei, der irrt gewaltig. Der Versuch, fachliche Anforderungen gut - also angemessen, einfach und änderungsfreundlich – umzusetzen, ohne das fachliche Problem wirklich zu verstehen, wird im besten Fall zu einer eleganten technischen Lösungen gelangen, die wahrscheinlich sogar funktioniert, die aber im Sinne von YAGNI weder einfach noch entwicklungsfähig ausfällt.
Die Trennung der fachlichen und technischen Belange bei der Gestaltung und Umsetzung von Software ist wichtig und richtig; problemnahes Programmieren als Teil der domänengetriebenen Entwicklung ist hierbei ein wichtiges Hilfsmittel. Aus dieser Trennung jedoch zu schliessen, dass es für den Softwareentwickler genügt, sich nur um die technischen Belange zu kümmern, ist dagegen ein gefährlicher Irrtum. Eine solche Haltung muss zwangsläufig dazu führen, dass Lösungen entstehen, die technisch zwar brillant sein mögen, aber dennoch unbrauchbar sind, weil sie fachlich gesehen nicht entwicklungsfähig sind. Ein guter Softwareentwickler trennt zwar sorgfältig die fachlichen von den technischen Aspekten einer Lösung, kümmert sich aber als Teil seiner Arbeit ebenso sorgfältig um ein beide Aspekte integrierendes Verstehen; nur so ergibt YAGNI überhaupt einen Sinn.
-nemo :-)
Über diesen Artikel diskutieren.
|
|
