Neulich haben wir bei Holisticon eine Code Kata zur Konvertierung von römischen Zahlen durchgeführt – ein Klassiker. Es wurde testgetrieben und mit Pair Programming gearbeitet. In der anschließenden Diskussion sind wir bei einer Frage gelandet, die in vielen Bereichen – und damit auch beim Pair Programming – sehr wichtig ist: Wie lange denke ich nach, bevor ich anfange, etwas zu tun?

Die Kata wurde in sehr kleinen Schritten durchgeführt. Das hat dazu geführt, dass sich die Kollegen ziemlich direkt in die Aufgabe gestürzt haben, um die erste kleine Anforderung zu implementieren und darauf sukzessive aufzubauen. Eine Strategie zur Lösung der gesamten Aufgabe gab es nicht, da die Lösung durch die Summe aller kleinen Schritte entsteht. Das war auch in diesem Fall so: trotz fehlender Strategie haben die Kollegen die Aufgabe gelöst.

Unabhängig von diesem konkreten Beispiel bzw. der Qualität seiner Lösung bin ich der Meinung, dass man sich zu Beginn einer Aufgabe die Zeit nehmen sollte, über die Strategie zu deren Lösung ein wenig nachzudenken. Ich unterstelle hier, dass das Ziel der Aufgabe ausreichend gut beschrieben ist – was auch nicht immer der Fall, aber eine andere Geschichte ist. Beim Pair Programming sollten sich Driver und Navigator also über eine ungefähre Strategie verständigen, bevor sie anfangen, die Lösung zu implementieren, schließlich gibt es immer mehrere Wege zum Ziel. Dies ist in anderen Lebenssituationen auch so. Wenn ich meinem Navigationssystem das Ziel meiner Fahrt mitteile, schlägt es mir verschiedene Routen dorthin vor, von denen ich eine auswählen muss. Für die Elbquerung in Hamburg gibt es z.B. die beiden wichtigen Varianten – für manche sind es Strategien ;-) – Elbtunnel und Elbbrücken.

Das bedeutet zum einen, dass es im Rahmen einer Strategie noch genügend Detailfragen zu klären gibt, der Weg also nicht in allen Details vorgegeben ist. Schließlich kann ich bestimmte Dinge erst zum Zeitpunkt der Implementierung optimal bewerten. Zum anderen sollte es auch nicht bedeuten, dass man dieser Strategie blind folgt. Stellt man auf halbem Wege fest, dass die gewählte Strategie nicht trägt, so ist sie zu überdenken und anzupassen. Auch das Navigationssystem überprüft während der Fahrt regelmäßig die aktuelle Route und passt sie ggf. in Abhängigkeit von verschiedenen Faktoren wie z.B.

• Verkehrslage
• Baustellen
• meinem Willen, den Anweisungen des Systems Folge zu leisten,

an. Diese Anpassungen reichen von Kleinigkeiten (Wahl einer Parallelstraße) bis zur Änderung der Strategie (der Elbtunnel ist gesperrt und ich muss über die Elbbrücken fahren). Die Einflussfaktoren sind bei jeder Fahrt anders und ändern sich mitunter auch im Verlauf der Fahrt. Auch das ist übrigens in der Softwareentwicklung nicht anders.

Natürlich sehe ich auch die Gefahr, dass man sich gleich zu Anfang beim Finden der Strategie verzettelt. Die Kunst ist hier, rechtzeitig aufzuhören, sich über die Strategie Gedanken zu machen. Ich könnte Stunden damit verbringen, die verschiedenen vorgeschlagenen Routen des Navigationssystems zu durchdenken. Nach einem kurzen Blick auf die Vorschläge und ein paar Abwägungen entscheide ich mich jedoch und fahre los. Ich tue dies in dem Wissen, dass ich auf dem Weg zum Ziel auf aktuelle Geschehnisse reagieren kann und muss. Die beste Strategie nützt nichts, wenn ich sie nicht umsetze. Jedoch brauche ich eine Strategie, um zielgerichtet vorgehen zu können.

Was ist jedoch, wenn ich nicht genügend Wissen habe, um eine Strategie zu finden? In diesem Fall treffe ich die bewusste Entscheidung – wie in der eingangs erwähnten Code Kata – in kleinen Schritten vorzugehen, um mich irgendwie dem Ziel zu nähern. Es ist zu erwarten, dass diese „Trial-and-Error“-Vorgehensweise sehr langsam ist, da sie eine gewisse Anzahl an Fehlversuchen beinhaltet. Sie ist manchmal notwendig, sollte aber nicht der bevorzugte Weg sein – auch und gerade bei iterativer Arbeitsweise.