Jeder von Euch war sicherlich schon in einer solchen Situation:

• Der Chef kommt von einer Konferenz: „Wir führen jetzt DevOps ein!“
• Ein Kollege kommt von einer UX-Weiterbildung: „Wir sollten ab jetzt Paper Prototyping machen!“
• Der Product Owner kommt von einem neuen Kunden: „Wir sollten den Kunden ganz eng in die Entwicklung einbinden!“
• Der CIO kommt von einem Vortrag über Netflix: „Unsere Software muss jetzt bei Amazon Web Services betrieben werden.“

Alle berichten enthusiastisch über ihre neuen Erkenntnisse und die Reaktion der Kollegen ist häufig die gleiche: „Das ist zwar schön, geht aber bei uns nicht, weil:“

Auf den ersten Blick erscheint diese Aussage meist plausibel und wird oft öffentlichkeitswirksam mit einem Beispiel unterlegt. Dennoch hält diese Aussage bei genauerem Hinsehen meist nicht stand. Hierfür sind uns bisher hauptsächlich 2 Ursachen begegnet: Subjektiv wahrgenommene, extreme Komplexität oder eine überzogene Erwartung bezüglich der Präzision von Software Engineering (SE) Methoden.

Wahrgenommene Komplexität

Dass wir uns in der eigenen Domäne besonders gut auskennen, ist eine absolute Stärke und notwendig, um tolle Produkte zu bauen: Wir kennen unsere Kunden (manche davon sogar persönlich), die Konkurrenz, den Markt, wichtige Einflussfaktoren und vor allem die Historie des eigenen Unternehmens.

Das hat aber nicht nur Vorteile: Weil wir für unser eigenes Unternehmen alle Details und (noch so abstrusen) Spezialfälle kennen, erscheint unser eigenes Business als viel komplizierter als das der Konkurrenz. Weil wir deren Details und Spezialfälle eben nicht kennen, tendieren wir eher dazu, sie zu simplifizieren. In unserem eigenen Unternehmen sehen wir oft den Wald vor lauter Bäumen nicht und die Fähigkeit zur Abstraktion bleibt im Tagesgeschäft auf der Strecke. Wir tendieren somit dazu, die Situation im eigenen Unternehmen zu übertreiben und die Situation von anderen Unternehmen zu untertreiben.

Die wahrgenommene Komplexität (im eigenen Unternehmen) nimmt noch dadurch zu, dass Unternehmen oft groß sind und das Wissen auf viele Köpfe verteilt ist. Somit ist es dem Einzelnen meist gar nicht möglich, sich eine Übersicht zu verschaffen. Um trotzdem zur notwendigen Abstraktion zu kommen, müssen sehr viele Leute involviert werden. Die dadurch entstehende Prozesskomplexität wird dann als Komplexität des zu lösenden Problems wahrgenommen. Diese Prozesskomplexität nimmt man bei der Konkurrenz nicht wahr und somit erscheint deren zu lösendes Problem einfacher.

Schauen wir uns als Beispiel die Einführung von DevOps an. Wir haben von vielen Unternehmen gehört, dass es erfolgreich eingeführt wurde. Soll es aber bei uns zum Einsatz kommen, dann fallen uns alle Details ein, die dagegen sprechen: alle zu involvierenden Personen und ihre Eigenheiten, Machtspiele und Veränderungsresistenzen, die Komplexität in Varianten und Releases der eigenen Produkte und Systeme und alle internationalen Unterschiede. Alle diese Details sind uns von den anderen Unternehmen nicht bekannt und führen somit nicht zu wahrgenommener Komplexität.

Überzogene Erwartung

(Uns) Informatikern fällt es besonders leicht, Gegenbeispiele zu finden, die belegen, dass eine Neuerung nicht 100%ig angewendet werden kann. Dies gilt meist sogar für eine Anwendung im Allgemeinen aber auf jeden Fall für eine Anwendung im eigenen Unternehmen. Selbst wenn die Neuerung zu 99,9% angewendet werden könnte, so finden wir die 0,1%, in denen es nicht funktioniert. Somit liefern wir den Todesstoß durch Gegenbeispiele:

• „Herr Müller aus dem Betrieb würde niemals mit uns zusammenarbeiten, daher können wir kein DevOps einführen!“
• „Bei uns können nicht alle Mitarbeiter zeichnen, somit können wir kein Paper Prototyping einführen!“
• „Die meisten unsere Kunden wissen eh nicht was sie brauchen, somit können wir sie auch nicht in die Entwicklung mit einbinden!“
• „Wir hatten auch schon mal Kunden aus dem militärischen Bereich, somit dürfen wir gar keine Daten in der Cloud speichern und schon gar nicht bei einem Unternehmen aus den USA!“

