This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: Perfektion als Maßstab?
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Schön langsam wird es schwierig, alle Themen unter einen Hut zu bekommen. Ich versuche daher hiermit auf einige Punkte aus den unterschiedlichen Themenbereichen einzugehen, um hoffentlich alles ein wenig zu kanalisieren.
Alex hat ja bereits meine Aussagen zum Thema Der perfekte Softwareentwicklerkommentiert. Nun hat sich auch noch Sven zu Wort gemeldet und das Thema Perfekte Software ins Spiel gebracht. Plausible und legitime Fragestellungen bzw. Aussagen können daraus erlesen werden.
Wenn ich mir darüber nun so meine Gedanken mache, dann stellt sich für mich die Frage, ob Perfektion überhaupt der Maßstab sein kann?
Qualität als Hürde
Software wird bekanntlich von sehr vielen nicht als qualitativ hochwertig angesehen, unabhängig der Bereiche, in denen seit jeher getestet wird, was das Zeug hält. In Business-Anwendungen und im Individual-Bereich zählen oft andere Anforderungen: schnelle Umsetzungszeit, möglichst hohe Funktionsdichte, möglichst hoher Gewinn. Legitime und nachvollziehbare Punkte, die sich offensichtlich mit erhöhtem Zeitaufwand durch Qualitätssicherung, Einführung neuer Methoden und Praktiken oft nicht vereinbaren lassen. Oder doch?
Aus Sicht der Nicht-Entwickler, fallen zum Zeitpunkt der Einführung derartiger Prozesse höhere Aufwände (zeitlich, monitär, etc.) an. Diese wollen oder können nicht getragen werden.
Der springende Punkte daran (und hier können sich weder Kunde, noch der Vorgesetzte, noch die Entwickler ausnehmen) ist, dass jeder seinen Teil dazu beitragen muss. Eine Gruppe alleine kann den großen Umschwung nicht bringen. Prozesse müssen optimiert, Methoden eingesetzt und beides gelebt werden. Nur dann kann es funktionieren.
Im Zuge dessen fällt immer wieder der Return on Investment (ROI). Ich gehe nicht so weit zu sagen, dass ihn niemand erkennt. Vielmehr wird oft nur der vermeintlich steinige Weg gesehen, den es zu gehen gilt. Dass dieser Weg gar nicht so steinig ist und mit kleinen, eingestreuten, Änderungen sehr schnell gegangen werden kann, wird oft nicht korrekt vermittelt (vom Entwickler, von Magazinen, von Online-Artikeln, etc.) oder vom Vorgesetzten dem Kunden gegenüber. Letztlich ist es dem Kunden egal, er will ein funktionierendes Produkt haben. Wie dies erreicht wird, Sache des Herstellers.
(Bewusst aussen vor lasse ich hierbei die Themen wie mit Features etc. umgegangen wird.)
Verantwortung übernehmen
Wohl einer der wichtigsten Punkte: Wer Verantwortung übernimmt, kann Veränderung bringen. Ein qualitätsbewußter Entwickler wird Verantwortung übernehmen, indem er einfach mal eben eine Build-Umgebung einrichtet, oder unabhängig der Unterstützung von oben seine Tests schreibt. Er wird eine geeignete Möglichkeit finden, seine Aufgaben zu analysieren, zu planen, umzusetzen und zu testen. Mit ein wenig Glück kann er diesen Gedanken auf Kollegen und Vorgesetzte transportieren.
Der Vorgesetzte muss Verantwortung üernehmen, indem dieser Entwickler gefördert wird. Natürlich muss nicht nur der qualitative Output passend sein, auch der quantitive. Ganz klar. Er muss einsehen, dass eine qualitative Verbesserung natürlich eine Auswirkung auf den gesamten Output des Unternehmens und somit auch auf das Branding des Unternehmens hat. Der Kunde wird es danken und eventuell weitere Kunden heranschaffen.
Ziel soll es sein, dass sich alle Bereiche (Entwickler, Vorgesetzer, Kunde) gegenseitig unterstützen und sich gegenseitig motivieren sich zu verbessern. Das muss nicht in Einklang mit Verzögerung, weniger Gewinn etc. gehen. Wohl aber geht es in die positive Richtung - mit dieser Einstellung.
Suchen, Sehen, Lernen, Verstehen, Vermitteln
Was Sven festgestellt hat, kann ich nur unterstreichen. Niemand weiß alles. Perfektion kann es also in diesem Sinne nicht geben. Was es aber geben kann und sollte, ist eine permanente Annäherung. Die Entwicklung von Software geht heute kaum schneller voran, als dies vor einigen Jahrzehnten der Fall war. Lediglich die Mittel, Werkzeuge haben sich geändert. Aus einem einfachen Programmierer ist ein Entwickler geworfen. Mit höheren Anforderungen, höhrerer Eigenständigkeit und mehr Verantwortung.
In diesem Zusammenhang fällt mir spontan der Begriff des Paradigmenwechsels ein. Ein Paradigmenwechsel wird notwendig, wenn Anomalien zunehmen und erkannt wird, dass ein anderer Weg doch der bessere wäre. Bis das Spiel wieder von vorne beginnt. In unserer schnelllebigen Branche verändert sich zwar vieles, Paradigmenwechsel halten sich - aus meiner Sicht - jedoch in Grenzen. Es gibt zwar hier Neues, dort Neues, aber wirklich wichtige Praktiken werden nur sehr sehr langsam angenommen.
Woran scheitert das?
Nicht weil wir so schlecht sind, es ist die Fülle an Information, an Werkzeugen, an Methoden. Haben sich darüber früher eine Handvoll Personen Gedanken gemacht, ist in der heutigen Zeit an allen Ecken und Enden ein neuer Aspekt zu lesen. Schwierig, alles unter einen Hut zu bekommen.
Wie war das? Sprich mit fünf Leuten und du erhältst 6 Meinungen. Der einzig wahre Weg ist nicht zu finden. Aber führen nicht alle Wege nach Rom? Die impliziert, das Rom das Ziel aller Ziele wäre. Dies bedeutet, dass auch alle Wege an Ziel führen. Ist das so?
Wie viele (Software)Projekte werden nicht abgeschlossen? Wieviele werden nicht mit vollständiger Funktionalität rechtzeitig ausgeliefert? Die Antwort kann sich jeder selbst geben.
Der Punkt ist, dass eben nicht alle Wege ans Ziel führen. Unterschiedliche Zeiten erfordern unterschiedliche Aktionen.
Gibt es eine Lösung?
Wohl nicht. Man kann wohl niemanden bekehren den richtigen Weg zu gehen, weil es ihn einfach nicht gibt. Aber man kann durchaus einen richtigeren Weg vorschlagen und versuchen zu unterstützen. Eigeninitiative und Verantwortung sind sie Schlagwörter von Wichtigkeit.
Es ist schön perfekt zu sein. Niemand wird jemals perfekt sein. Weder der Mensch, noch seine erschaffenen Produkte. In ist, wer nicht perfekt sein will, sich und seine Umgebung jedoch beständig zu verbessern versucht.
In diesem Sinne:
Keine Perfektion, aber kontinuierliche Verbesserung!
Previous Topic
