Besuch von Uncle Bob...PowerDays Clean Code. Lieser & Westphal im Interview



#1 Ihr seid die beiden Gesichter der PowerDays Clean Code. Stellt Euch doch bitte kurz vor!

Stefan Lieser:

Stefan Lieser aus Köln, vor 50 Jahren hier geboren. Für das Informatikstudium bin ich nach Koblenz gegangen, habe dort mit zwei Partnern eine GmbH gegründet und bin erst 2000 wieder zurück nach Köln gezogen. Mit kurzer Unterbrechung immer selbstständig. Die Zeit als GmbH Geschäftsführer war sehr lehrreich. In kurzer Zeit auf über 40 Mitarbeiter anwachsen und sehen, dass die Idee trägt, ist eine gute Erfahrung. Allerdings zog es mich dann vom Thema Netzwerktechnik wieder zurück zur Softwareentwicklung. Seit 2008 befasse ich mich gezielt mit der Frage, wie man als Softwareentwickler einen guten Job machen kann. Darunter fallen Überlegungen ganz konkret zum Quellcode, über Entwurf und Testen, bis zum Entwicklungsprozess. Ich bin „gerne Lerner“, da liegt es nahe, das selbst Gelernte an andere zu vermitteln. So schaue ich auf etwa 20 Jahre Erfahrung als Trainer zurück.

 

Ralf Westphal:

Bild vergrößernWohnhaft Hamburg, 53 Jahre und immer selbstständig gewesen. Seit mehr als 30 Jahren inzwischen. Mit der Softwareentwicklung habe ich 1980 begonnen und bin nach Geschäftsführung und Chefredakteurstätigkeit für die BasicPro in die Beratung und das Training und den Fachjournalismus gerutscht. Dabei hat sich über die Jahre und Jahrzehnte auch mein Fokus von (Microsoft) Technologien zum Konzeptionellen verschoben. Und 2008 haben Stefan und ich dann die Clean Code Developer Initiative gegründet, weil wir im Bereich „nachhaltige Softwareproduktion“ ein großes Defizit gesehen haben und immer noch sehen.

 

#2 Die PowerDays Clean Code bestehen aus drei Workshops – Radikale OO, Story Slicing und Mikado Methode. Was dürfen die Teilnehmer von den Workshops erwarten? Und: Habt Ihr vielleicht auch Erwartungen an die Workshop-Teilnehmer?

Stefan Lieser:

Ralf Westphal und ich haben über die Jahre unsere eigenen Ansichten zur Softwareentwicklung vertieft. Wir haben viel ausprobiert und tun dies immer noch. Entstanden ist so eine pragmatische Vorgehensweise, die die Wandelbarkeit von Software in den Vordergrund rückt. Die Teilnehmer erwartet eine Workshopserie, bei der wenig frontale „Druckbetankung“ stattfindet, sondern gemeinsames Erarbeiten von Lösungen zu Übungsaufgaben. Wir beobachten seit vielen Jahren, dass sich Inhalte so am besten vermitteln lassen, in dem Sinne, dass die Teilnehmer das Gelernte hinterher auch wirklich anwenden können.

Ralf Westphal:

Erwarten dürfen die Teilnehmer Ungewöhnliches und Unerwartetes. Ja, das meine ich so, denn ich glaube, dass wir einen Blick auf die Softwareentwicklung vermitteln, der durchaus vom Erwarteten, d.h. vom Mainstream abweicht. Wir sind nicht daran interessiert, die Buzzwords mit den kanonischen Erklärungen wiederzugeben. Bei uns sieht die Interpretation von Objektorientierung oder Agilität oder Clean Code anders aus als woanders, weil wir uns sehr bemühen, von der Essenz auszugehen. Worum geht es wirklich, wirklich? Was steckt echt im Kern? Das treibt uns um. Dazu haben wir Antworten gefunden. Die vermitteln wir mit viel Engagement – so werden die Trainingstage nicht langweilig. Mal wird es richtig ernst, aber meistens ist geht es ganz locker voran.

