Von Versprechen in der Politik und in der IT

Agile Kolumne: Wahl ohne Kampf

Henning Wolf

Alle 4 Jahre wieder wählen wir den deutschen Bundestag (oder auch schon mal etwas eher). Diverse Parteien und Gruppierungen mit den unterschiedlichsten Programmen und Versprechen buhlen um unsere Stimmen. Dabei werden die verschiedenen Sichtweisen der Parteien in hitzigen Diskussionen unters Volk gebracht. Beim Volk kommt allerdings gar nicht so viel von den Inhalten an, oder sie glauben nicht, dass es relevante Unterschiede zwischen den Parteien gibt. Jedenfalls treffen immer mehr Wähler ihre Wahlentscheidung sehr spät. Und immer mehr Wahlberechtigte entscheiden sich dafür, von ihrem Wahlrecht keinen Gebrauch zu machen. Ein Grund liegt sicherlich darin, dass die Bürger den Versprechen der politischen Parteien immer weniger glauben.

Alle 4 Jahre wieder wählen wir den deutschen Bundestag (oder auch schon mal etwas eher). Diverse Parteien und Gruppierungen mit den unterschiedlichsten Programmen und Versprechen buhlen um unsere Stimmen. Dabei werden die verschiedenen Sichtweisen der Parteien in hitzigen Diskussionen unters Volk gebracht. Beim Volk kommt allerdings gar nicht so viel von den Inhalten an, oder sie glauben nicht, dass es relevante Unterschiede zwischen den Parteien gibt. Jedenfalls treffen immer mehr Wähler ihre Wahlentscheidung sehr spät. Und immer mehr Wahlberechtigte entscheiden sich dafür, von ihrem Wahlrecht keinen Gebrauch zu machen.Ein Grund liegt sicherlich darin, dass die Bürger den Versprechen der politischen Parteien immer weniger glauben.

Perspektivenwechsel

In der Softwareentwicklung haben wir ähnliche Versprechen. Egal, ob es um neue Programmiersprachen, Frameworks, Technologien oder Vorgehensweisen geht – immer wieder wird uns Großartiges versprochen: „Objektorientierung bringt (automatisch) Wiederverwendung!“ Das hat nur teilweise hingehauen, und das lag nicht nur an der Kampagne der S.O.A.-Partei, die selbiges und mehr versprach. „Mit Java wird alles einfacher!“ Das stimmte sogar ziemlich lange im Vergleich zu C++. Plötzlich kümmerte sich Java um das Zusammenbauen der Anwendung und die Speicherverwaltung. Zwar konnte es auch damit Probleme geben, aber erst einmal war es wirklich einfacher. Doch mit steigenden Ansprüchen und diversen Erweiterungen ist es heute mit der Einfachheit vorbei. (Ja, zugegeben: Dafür kann man mehr damit machen, aber wir wollten doch Einfachheit!)

„Softwareentwicklung braucht Modellierung! Nehmt UML!“ Natürlich ist Softwareentwicklung zu erheblichen Teilen Modellbildung. Wir machen uns ein Bild von einer Fachlichkeit und modellieren es. Das passiert auch, wenn wir eine Java-Klasse schreiben, denn Modelle müssen weder grafisch noch in UML vorliegen. Andererseits ist es schon verständlich, dass man bei grafischen Notationen keinen Wildwuchs möchte, sondern der UML-Einheitspartei folgend nur eine Notation lernen muss. Aber nur weil es so eine Notation gibt, muss man sie ja nicht immer und überall verwenden, sondern eben nur dann, wenn es sinnvoll ist.

„Agile Softwareentwicklung macht erfolgreich!“ Finden wir persönlich schon, schauen aber realistisch genug darauf, um zu wissen, dass agile Softwareentwicklung eben nicht für Jeden und für alle Organisationen und Projekttypen immer gleich gut geeignet wäre. Und selbst wenn die Voraussetzungen günstig sind, stellt sich der Erfolg keineswegs von selbst ein. Denn wie bei so vielen Versprechen kommt es auch bei diesem ganz wesentlich darauf an, was man bereit ist, für den Erfolg zu ändern. „Groovy/Grails macht Euch x-mal produktiver!“ (mit x>1) Produktivitätsversprechen sind das Steuersenkungsversprechen der Softwareentwicklung. Auch schon die OO-Wiederverwendung und die Java-Einfachheit zielten auf Produktivitätssteigerung ab. Das ist natürlich auch deshalb so verlockend, weil Manager verständlicherweise auf Produktivitätssteigerungen abfahren. Und tatsächlich bietet Groovy/Grails hier ein großes Potential, aber auch das hat seinen Preis: Neben Einarbeitung und Umdenken mag er auch darin liegen, dass vielleicht ein Teil der bisherigen Java-Entwickler abgehängt wird. Das heißt nicht, dass man sich nicht für Groovy/Grails entscheiden sollte. Es sollte einem nur klar sein, welchen Preis man eventuell zu zahlen hat, um tatsächlich produktiver zu werden.

