Bessere Prozesse für den Rest von uns

Die “Gurus” können es. Die können ihr TDD, OOP, XP, Scrum usw. Aber was ist mit dem Rest der Entwicklergemeinde?

In den meisten Teams gibt es auch einen, der es kann. Einen der ansagt. Aber was ist, wenn der mal ausfällt? Was ist mit dem Rest des Teams.

Mein Eindruck ist, wir verlassen uns noch zu sehr auf “Gurus”, “Meister” und “starke Persönlichkeiten”. Die bestimmen unsere Arbeit. Entweder verteilen sie sie. Oder sie definieren Methoden auf ihrem Level – die dann Normalsterbliche nur schwer selbst in ihren Arbeitsalltag transferieren können.

Wie anders ist es zu erklären, dass zum Beispiel TDD nach 10 Jahren immer noch kein Standard ist? Wie anders ist es zu erklären, dass Entwurf mit der UML nach mehr als 10 Jahren immer noch kein Standard ist? Mit Standard meine ich so etwas wie “Bei 80% der Entwickler akzeptiert und in täglichem Gebrauch.”

Ich behaupte nicht, dass TDD oder UML schlecht seien. Fragt sich nur, wem sie real helfen. Ich sehe einfach eine große Differenz zwischen Anspruch und Implementation. An der Verfügbarkeit von sprachgewandten Verkündern dieser und anderer Techniken oder Literatur darüber kann es nicht liegen. Woran dann?

Eine Folie in einem Vortrag von Sam Aaron hat mich darauf gebracht:

Sam hat eine Geschichte von Schachgroßmeister Gary Kasparov erzählt: Nachdem Kasparov gegen IBMs Deep Blue verloren hatte, hat er den Gegner Computer nicht verteufelt. Er hat ihn umarmt und versucht, mit Hilfe von Software insgesamt zu einem besseren Spieler zu werden. Er hat sich von Software beim Schachspiel sozusagen beraten lassen. Damit hat er dann jeden der willig war herausgefordert. Und geschlagen wurde Kasparov von zwei Unbekannten.

Darauf bezieht sich das Zitat. Kasparov war überrascht, dass ihn, den Großmeister (strong human), der sich auch noch von einer Maschine unterstützen ließ, zwei Nobodys in Schachdingen (weak human) übertreffen konnten, die sich auch von einer Maschine unterstützen ließen. Sein Schluss daraus: Sie hatten einen “better process”, mit dem sie gearbeitet haben.

Wenn mir eines immer bewusster geworden ist in den letzten Jahren, dann ist das die Begrenztheit der Möglichkeiten zu Veränderungen in Teams. Alle sind nämlich heute am Limit. Inwiefern das selbstverschuldet oder schlechtem Management anzuhängen ist, lasse ich mal dahingestellt. Es ist einfach so. Damit müssen wir leben.

Außerdem ist die Ausbildung von Softwareentwicklern immer noch (oder inzwischen?) schlecht. Nicht überall natürlich, aber weitestgehend.

Unterm Strich bedeutet das, Software wird vor allem von “weak humans” geschrieben. Wir brauchen daher Techniken, Methoden, Konzepte für diese “weak humans”. Das bedeutet, sie müssen sehr explizit und konkret sein. Sie müssen stark an die Hand nehmen. Sie müssen in kleinen Schritten zwischendurch erlernbar sein. Sie müssen in einer Welt voller legacy code und mittelalterlichem Management “bootstrapfähig” sein.

Das sage ich mit einer guten Portion Selbstkritik. Was Stefan Lieser und ich unter www.clean-code-developer.de zusammengetragen haben, entspricht dieser Forderung auch nicht immer. Und auch der Flow-Design Ansatz kann noch darauf zugefeilt werden.

Insgesamt jedoch habe ich in dem Kasparov-Zitat meinen Anspruch formuliert gefunden: Ich bemühe mich und will mich noch mehr bemühen, “normalsterblichen” Entwicklern zu helfen. Die große Zahl “weak humans” ist meine Zielgruppe. Für sie muss ich versuchen, was immer ich beschreibe, verständlich und nützlich zu machen.

Und ich glaube, danach sollten wir in der Branche insgesamt mehr streben. Wir müssen erkennen, dass die Softwarekrise nur mit mehr Entwicklern bewältigbar ist. Das führt allerdings fast notwendig dazu, dass deren allgemeines Ausbildungsniveau nicht steigt. Also sind Veränderungen im Alltag nur erfolgversprechend, wenn sie “weak humans” und “weak teams” und “weak companies” adressieren.

Damit will ich niemanden von einer (Selbst)Verantwortung zum Lernen und Streben nach Verbesserung entheben. Es geht mir vielmehr um die Anerkenntnis der schwierigen Umstände in und um Teams. Wir reden ja bei all den zitierten Methoden vor allem darüber, “Softwareherstellungsmaschinen” während des Laufens umzubauen. Und das ist eben schwierig. Da müssen wir bescheiden werden. Wir müssen auch sensibel werden für die Grunde, warum diese Methode oder jener Ansatz nicht so fruchtet, wie wir es uns vorstellen. Liegt das wirklich an unfähigen Entwicklern – oder sollten wir häufiger selbstkritisch sein und schauen, wo Methode und Ansatz verbessert werden können?

Als Lohn der Mühe winkt gem. Kasparov, dass noch bessere Methoden und Prozesse als heute diese “weak humans” in die Lage versetzen, bessere Software zu schreiben, als die heutigen “Meister” mir ihren Helfern es können. Ist das nicht ein attraktives Ziel, das wir versuchen sollten zu erreichen?

Wo Erfolge heute zu verzeichnen sind, ist das selbstverständlich toll. Aber wir sollten uns von diesen Erfolgen nicht einlullen lassen. Sie können unversehens zum Feind des Besseren mutieren. Das wäre doch schade, oder?

Also: Es gibt keine Methode, kein Konzept, keine Technik, keine Technologie, die nicht noch besser, vor allem einfacher gemacht werden könnte - und somit für “weak humans” leichter zu adaptieren ist. Usability ist auch hier Trumpf.