#3 Was steckt genau hinter dem Begriff „Clean Code“?

Ein Buch von Uncle Bob 😉  Darüber hinaus versteht jeder Entwickler etwas anderes darunter. Ralf und ich haben mit der Clean Code Developer Initiative versucht, Prinzipien und Praktiken zusammenzutragen, die unserer Ansicht nach zu Wandelbarkeit, Korrektheit, Produktionseffizienz und Kontinuierlicher Verbesserung beitragen. Das war allerdings erst der Anfang. Denn die Prinzipien müssen ja auch eingehalten werden. Dazu haben wir über die Jahre mit Flow Design ein konkretes Vorgehen entwickelt. Das wichtigste dabei ist, dass wir eine Lösung immer erst entwerfen, bevor wir sie in Code gießen.

„Clean Code“ ist natürlich auch nur ein Buzzword. Das war und ist nötig, um Aufmerksamkeit zu generieren und Anschlussfähigkeit herzustellen. Dahinter steckt jedoch mehr als „irgendwas mit Code“. Clean Code ist der Oberbegriff unter dem wir all das subsumieren, was hilft, Softwareproduktion heute und in der Zukunft produktiv zu machen bzw. zu halten. Es geht also um Prinzipien der Codestrukturierung, aber auch um die Vorgehensweise bei der Entwicklung oder Kommunikation im Team. Das ursprüngliche Buch von Robert C. Martin mit dem gleichnamigen Titel ist viel enger gefasst. Doch während unserer Arbeit an der Clean Code Developer Initiative haben wir gemerkt, dass mehr dazu gehört. So haben wir über die Jahre eine umfassende Methode entwickelt, quasi eine kleine „vereinheitlichende Theorie der Softwareproduktion“.

#4 Seit wann seid Ihr „clean“ und wie kam es dazu?

In 2008 haben wir zufällig beide das Buch von Bob C. Martin gelesen. Wir waren beide der Ansicht, dass es viele nützliche Prinzipien und Praktiken enthält, dass es darüber hinaus aber weitere gibt. Also haben wir begonnen, die Bausteine aus unterschiedlichen Quellen zusammenzutragen. Da Ralf in Hamburg lebt und ich in Köln, lag es nahe, die Zusammenarbeit über ein Wiki zu organisieren. Schon damals waren wir beide in der .NET Community aktiv, haben Vorträge bei .NET Usergroups gehalten. Da lag es dann irgendwann auf der Hand, dass wir das Wiki öffentlich zugänglich machen. Beim Namen wollten wir uns an das „Clean Code“ Buch anlehnen, um den Drive, der damit in der Community entstanden ist, aufzunehmen.

#5 Was macht das Thema Clean Code so wichtig für Coder? Und falls das Kind schon in den Brunnen gefallen ist: Wie sagt man den Müllhalden den Kampf an?

Es gibt immer wieder Momente da frage ich mich, wieso Entwickler eigentlich einen so schlechten Job machen. Die Gründe sind vielfältig und nicht alles liegt im Verantwortungsbereich von Softwareentwicklern. Aber in mir entstand schon vor vielen Jahren, noch zu Zeiten von VB6, die große Sehnsucht, Entwicklern ein leicht zu lernendes Vorgehen an die Hand zu geben, mit dem die Situation verbessert werden kann. Ich behaupte, dass wir das erreicht haben. Wenn Entwickler sich nicht an Clean Code Developer Prinzipien halten, wird sehr viel Geld verbrannt. Der erste Schritt raus aus der Situation ist die Bereitschaft Neues zu lernen und regelmäßig Weiterbildung zu betreiben.

#6 Was habt Ihr für Erfahrungen mit „Code Reviews“ gemacht?