Befinden wir uns also auf der Ebene der Politiker, was die Versprechen in der IT anbelangt? Das glauben wir nicht, denn es gibt wichtige Unterschiede. Eines der Probleme mit den Wahlkampfversprechen liegt darin, dass sie auf der Annahme beruhen, man könnte die Zukunft für 4 Jahre im Voraus vorhersagen. „Wir werden die Steuern senken“, lässt sich eben nur dann einlösen, wenn bestimmte Umweltbedingungen konstant bleiben.

In der Softwareentwicklung haben wir gelernt, dass wir die Zukunft nicht voraussehen können, nicht mal für sechs Monate. Das ändert natürlich nichts daran, dass es immer wieder vollmundige Versprechen von Toolherstellern etc. gibt, was neue Technologien angeht. Aber im Grunde ist uns klar, wo die Grenzen liegen, und wir verwenden neue Technologien situativ und adaptieren gegebenenfalls die Verwendung an die konkrete Situation. Und vor allem diese kreativen Adaptionen finden wir häufig in erfolgreichen Technologien: Das Telefon wurde ursprünglich entwickelt, um Konzerte zu übertragen. Das Lambda-Kalkül war als Ersatz für die Turing-Maschine gedacht und nicht als Programmiersprache (Lisp). Mit Java wollte man Applets für das Internet (oder Steuerungssoftware für Waschmaschinen) entwickeln. Und das Internet war zum Datenaustausch zwischen Wissenschaftlern konzipiert.

Nachträglich hat Altkanzler Schröder erkannt, dass die Zukunft auch für Politiker schwer vorherzusagen ist (aus einem Interview im Spiegel 43/2006): „Vieles war in der Theorie nicht zu analysieren, sondern musste in der Wirklichkeit erprobt werden. Man weiß doch vorher nicht, welche Entwicklungen bei einzelnen Gruppen oder einzelnen Personen auftreten können, die so nicht gewollt sind. Deswegen sage ich ja, man muss die Möglichkeit haben, politisch undiskreditiert korrigieren zu können.“

Perspektivenrückwechsel

Genau damit haben die Politiker ein Problem. Sie beschränken sich nicht darauf, eine Strategie zu formulieren („wir wollen die Steuern senken, wenn das finanzierbar ist“), sondern machen Versprechungen („wir werden die Steuern senken“) – und das funktioniert eben selten.Aber kann man es Ihnen allein vorwerfen? Zwingen wir einfachen Bürger unsere Politiker nicht gerade dazu, es uns so einfach wie möglich zu machen? Klar wollen wir am liebsten weniger Steuern bezahlen. Vermutlich interessiert es viele nicht einmal, wie das funktionieren soll. Erst später dann bei gekürzten Leistungen des Staats oder hohen Schulden wird die Rechnung präsentiert.

Wenn wir ehrlich sind, machen wir es uns eben auch oft so einfach und nehmen das Versprechen gerne für bare Münze, ohne die Kehrseite der Medaille zu betrachten. Das bietet auch Vorteile: erstens haben viele Spaß am Kennenlernen neuer Konzepte und Technologien, und zweitens dürfen wir uns damit vom Bisherigen abwenden. Das hat vielleicht nach mehreren Jahren einen Zustand der Degeneration erreicht, der den Umgang damit zu einer wenig vergnügungssteuerpflichtigen Veranstaltung macht. Aber Hand aufs Herz: Das vergurkte ANT-Build-Skript braucht eher eine Analyse, wie es so weit kommen konnte als eine Reimplementation mit Maven. Letztere ist zwar einfach, wird aber „wahrscheinlich aus demselben Grund in ein paar Monaten nicht mehr wartbar sein“.

Geschrieben von
Henning Wolf
Dipl.-Inform. Henning Wolf ist Geschäftsführer der it-agile GmbH in Hamburg. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten (XP, Scrum, FDD) als Entwickler, Projektleiter und Berater. Er ist Autor der Bücher „Software entwickeln mit eXtreme Programming“ und „Agile Softwareentwicklung“. Henning Wolf hilft Unternehmen und Organisationen agile Methoden erfolgreich einzuführen.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.