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.