Wir haben uns früher nicht getraut, einem Team Empfehlungen zu geben, ohne das Team vorher mindestens einen Tag lang zu beobachten. Inzwischen wissen wir, Code Reviews und Retrospektiven können wir blind empfehlen. Der Nutzen ist sehr groß, so dass sich der Aufwand von 30-45 Minuten täglich auf jeden Fall lohnt. In komplexen Prozessen ist Feedback das wichtigste Mittel zur Steuerung. Code Reviews erzeugen Feedback.

Sie finden zu selten statt. Viel zu selten. Ich komme deshalb immer mehr dahin, Code Reviews nicht explizit als eigene Tätigkeit anzusetzen, sondern sie in die Codierung mit einzubauen. Pair Programming ist dafür noch zu schwach. Mob Programming macht das besser: das ganze Team codiert gemeinsam. Diese Praktik wurde von Woody Zuill entwickelt und funktioniert immer wieder sehr befriedigend. Ich setze sie oft in Trainings ein.

#7 Viele Unternehmen scheuen sich davor, „Clean Code“ zu praktizieren. So mancher Entwickler wird das kennen: Man selbst möchte ja gerne „clean“ arbeiten, die Kollegen und/oder Vorgesetzten sind von der „Idee“ aber gar nicht angetan. Das Argument: Horrender Mehraufwand, lange Entwicklungszyklen. Wie lässt sich die Fraktion „Das muss jetzt aber schnell fertig werden. Bloß keine langes Palaver vorneweg!“ von den Vorteilen einer „sauberen“ Herangehensweise denn nun am besten überzeugen? Sind die Bedenken unbegründet und für wen lohnt sich der Switch am meisten?

Hier würde ich zwei Arten von „Gegnern“ unterscheiden: Fundamentalisten und Unwissende. Mit Fundamentalisten kann man nicht diskutieren. An denen ist jedes Argument verschwendet. Ihr Weltbild ist so gestrickt, dass sie keine gegenteiligen Sichtweisen akzeptieren können.

Aber die meisten sind eher Unwissende. Mit denen kann man reden. Da ist meine erste Frage: Weißt du, wie viel dich heute Konflikte kosten? Konflikte sind Diskussionen mit dem Kunden, weil etwas nicht funktioniert oder fehlt, Verzögerungen bei der Auslieferung, langsame Codierung, weil ständig der Debugger angeworfen werden muss, weil jemand den Code nicht versteht, Nachbesserungen wegen Regressionsfehlern usw. usf.

Darauf muss der Unwissende mit Nein antworten. Niemand misst den Aufwand, der in die Lösung all der kleinen und großen Konflikte fließt. Das ist wie beim Bruttosozialprodukt: es steigt immer, egal, ob jemand ein Auto verkauft oder es gegen den Baum fährt. Umsatz wird gemacht. Bei der Softwareentwicklung ist die Maßeinheit der Schweiß auf der Stirn der Entwickler. Solange die ächzen und die Finger auf der Tastatur glühen und auch noch halbwegs regelmäßig irgendwas Neues ausgeliefert werden kann, ist alles ok. Die Entwicklung scheint produktiv. Doch das ist sie nicht. Sie verschwendet Unmengen an Zeit (und damit Geld und Nerven). Ich sehe das in Trainings. Dort kann ich Entwickler genau beobachten. Wohin sie schauen, wie sie tippen (oder auch nicht), wann sie die Maus schubsen… das alles verrät mir etwas über ihre Produktivität bzw. vor allem deren Abwesenheit. Nach einer halben Stunde sind alle geschafft – doch viel ist nicht auf die Straße gekommen. Das liegt einfach daran, weil in keiner Ausbildung und schon gar nicht am Arbeitsplatz vermittelt wird, was systematische Softwareentwicklung ist, also eine, bei der nach einer stringenten Methode vorgegangen wird und Maßstäbe für Handlungen existieren.

#8 Ihr seid viel im Projektgeschäft unterwegs. Was sind die größten Hürden innerhalb von Unternehmen, wenn es um Clean Code geht. Seht Ihr diesbezüglich einen Unterschied zwischen KMUs und Konzernen?

