Die Geburt von Clean Code aus der Produktivität

Wenn es beim Clean Code Development nicht offensichtlich um Geld geht, wird es keinen Einzug in die Softwareentwicklung halten.

Nicht, dass ich das nicht schon gewusst hätte, aber ich habe das nicht gut genug umgesetzt in dem, wie ich über Clean Code Development spreche und wie ich es in Trainings und Beratungen vermittle.

Ich werde daher zukünftig die Produktivität in den Mittelpunkt meiner Arbeit stellen.

Produktiv ist, wer in einer gewissen Zeit ein gewisses Ergebnis herstellt. Einen Wert stellt das Ergebnis dar, wenn es für den Empfänger wünschenswert ist und er bereit ist, dafür Geld auszugeben.

Produktiver ist, wer in derselben Zeit mehr Wert herstellt oder in weniger Zeit denselben Wert.

Was wünschenswerte Ergebnisse sind, sei zunächst dahingestellt. Die können etwas mit der Funktionalität einer Software zu tun haben oder mit ihrer Effizienz oder mit ihrer Korrektheit oder mit ihrer Wandelbarkeit.

Primär ist nicht, an welchem dieser Anforderungsbereiche gearbeitet wird, sondern dass überhaupt Wert entsteht.

Ob allerdings Wert entsteht, ergibt nur eine Überprüfung. An den Anfang der Softwareentwicklung gehört daher die Planung der Wertmessung. Wann ist deren nächster Termin?

Bei der Wertmessung bekommt die Umsetzung Feedback. Die Softwareentwicklung ist ja nach dieser Messung nicht beendet. Sie geht weiter und soll aus dem Urteil des Empfängers etwas lernen, allemal, wenn Nachbesserungen nötig sind.

Vielleicht hört sich das für dich noch nicht so neu und ungewöhnlich an. Das mag sich aber ändern, wenn ich betone, was nicht mehr am Anfang der Softwareentwicklung steht: die Anforderungsdefinition.

Genau, ich halte es für wichtiger, den Feedbacktermin festzulegen, als den Termin für eine Spezifikationssitzung.

Und es kommt noch dicker!

Der Empfänger legt noch nicht einmal fest, wie viel Wert er bei der nächsten Messung vorfinden will. Der Empfänger definiert kein Soll. Er ist einzig daran interessiert, dass überhaupt mehr Wert vorhanden sein ist als vorher.

Wichtiger als ein bestimmtes Soll ist dem Empfänger die Verlässlichkeit. Er erwartet nicht nur, dass die Softwareentwicklung den Feedbacktermin einhält, sondern auch, dass sie liefert, was sie an Wert in Aussicht stellt.

Spürst du den Unterschied zur üblichen Praxis?

Üblicherweise sagt der Auftraggeber/Kunde (Empfänger), was bis wann geliefert werden soll. Dann sagt die Softwareentwicklung, das sei nicht zu schaffen. Dann wird verhandelt.

Ich meine es aber anders. Bei mir soll wirklich nur die Softwareentwicklung definieren, was sie meint, an Wert bis zum Feedbacktermin produzieren zu können. Wenn sie sich dabei unsicher ist, dann soll sie lieber weniger versprechen. Und wenn sie sich dann immer noch unsicher fühlt, dann noch weniger.

Der Empfänger klagt nicht „Das ist mir nicht genug.“ oder „Letztes Mal wolltet ihr mehr schaffen.“ Er hat keine Hoheit über den Scope, sondern nur über die Zeit. Die Zeit und auch die Priorität. Denn in der Priorität von Anforderungen drückt sich aus, was ihm etwas wert ist.

Extrem formuliert soll der Empfänger sogar die Softwareentwicklung ermahnen, sich nicht zu viel vorzunehmen. Lieber weniger und verlässlich liefern als mehr versuchen und enttäuschen.

Der Fokus auf die Produktivität drückt sich für mich also im Takt aus. Der Lieferumfang ist zweitrangig.

Jetzt fragst du dich vielleicht, wie es mit so einer Einstellung voran gehen soll. Tritt die Softwareentwicklung dann nicht ängstlich auf der Stelle? „Besser nicht zu viel versprechen!“

Stimmt, es fehlt noch etwas im Bild. Das ist die Frequenz des Taktes. Wie häufig sollte es denn Feedback geben?

Solch ein Fokus auf Produktivität setzt eine hohe Taktfrequenz voraus. Den Abstand zwischen Feedbacks sehe ich bei maximal 16 Stunden, gern auch kürzer. Wenn der Empfänger heute um 9:00h über den nächsten Feedback-Termin nachdenkt, dann sollte der spätestens morgen um 16:00h liegen.

