- Angst ist ein Kontrollinstrument. Wer Bedenken äußert und Unsicherheitsszenarien ausmalt, der erlangt Bedeutung und damit Macht. In einer Welt, in der Softwareentwicklung oft noch als lästiges Anhängsel gesehen wird und man mit Unkenntnis in IT-Dingen auf Partys und im Feuilleton kokettieren kann, da schrumpft auf der anderen Seite schnell mal das Selbstwertgefühl – und will kompensiert werden. Angstbasiertes Bedenkenträgertum ist da ein probates Mittel.
- Wem der vorgenannte Grund zu psychologisch-schwammig ist, kann hoffentlich zumindest mit diesem zweiten etwas anfangen: Die ängstlichen Bedenken sind Ausdruck einer noch tieferliegenden Angst. Und das ist die Angst, Code später nur noch schwer verändern zu können. Der Gedanke dahinter: “Wenn ich heute etwas nicht berücksichtige, dann habe ich morgen oder übermorgen große Probleme, neue Erkenntnisse in den Code einzubringen.” Spätere Codeanpassungen können zu Regressionen führen, Codeveränderungen können schlicht viel, viel, viel aufwändiger sein, als es gleich “richtig” zu machen.
Der zweite Grund ist für mich der gravierendere. Denn dahinter steckt ein Bild von Code, das mir essenziell anti-agil scheint.
Oberste Priorität hat für mich daher jedes Prinzip und jede Praktik, um diese Angst zu reduzieren. Eine gute Abdeckung mit automatisierten Tests hilft. Ein Versionsverwaltungssystem hilft. Ein automatischer Buildprozess hilft. Sie wirken angstlösend. Regressionen werden zumindest schnell erkannt, wenn nicht gar verhindert.
Für die Flexibilisierung von Code müssen wir aber noch mehr tun. Die Kosten für Änderungen dürfen nicht weiter exponenziell steigen. Aber auch einen linearen Anstieg empfinde ich als noch zu schwachen Trost. Warum wird es mit der Zeit nicht immer leichter und leichter, Änderungen in Software einzubringen? Wenn wir Software als Wissenspool ansehen, dann wächst der doch über die Zeit. Und mit mehr wissen, sollten Probleme in der Zukunft leichter zu lösen sein.
Dieser kühnen Vision stehen aber natürlich alte, feste Glaubenssätze entgegen. Aus denen speist sich auch die Angst. Da Angst jedoch ein ganz unschönes Gefühl ist, finde ich es natürlich, nach Wegen zu suchen, die Angst zu überwinden. Auch und gerade, wenn wir dafür über die langen Schatten heimeliger Glaubenssätze springen müssen.
Welche Glaubenssätze halten uns also davon ab, Software in anderer als der heutigen Weise zu entwerfen und zu codieren? Was können wir anders machen, um keine Angst mehr davor zu haben, Veränderungen auf einen beliebigen Zeitpunkt in der Zukunft zu verschieben? Wie kommen wir weg von dem Satz, “Ja, wenn Sie uns das vor einem halben Jahr gesagt hätten, dann hätten wir das ganz leicht einbauen können. Jetzt ist das sehr, sehr schwierig.” Der ist nämlich nicht nur demotivierend für Kunden wie Entwickler, sondern steht in ständigem Konflikt zur Realität der Anforderungskenntnis. Kunden wissen nun mal sowenig darüber, was sie morgen oder übermorgen vielleicht haben wollen. Und sie können das, was sie ungefähr wissen, nur schlecht formulieren. Also müssen wir ohnehin mit ständigen Veränderungen fertig werden. Besser, wir verlieren endgültig die Angst davor. Stattdessen sollten wir jeden Änderungswunsch willkommen heißen. Denn er zeigt uns, dass unsere Software gewollt wird. Wer aufhört, Änderungen zu wünschen, der hört sehr wahrscheinlich auf, unsere Software zu nutzen.
3 Kommentare:
"Warum wird es mit der Zeit nicht immer leichter und leichter, Änderungen in Software einzubringen? Wenn wir Software als Wissenspool ansehen, dann wächst der doch über die Zeit."
Typischerweise steigt im Lauf der Zeit die Code-Menge und meistens auch die Komplexität des Codes. Die reine Code-Menge macht es schon schwieriger, die zu ändere(n) Stelle(n) zu finden oder einfach nur den Überblick zu behalten. Und (steigende) Komplexität ist das Hindernis bzw. der Bremsklotz überhaupt.
Natürlich kannst du sagen, dass man wegen SRP/SoC gar nicht immer alles im Blick haben muss, und das stimmt bis zu einem gewissen Grade, aber das kompensiert eben nur einen Teil des steigenden Aufwands. Und gerade steigende Komplexität überkompensiert alle auf diese Weise erreichbaren Einsparungen.
Selbst bei einem Wissenspool stimmt deine Annahme nicht. Mit mehr Wissen werden Aufgaben nicht unbedingt leichter, da bei der Erledigung der Aufgabe auch mehr zu berücksichtigen ist. Das steigende Wissen über frühere Fehlentscheidungen, Fehler- und Gefahrenquellen, Unfälle, Umweltauswirkungen usw. machen die Konstruktion eines neuen Produkts (nehmen wir Autos) immer schwieriger und komplexer. Es muss immer mehr berücksichtigt werden. Immer mehr muss im Blick behalten werden.
Diese Angst führt auf Seiten des Kunden insbesondere auch dazu, dass möglichst jeder möglichst alle Anforderungen und Eventualitäten von vorneherein von der Software abgedeckt wissen will. Er hat in seiner Laufbahn schließlich gelernt, dass später eingebrachte Anforderungen -- wenn überhaupt -- nur noch mit Schmerzen, Vorwürfen, viel Zeit und noch mehr Geld erfüllt werden.
Das Ergebnis sind nicht zuletzt aufgeblähte Anforderungskataloge, zähe politische Auseinandersetzungen bei sich widersprechenden Anforderungen. Dies führt oftmals eben dazu, dass das Projekt nach monatelanger Diskussion überhaupt nicht mehr realisiert wird.
Diese Angst sorgt also oft genug dafür, dass spannende Aufgaben und sinnvolle Lösungen nie umgesetzt werden.
@Frank: Ich denke, wir haben hier ein Missverständnis. Ich versuche es einmal aufzuklären:
Wenn ich zum Zeitpunkt t1 ein Feature F an 3 Stellen einbauen muss, dann ist das wenig Aufwand.
Wenn dem Kunden das Feature F dem Kunden erst viel später einfällt (t2 >> t1), dann ist mein Aufwand, es einzubauen u.U. viel größer, weil ich es an 30 Stellen einbauen muss. Dagegen kann ich nichts machen.
Allerdings werden hier Äpfel mit Birnen verglichen. Denn es werden zwei unterschiedliche Systeme verglichen. Unter den Tisch ist nämlich gefallen, dass von t1 bis t2 27 Stellen hinzugekommen sind, an denen F relevant ist. Hätte ich F schon an t1 gekannt, hätte ich an diesen 27 Stellen F selbstverständlich beim Fortschreiten von t1 nach t2 auch einbauen müssen.
Um diese Art der Aufwandssteigerung geht es mir ja aber gar nicht. An steigender Quantität ist kaum zu rütteln.
Entwickler können nicht aufstöhnen, weil der Kunde erst bei t2 auf F kommt, weil sie dann an 30 Stellen F nachträglich einbauen müssen. Den Aufwand hätten sie eh gehabt.
Deshalb stöhnen sie auch nicht. Sie stöhnen vielmehr, weil es schwieriger ist, F nachträglich einzubauen als sofort, wenn man an eine relevante Stelle herstellt. Und nicht nur ein bisschen schwieriger, sondern richtig viel schwieriger.
Etwas formaler: Der Aufwand, um F an einer relevanten Stelle S anzuwenden, sei AF. In meiner Vorstellung ist AF mehr oder weniger konstant, also AFt1 == AFt2. Es gibt also nur einen vernachlässigbaren Unterschied zwischen 3*AFt1+27*AFt1 und 30*AFt2.
Das sehen die meisten Entwickler für ihre Projekte heute aber ganz anders. Für sie ist AFt1 << AFt2.
Und da frage ich: Warum sollte das so sein? "Wegen der Komplexität!" ist die reflexhafte Antwort. Das hört sich aber so an, als sagte man: "Mit dem Rauchen aufhören ist so schwer wegen der Abhängigkeit."
Klar, das ist so. Aber das muss ja nicht so sein. Wir sind doch nicht einfach Opfer des Rauchens und der Softwarekomplexität. Wir tun uns beides jeden Tag selbst an. Da ist ein bisschen SRP-Missachtung auf Methodenebene nur die Spitze des Eisbergs. Völlig unnötige Komplexität lauert überall. Das beginnt mit Features, die man einbaut, obwohl unklar ist, ob sie irgendwer braucht. Es beginnt also mit der Kultur des Unternehmens.
Kommentar veröffentlichen
Hinweis: Nur ein Mitglied dieses Blogs kann Kommentare posten.