Ohne ständig in Projekten unterwegs zu sein, können wir dennoch beobachten, dass Veränderungsprozesse in Konzernen tendenziell langsamer ablaufen. In inhabergeführten Unternehmen ist die Geschäftsführung meist in den Prozess eingebunden. Wir beginnen dort häufig mit einem Impulstag, der allen beteiligten Rollen im Unternehmen verdeutlichen soll, worum es bei Softwareentwicklung geht, worauf es ankommt, was man alles falsch machen kann. Da Softwareentwicklung immer eingebunden ist in andere Bereiche eines Unternehmens wird der Veränderungs- und Lernprozess beschleunigt, wenn die Rollen in der Umgebung beteiligt sind. Das erleben wir in Konzernen eher nicht. Dort gibt es eher den Trend zur Vereinheitlichung und Prozesse werden immer noch oft von oben verordnet statt von unten zu wachsen.

Wir sind nicht im Projektgeschäft unterwegs. Manchmal möchten wir das wieder – aber dann würde es andererseits auch wieder unsere Zeit für die Vermittlung der Methode beschneiden.

 

#9 Clean Code entlastet das Team langfristig. Seid Ihr oft Zeugen von Aha-Erlebnissen Eurer Kunden? Könnt Ihr uns ein Beispiel aus der Projekt-Praxis nennen?

Wenn wir in Trainings die arbeitsteilige Implementation durchgehen, kommt regelmäßig am Abend das Aha Erlebnis. Jeder Einzelne hat nur einen kleinen Teil beigetragen, doch durch die Zusammenarbeit ist viel zusammengekommen. Da die Integration der Einzelteile reibungslos verläuft, was im Projektalltag eher nicht der Fall ist, sind die Teilnehmer angenehm überrascht, wie einfach Arbeitsteilung doch sein kann.

Aha-Erlebnisse gibt es während der Trainings einige. (Wenn man es als Teilnehmer zulässt, wirklich von überkommenen Vorstellungen mal abzusehen.) Aus der Praxis kann ich berichten, dass z.B. unsere Herangehensweise an TDD einigen schon einen Durchbruch verschafft hat. „Jetzt verstehe ich das!“, „Endlich funktioniert das für mich mit test-first.“ habe ich sogar schon nach offenen Trainings gehört.

#10 Zeit zum Träumen: Was ist Eure Vision von perfekter Softwareentwicklung?

Perfekt gibt es nicht. Aber eine bessere Softwareentwicklung ist immer möglich. Für mich gehört im Kern dazu die ständige Reflexion. Was tue ich? Warum tue ich das? Erziele ich das gewünschte Ergebnis? Wie kommt es zu Konflikten? Welchem Glaubenssatz unterliege ich? Was kann ich besser machen? Das sind Fragen, die automatisch in jedem Kopf kreisen sollten. Immer. Das würde ich dann deliberate practice nennen, „kontinuierliche Verbesserung“.

#11 Welche Blogs zum Thema Clean Code könnt Ihr empfehlen?

Ich schreibe zum Thema Refactoring unter refactoring-legacy-code.net.

 

Ich schreibe unter ralfw.de/blog und ccd-school.de. Und ansonsten ist die Welt bunt. Ich folge keinem speziellen Clean Code Blog, aber ich schaue immer mal wieder bei Robert C. Martin oder Ron Jeffries rein. Ansonsten stolpere ich über das Thema hier und da – und bin leider meistens nicht sehr erfreut.

-> Neugierig auf die PowerDays Clean geworden? Tickets und weitere Infos!

No votes yet.
Please wait...
Christine S. Thon

Christine S. Thon

Erst Media Arts, dann PPC Marketing & Digital Analytics. Jetzt: Zuständig für das gesamte "Marketing-Paket" der GFU Cyrus AG.
Christine S. Thon

Letzte Artikel von Christine S. Thon (Alle anzeigen)

|