Der Entwicklung gegenüber sagt er dann „Ich würde gern morgen um 16:00h wieder Feedback geben. Was könnt ihr bis dahin verlässlich liefern? Meine Prioritäten sind: Erweiterung S, Bug X, Erweiterung T.“

Nicht in 4 Wochen, nicht in 2, nicht in 1 Woche ist "Antritt zum Rapport", sondern immer spätestens morgen.

Hört sich das für dich nach hohem Druck an? Das würde ich verstehen - doch das Gegenteil soll erreicht werden.

Spüre dem nochmal nach: Die Softwareentwicklung bestimmt, was sie bis zum Feedback-Termin liefern will. Motto: „Darfs noch etwas weniger sein?“ ;-)

Weniger ist nämlich mehr, wenn es denn wirklich geliefert wird. Nicht zu liefern, was man versprochen hat, ist viel schlimmer, als verlässlich nur wenig zu liefern. Ein Versprechen zu brechen führt zu Enttäuschung. Das macht beide Seiten unglücklich.

Indem der Empfänger eine kurze Liste seiner Top-Prioritäten nennt, gibt er der Softwareentwicklung eine Auswahl. Die macht es ihr leichter, sich einerseits auf etwas festzulegen und andererseits sich darüber hinaus zu orientieren.

Sie kann z.B. versprechen, den Aspekt Q als erstes Inkrement der Erweiterung S zu liefern und gleichzeitig die Arbeit an Bug X aufzunehmen. Ob der jedoch gefixt sein wird, ist unsicher. Beim Feedback-Meeting wird über den Arbeitsstand des Bug Fixing berichtet.

Wie du siehst, gibt es auch keinen Vergleich dessen, was versprochen wird, mit anderen Versprechen in der Vergangenheit. Es findet keine Schätzung statt. „Velocity“ ist kein Konzept in diesem Bild.

Einzig und allein Fortschritt zählt. Verlässlicher Fortschritt - und wo kein Fortschritt, da zumindest kein Rückschritt. Das Feedback muss daher 360° umfassen.

Jetzt kommen doch noch die Anforderungsbereiche ins Bild. Denn was liegt denn 360° um den Empfänger herum? Vor allem ist der natürlich an Wertzuwachs bei Verhaltensanforderungen interessiert. Wert entsteht für ihn, wenn die Software mehr Funktionalität und/oder mehr Effizienz beim nächsten Feedback-Termin bietet als beim vorherigen.

Dazu kann er selbst das Feedback geben. Er hat in dieser Hinsicht klare Erwartungen - selbst wenn er die vor einer Überprüfung nicht immer deutlich vermittelt.

Beim Feedback-Termin darf die Zukunftsfähigkeit jedoch nicht unberücksichtigt bleiben. Denn sonst kommt die Produktivität bald ins Stocken. Also muss auch Feedback zur Korrektheit, vor allem der Regressionsfreiheit, und der Wandelbarkeit (Verständlichkeit, Testbarkeit) gegeben werden.

Das ist allerdings nicht Aufgabe des Empfängers/Kunden, sondern des Architekten. Sein Metier sind die nicht-funktionalen Anforderungen, zu denen nicht nur die Effizienz, sondern auch die Zukunftsfähigkeit gehört.

Nochmal zusammengefasst:

• Produktivität ist die zentrale Anforderung
  • Produktivität ist da, wo verlässlich Fortschritt gemacht wird
    • Verlässlichkeit braucht Takt
      • Für die Festlegung und Einhaltung des Taktes sorgt der Kunde
    • Fortschritt ist, wo Veränderungen an einem Zustand positiv sind und an anderer Stelle zumindest kein Rückschritt stattgefunden hat
      • Die Bewertung des Zustands erfolgt in einem 360° Feedback-Termin
        • Feedback zu Verhaltensveränderungen gibt die Abnahme durch den Kunden
        • Feedback zu Zukunftsfähigkeit gibt der Review durch den Architekten

Ob der Kunde selbst oder ein Stellvertreter an diesem Vorgehen zieht, sei dahingestellt. In Scrum gibt es dafür Rollen: der Scrum Master ist der Takt-Verantwortliche, der Product Owner der Verantwortliche für die Abnahme.

In jedem Fall braucht es aber noch die Architektenrolle, die den Review durchführt. Insbesondere Wandelbarkeit kann der Kunde nicht selbst feststellen; er braucht einen Vertrauten im Team.

Durch diesen Vertrauten in diesem Vorgehen kommt am Ende dann auch Clean Code in die Welt. Deshalb die Überschrift.