Häufig ist jedoch unser Anspruch an SE-Methoden zu hoch. Statt zu erwarten, dass sie uns in einem überwiegenden Teil der Fälle helfen, erwarten wir 100% Anwendbarkeit und Präzision, am besten anwendbar ohne viel Vorwissen und trotzdem mit tollen Ergebnissen. Sofern dies nicht vollständig gegeben ist, tendieren wir stark zur Ablehnung der Methode. Eine solch ablehnende Haltung wird dann gleich noch generalisiert und die Anwendbarkeit der Methode grundsätzlich in Frage gestellt. Es erscheint plausibel, die 99,9% Verbesserung sicherheitshalber fallen zu lassen, da die Methode nicht 100% funktioniert.

Damit werden zwar die problematischen 0,1% vermieden aber wir bekommen eben auch nicht die 99,9% Verbesserung. Da man nach so einer Entscheidung aber nichts verändern muss, werden sie viel zu leicht und viel zu oft getroffen. Das hängt leider auch damit zusammen, dass „man“ für die problematischen 0,1% ggf. irgendwann Rede und Antwort stehen muss, wenn man sich FÜR eine Änderung entscheidet. Wird die leichte Entscheidung GEGEN eine Änderung getroffen, muss „man“ aber nie für das Nicht-Eintreten der 99,9% Verbesserung einstehen, weil es ja einfach so weiter geht wie bisher.

Sofware-Engineering ist keine exakte Wissenschaft!

Wir vergessen leider sehr gerne: Software Engineering ist keine exakte Wissenschaft. Vielmehr dient es dazu, den Umgang mit vielen komplexen Einflussfaktoren in der Entwicklung von Software besser beherrschbar zu machen:

• Mitarbeit von vielen Menschen mit ganz unterschiedlichen Hintergründen und Wissensständen
• Lösung immer neuer Problemstellungen durch Software. Diese Problemstellungen sind meist nicht klar, ändern sich über die Zeit und werden von verschiedenen Menschen verschieden wahrgenommen
• Verwendung innovativer Technologien, die häufig nicht in allen Facetten verstanden sind

In einem solch komplexen und heterogenen Umfeld ist es eigentlich klar, dass SE-Methoden nur mit Abstraktionen arbeiten und Approximationen anbieten können. Sie sind selten wirklich formal und erfordern immer ein gewisses Expertenwissen. Im Umkehrschluss ist es dann die Aufgabe der anwendenden Menschen, die Übertragbarkeit oder Nichtübertragbarkeit zu erkennen und im Falle einer Anwendung auch konkret auszugestalten.

In der konkreten Anwendung von SE-Methoden bleibt daher immer der Mensch gefordert: Er hat Gestaltungsspielraum und kann seine Kreativität einbringen. Softwareentwicklung ist keine überaus planbare und vorhersehbare Aktivität, sondern erfordert einen hohen Grad Forschungs- und Planungstätigkeiten (Gedanken dazu in einem Blog-Beitrag von Ralf Westphal ).

Es gibt keine Fließbandtätigkeiten im Software-Engineering!

Tätigkeiten mit extrem hoher Wiederholbarkeit (wie zum Beispiel Montage am Fließband) gibt es bei der Softwareentwicklung fast nicht, insbesondere weil Software, einmal erschaffen, beliebig ohne Aufwand vervielfältigt werden kann. Für alle wiederkehrenden Aufgaben entstehen Tools zur Automatisierung, wie zum Beispiel für die Testautomatisierung oder für Continuous Delivery. Zu großen Teilen  ist Softwareentwicklung aber weniger formal und planbar und fordert mehr den Menschen. Wäre dies nicht so, dann wäre Softwareentwicklung mittlerweile vollständig automatisiert und nicht mehr auf Menschen angewiesen. Obwohl das offensichtlich ist, haben dennoch viele den Wunsch nach einer Supermethode, die perfekt auf jeden Kontext passt und völlig reproduzierbar ist (und im Falle der Existenz direkt alle Jobs kosten würde).

Das alles soll natürlich nicht heißen, dass SE-Methoden nicht noch weitaus besser werden können und müssen. Mary Shaw zeigt sehr gut auf, wie sich Software Engineering gegenwärtig gegenüber anderen Ingenieursdisziplinen positioniert und welches Verbesserungspotential noch besteht. Es gibt also noch viel zu tun!

In diesem Wissen über SE-Methoden müssen alle Beteiligten handeln: nicht vorschnell Methoden und Ideen ablehnen. Bevor wir sagen „bei uns ist alles anders“ sollten wir darüber nachdenken, wo Abstraktion und Approximation am Werk sind. Die Kunst ist es also gerade nicht, durch ein Gegenbeispiel eine neue Idee auszuhebeln, sondern umfassend zu beurteilen, ob in der Summe eine SE-Methode wirtschaftlich und erfolgreich einsetzbar ist.

Ist bei dir im Unternehmen auch alles anders? Hast du eventuell eine schöne Anekdote, die zum Spruch passt? Dann schreib uns einfach einen Kommentar.