Clean Code kann nicht am Anfang stehen. Noch nicht einmal Funktionalität kann am Anfang stehen. Produktivität muss am Anfang stehen. Nur so wird die Bedingung für die Möglichkeit von Fortschritt optimal geschaffen.

Was immer ich an Clean Code Prinzipien und Praktiken mit der CCD School vermittle, ist daher ausschließlich Mittel zum Zweck eines reibungslosen Feedbacks im Review.

TDD, Flow-Design, Slicing, IOSP... das sind alles nur Mittel. Nichts muss, alles kann - wenn dadurch der Review besser ausfällt.

Dahingehend werde ich meine Trainings und Beratungen umstellen. Für mich hat zukünftig die höchste Priorität, den Raum für das Feedback zu schaffen. So lange der nicht verlässlich vorhanden ist, kann ich mir die tollsten Clean Code Tricks sparen.

Wenn in einem Team in den letzten 16 Arbeitsstunden keine Abnahme, kein Review stattgefunden haben, wenn niemand daran zieht… dann ist das der erste Aspekt, an dem gearbeitet werden muss. Solange dafür keine Bereitschaft existiert, ist jede Clean Code Methode überflüssig.

Als erstes muss die Organisation also in den richtigen Takt kommen. Dann und erst dann stellt sich die Frage, was und wie bei der Abnahme und beim Review geprüft wird.

Wie kann ein Team in 16 Stunden etwas Feedbackfähiges für die Abnahme liefern? Wie kann ein Team in 16 Stunden Verhaltensänderungen in eine Software einbauen und dennoch die Wandelbarkeit und Regressionsfreiheit nicht kompromittieren?

Darüber können wir reden, wenn es soweit ist, d.h. wenn ein frustrierendes Feeback nach einer Verönderung in der Entwicklung schreit.

Nicht, dass es in Trainings bisher kein Feedback gegeben hätte. Bisher stand dort jedoch die Stoffvermittlung im Vordergrund. Dann kamen Übungen. Am Ende Feedback. Zukünftig wird es anders herum laufen: Zuerst die Planung des nächsten Feedback-Termins. (Natürlich nicht in 16 Stunden, sondern in 1-2 Stunden.) Dann die Übung. Und wenn die Trainingsteilnehmer durch den Verlauf des Feedback-Termins bereit sind, dann und erst dann werde ich Stoff explizit vermitteln.

Damit vermittle ich nicht nur im Training schon durch die Form, was ich vom Arbeitsalltag erwarte. Ich glaube auch, dass es lernpsychologisch besser ist. Durch die Praxis des Feedbacks wird unmittelbar und sehr konkret die Motivation geweckt, etwas zu lernen.

Die ewig wiederkehrenden Fragen beim Review sind:

• Ist der Code schon korrekt? (Korrektheit/Maturität)
• Ist der Code immer noch korrekt? (Korrektheit/Regressionsfreiheit)
• Ist der Code verständlich? (Wandelbarkeit)
• Ist der Code testbar? (Wandelbarkeit)

Wenn die Fragen zügig und nachvollziehbar mit Ja beantwortet werden können und keine Refaktorisierung nötig ist, dann ist alles gut.

Ist das jedoch nicht der Fall… dann braucht der Review Zeit und mehr Zeit. In der kann keine weitere Verhaltensanforderung bedient werden. Das gefällt dem Kunden nicht. Daraus und nur daraus ergibt sich dann Wunsch und Notwendigkeit, Prinzipien und Praktiken des Clean Code Development zu lernen. So kommt das Geld ins Spiel. Gut so!

PS: Mit diesen Gedanken schließe ich an eine Idee aus dem Jahr 2013 an. Die hatte ich damals unter dem Begriff Spinning in mehreren Artikeln beschrieben. Seitdem war mein Fokus jedoch zu anderen Aspekten der Software gewandert… um nun zurückzukehren. Ich habe einfach zu viele „energielose“ Projekte gesehen, zu viele Teams, die wahrlich „sinnlos“ umherirren.

Unmittelbarer Auslöser war jedoch Frust. Frust darüber mitanzusehen, wie gute Motivation für Clean Code Development im Training bei die Rückkehr in den Arbeitsalltag zerrieben wird in dessen dysfunktionaler Praxis.

Ich musste einsehen, dass meine Art des Trainings zu wenig darauf vorbereitet. Und dass Clean Code Development im Management zu wenig verwurzelt ist.

Deshalb nun (wieder und mehr) Fokus auf das Geld. It’s always the money, stupid! ;-) Und damit auf den Prozess. Denn der ist für Management sichtbar, nicht jedoch die mytische Qualität „Wandelbarkeit“ von Quellcode.