SW-Entwicklung – Barbaras Blog

Sandi Metz inspiriert

„Hast du schon die Videos gesehen?“

Diese Frage bezog sich auf drei Videos von Sandi Metz: Polly want a message, All the little things, und Nothing is Something. Thema: refactoring, design pattern, dependency injection, im dritten Video insbesondere auch das null-pattern. Ich hatte die Videos noch nicht gesehen, aber nachdem ich sie gesehen hatte, packte mich wieder die Lust aufs objektorientierte Programmieren.

Ein ganzes Wochenende und noch einige weitere Abende saß ich mit meinem Sohn zusammen vor dem Minecraft-Plugin BetonQuest und wir fingen an einen Teil des Codes (die Events) zu refactorn. Wir probierten das Null-Pattern aus, stolperten über die teilweise „schwierigen“ dependencies und erzeugten zwei erste Pull-Requests.

Da Niki einer der Haupt-Contributoren für BetonQuest ist und Java seine Heimat, fiel es mir als embedded Entwickler doch manches Mal schwer, seinen kleinen Zaubereien zu folgen. Nun will ich mich selber ausprobieren und schau gerade nach einen kleinen eigenen Projekt. Mal schauen, was da noch kommt.

Unterbrechungen

Schon wieder klingelte das Telefon. Ich hatte es gerade 3 Minuten lang geschafft, an meiner Entwickler-Aufgabe zu arbeiten. Ein langwieriges und ermüdendes Thema, das mir nicht viel Spaß machte.

Jede Unterbrechung war eine angenehme Ausrede, die Aufgabe vor mir her zu schieben. Aber so würde ich nie fertig werden. Und das Wochenende rückte auch schon näher, wo war die ganze Zeit geblieben?

Schluss damit!

Nachdem ich aufgelegt hatte, spazierte ich zur Teekanne und goss mir das mittlerweile nur noch lauwarme Gebräu ein und kramte in meiner Toolkiste (= Hirn).

Ein klarer Fall für die Pomodoro, dachte ich: 25 Minuten konzentriert und ohne Unterbrechung arbeiten – ein paar Minuten Pause, dann wieder 25 Minuten Arbeit. Diese Technik hat schon manches Mal geholfen.

Gesagt, getan… Wecker gestellt und los gings.

Zehn Minuten später stand meine Tochter in der Tür. Dann nach fünf Minuten kam eine Anfrage von einem Kollegen per Chat rein. So ging es also nicht. Ich entschloss mich zu drastischeren Maßnahmen.

25 Minuten ohne Unterbrechung wollen möglich gemacht werden. Ich checkte kurz alles: Mail, Chats, offene Anrufe, Termine, Notizen. Gab es etwas mit wirklich höherer Priorität? Gerade stand nichts an. Ich sagte zu meinen Kindern: Hier ist mein Wecker. Wenn der in 25 Minuten klingelt, dann habe ich kurz Zeit für alles was ihr von mir wollt.

Tür zu – im Firmenchat und im Kundenchat auf Abwesenheit mit einer Notiz – Notifications aus – Handy auf „nicht stören“

Ich setzte mir die Kopfhörer auf, um mit einem monotonen Hintergrundgeräusch die Außengeräusche gänzlich zu überdecken. (Ich nehme gerne Meeresrauschen, Flötenmusik von Indianern oder schamanische Trommeln). Jetzt war alles vorbereitet.

Mein Ziel war, in 25 Minuten durch 10 Work Items durch zu kommen. Als der Wecker klingelte war ich erstaunt. Ich hatte zwar nur 8 Items geschafft, war aber viel schneller als sonst in die Arbeit eingetaucht.

Tür auf – ein Glas Wasser – ein kurzer Blick, ob einer was von mir braucht – und schon ging es weiter mit dem zweiten 25-Minuten-Minisprint. Ziel diesmal: 15 Items.

Ich hatte schon gesehen, dass die nächsten Items nicht so komplizierte Fälle sein würden wie im ersten Sprint. Und tatsächlich, als der Wecker wieder klingelte, hatte ich sogar 23 Items geschafft.

Ich machte eine etwas längere Pause, schaute kurz bei meiner Tochter vorbei und wechselte ein paar Worte mit meinem Sohn. Und schon ging es weiter. Nach zwei Stunden hatte ich die Aufgabe fertig. Ich hatte mit einem Aufwand von 6 Stunden gerechnet.

Was sind die Kernpunkte:

Unterbrechungsfreies Arbeiten schafft Freiraum. Am Ende hat man in weniger Zeit mehr geschafft und kann dann ohne Probleme wieder eine Phase mit Gesprächen, Anfragen, Chats und Emails angehen.
Der 25-5 Rhytmus schafft ein konzentriertes Klima mit dem Bewusstsein, dass man zwischendurch Zeit hat, auf das Außen zu reagieren.
Die kurzen Pausen sind wirklich ein Genuss und auch Arbeitszeit. Denn darin entspannt das Gehirn kurz und produziert kreative Ideen. Außerdem denkt man daran, regelmäßig zu trinken.
Klare Regeln und Grenzen sind nötig, auch für einen selbst.
Leider kann man sich nicht immer den Luxus gönnen, alle Kommunikationskanäle abzuschalten. Andere warten auf meine Reaktion oder benötigen Input von mir um weiter zu machen. Aber Hand aufs Herz, was ist effizienter: sofort zu unterbrechen und für andere da zu sein oder den anderen noch den Rest meiner Pomodoro-Zeit geben – vielleicht können sie ihr Problem sogar selber lösen. Wenn ich dann in meiner Pause zu ihnen gehe, ist ihre Unterbrechung eher zielführend, weil sie ja in ihrem Kontext bleiben und meine Hilfe haben möchten.

Die Kosten des Problems

Er war neuen Erkenntnissen zu seinen aktuellen SW-Fehlern auf der Spur. Endlich hatte er eine wichtige Ursache ausgemacht und war bei einer groben Schätzung zu dem Ergebnis gekommen, dass er noch 3 Wochen brauchen würde, alles glatt und sauber zu ziehen. Im besten Fall eine Woche. Die Änderung würde eine Umstrukturierung größerer Programmteile umfassen. Er hatte schon gut eine Woche für die Analyse benötigt und 2 Fixes machen können, die das Problem entschärften.

„Drei Wochen? Wie teuer ist denn das Problem?“, fragte ich ihn.
„Häh?“
„Na ja, das Problem habt ihr ja schon länger. Was passiert aktuell? Was kann im schlimmsten Falle passieren? Wer ist davon wie betroffen?“

Ich wollte ihn motivieren, die Programmierer-Perspektive zu verlassen und sich das Thema von außen anzuschauen.

Wir kamen darauf, dass zur Zeit zur Vermeidung des Problems jeden Tag das System einmal einen Reset machen musste. Wenn jemand einen Fehler in der Konfiguration seiner Export-Task machte, konnte das System Amok laufen. Gelegentlich schlugen ein Export oder ein Import fehl. Das System ist ein Firmen-internes Tool, hat also keinen direkten Impact auf die Kundenanwendungen. Die internen Anwender sind genervt, müssen bei einem Abbruch den Export nochmal starten. Bricht ein Import ab, kann es zu Inkonsistenzen kommen, die man im schlechtesten Fall nicht entdeckt. Das hat dann indirekt Auswirkungen auf die Kundenapplikationen, kann aber durch einen erneuten Import behoben werden.

„Und wie groß ist die Wahrscheinlichkeit, dass ein fehlerhafter Import unentdeckt bleibt?“
„Sehr klein. Eigentlich weiß es jeder, dass man das Ergebnis überprüfen muss.“
„Und der Neustart des Systems?“
„Der ist schon lange automatisiert. Darum braucht sich niemand zu kümmern.“
„Und wie oft treten Fehler auf?“
„Weiß ich nicht.“
„Also kostet es vor allem die Zeit und Nerven der internen Nutzer, die auf das Ergebnis warten, um eine bestimmte Aufgabe weiter zu führen. Um die Kosten des Problems kalkulieren zu können, musst du also herausfinden, wieviel Zeit jede Woche verloren geht, um einen abgebrochenen Task nochmal zu starten.“

Ich erklärte ihm das Prinzip, das ich auf der Architektur-Schulung von Gernot Starke und Peter Hruschka gelernt hatte. (Blog von Gernot und Peter)

Versuche die Kosten, die das Problem verursacht, zu beziffern. Nur wenn die Kosten deutlich höher sind als das Lösen des Problems, lohnt es sich, das Problem zu lösen.

In diesem Fall war das Problem noch nicht komplett gelöst. Mit dem täglichen Neustart, den angewendeten Fixes sollte es nur noch selten auftreten. Eindeutig ein Fall für „Nicht weiter glatt ziehen“.

Es war das erste Mal, dass ich bewusst versucht habe, dieses Prinzip anzuwenden. Interessant war das Gefühl, den Perspektiven-Wechsel zu machen. Dabei konnte man auch schauen, ob es auf anderen Ebenen Lösungen für das Problem gab. Insbesondere fiel es meinem Kollegen diesmal leichter, auch seinen Chef abzuholen und eine differenziertere Entscheidungsgrundlage zu bieten.

Was sind die Kernpunkte:

„Lösungsorientiert“ ist ein schönes Schlagwort, das insbesondere von Managern missbraucht wird, um vermeintlich Kosten zu senken. Oft ist eine Lösung zwar eine Lösung, technisch gesehen sogar manchmal eine gute Lösung, aber vielleicht für das falsche Problem. Das Problem muss erst aus allen Ebenen heraus verstanden werden, bevor man entscheiden kann, in welche Richtung man später Anstrengungen unternimmt.
Oft steckt der Betrachter des Problems zu tief im technischen Detail. Es ist wichtig, die Perspektive zu wechseln und sich alle Auswirkungen nochmal auf der Ebene der Auswirkungen im Prozess anzuschauen. Oft gibt es Zusammenhänge in den Gesamtprozessen des Unternehmens und vielleicht ist die Ursache des Problems in einem ganz anderen Bereich anzusiedeln und nicht da, wo es sich manifestiert.
Für Änderungen auf Architektur-Ebene müssen die Kosten des Problems deutlich kleiner sein als die Kosten zur Behebung des Problems.

Verstehe einer das Konzept!

Verzweifelt saß er vor dem Kotlin Code und versuchte mir das Konzept von Coroutines zu erklären, das er selber noch nicht richtig verstanden hatte.

“Ich weiß nicht, wo diese ganzen Threads entstehen. Das sollte eigentlich nicht passieren. Genau dafür sind Coroutines ja schließlich da …“

„Kennt sich denn niemand bei euch damit aus?”

“Der Autor von dieser Software ist mittlerweile gegangen. Ich werde auf die zwei Java-Experten verwiesen. Aber das sind Java-Experten, keine Kotlin-Experten.”

Ich grübelte an diesem Problem herum. Ein typischer Fall. Man hat wichtige Konzepte – in diesem Fall die einer Programmiersprache – nicht verstanden, um die wirkliche Ursache für die Probleme im System zu verstehen. Geschweige denn lösen zu können. Und der Autor des Systems hatte sie wohl auch nicht verstanden. Wenn man doch jemanden kennen würde, der einem diese Konzepte erklären könnte.

Manchmal hat man so jemanden in seinem Netzwerk, aber den bezahlt die Firma nicht. Dass heißt, Hilfe aus dieser Richtung kann höchstens Impulse setzen. Ich fragte den frustrierten Programmierer: „Such doch mal nach Namen von Leuten, die sich wirklich mit dem Thema auskennen.“

Es war ein kurzer Weg. Auf der Seite des Herstellers von Kotlin wurde der Teamleiter Roman Elizarov erwähnt. Ein Blick in Youtube brachte eine Reihe seiner Vorträge zum Vorschein, die die Konzepte, Goes und No-Goes erklärten. Und drei Stunden später wussten wir, wo in der Architektur der Software grundlegende Fehler waren.

Was habe ich daraus gelernt?

Es ist wichtig, die Grundkonzepte der Tools zu verstehen, die wir benutzen.
Es lohnt sich, nach Blogs, Artikeln und Videos von den Leuten zu suchen, die die Tool durchdrungen haben, vielleicht sogar entwickelt haben.
Und man kann, wenn man dann immer noch nicht weiter kommt, direkten Kontakt aufnehmen.
Für eine Firma würde es sich unter Umständen sogar lohnen, ein paar Beratungsstunden zu kaufen, wenn das schnell und unkompliziert möglich ist.

Leidenschaft durch Zusammenarbeit

Das Wort Zusammenarbeit beinhaltet zwei Teile: „Arbeit“ und „Zusammen“.

Arbeit für sich macht mir meistens schon viel Spaß. Ich liebe es mich tief in ein Thema einzuarbeiten, und weitere Zusammenhänge mit anderen Themen zu erkunden – und dabei etwas zu erschaffen.

Noch mehr liebe ich es, wenn ich dabei mit jemanden zusammen arbeiten kann. Wenn wir gemeinsam die Abgründe durchschreiten und detailverliebt das Werk gestalten.

Im Laufe meines Lebens habe ich schon mit vielen Leuten gearbeitet. Zu jedem Menschen habe ich eine in jeder Weise eigene Beziehung aufgebaut. Manchmal sind diese Beziehungen nur sehr schwach ausgeprägt. Die Wege zu dem anderen sind schwer zu überwinden. Und manchmal ist es wie mit einer neuen Erfahrung. Man macht sie und sie brennt sich innerhalb kürzester Zeit tief in das Hirn ein. Oder wie mit einer gut gelernten Vokabel: man teilt so oft seine Gedanken und Ideen, dass eine tiefe Vertrautheit entsteht.

Wenn ich auf solche Menschen treffe, ist die Arbeit am Schönsten. In diesen Projekten entsteht Leidenschaft. Und auch wenn ich mit den Menschen später nicht mehr zusammen arbeite, weil wir in ganz unterschiedlichen Projekten landen oder das Projekt beim Kunden zu Ende ist, bleibt doch diese besondere Verbindung erhalten und flackert mit jedem Blick und Wort, das man wechselt, mit jedem Gedanken an den anderen neu auf.

Das gleiche Ziel aus zwei Richtungen ansteuern

Es war einmal die Idee, dass der eine den Code schreibt und der andere den Code testet. Schöne Welt des V-Modells. Ich habe in vielen Projekten mal die eine und mal die andere Seite erlebt. Meistens hat man als Tester den Frust, dass man zwar viele oder zumindest einige Fehler findet, der Programmierer aber schon längst an einer anderen Ecke arbeitet und gerade gar keine Zeit für alte Bugs hat. Im modernen Fachjargon nennt man das auch technical dept. Dafür brauchen wir dann Jira und mindestens 10 Minuten, wenn nicht sogar länger, um diese Bugs unvergesslich zu machen.

Die agile Welt verspricht da Abhilfe. Aber:

Interessanterweise haben es viele Projekte in unseren Regionen geschafft, sich agil zu nennen, obwohl sie immer noch nach dem V-Modell arbeiten. Im ersten Sprint werden Requirements gemacht, dann gibt es vielleicht ein Konglomerat von Design und Entwicklung. Und wenn die Entwickler ihren Sprint fertig haben, dann können die Tester einen Testsprint auf das entwickelte Zeug hinlegen.

Da besteht wohl ein heftiges Missverständnis. Dieses Vorgehen verletzt eines der grundlegendsten Prinzipien der agilen Software-Entwicklung und die Beteiligten sind sogar noch stolz darauf. Es geht um das Prinzip, dass am Ende jedes Sprints ein lieferbares Produkt steht. Und ein Produkt ist auch gemäß V-Modell erst lieferbar, wenn der Test erledigt ist. Andere Projekte führen dafür irgendwann die „Null-Bug-Policy“ ein. Komisch eigentlich, denn das sollte doch in meinen Augen selbstverständlich sein. Denn ist fertig fertig, oder wollen wir unseren Test beim Kunden machen?

Vor allem entgeht allen Mitarbeitern eine echt tolle Erfahrung, die ich in (mindestens) einem unserer Projekte machen konnte – und das obwohl wir uns nicht „agil“ schimpften (denn das waren wir noch lange nicht). Wir haben unsere Arbeit auch in kleine Pakete aufgeteilt, dynamisch entschieden, welche Pakete wir zuerst bearbeiten und die Rollen aufgeteilt. Ein Kollege hat die Integrationstests übernommen und die Entwickler konnten ihre Modultests jeder nach seinem Geschmack selber gestalten. Der Tester entwickelte gleichzeitig mit uns die Integrationstests. Er wusste ja auch, was am Ende rauskommen sollte. So hatten wir eigentlich immer zur gleichen Zeit die Tests und den Code fertig. Wenn wir beide soweit waren, haben wir uns gleich zusammengesetzt, die Tests laufen gelassen und gemeinsam nach den Fehlern gesucht. Und zwar sowohl in den Tests als auch im Code. Denn jeder schreibt Bugs. (Frei nach James Grenning)

Es gab mehrere Dinge, die daran toll waren. Erstens war es unsere gemeinsame Arbeit. In der klassischen Rollenaufteilung gerät man oft in ein Gegeneinander. Zweitens war ich gerade bei meinem Code im Saft und wenn der Test einen Fehler geliefert hat, war es sehr leicht, die Ursache zu finden. Drittens haben wir dabei nebenbei Code- und Testreviews gemacht.

Bekanntermaßen finden man neben einem Fehler gleich noch ein oder zwei andere. Das liegt daran, dass es Phasen gibt, in denen man nicht so konzentriert arbeiten kann und dann macht man eben mehr Fehler auf einmal. So konnten wir gleich noch ein kleines Refactoring machen und uns sind dabei noch fehlende Testfälle eingefallen. Wichtig für Regressionstest. Wir hatten ein gutes Gefühl, dass der Code so passt, weil wir auch an einige Sonderfälle gedacht haben.

Und es hat einfach tierisch Spaß gemacht. Wir beide haben gemerkt, wie wichtig die Aufgabe des anderen ist. Wir konnten uns direkt gegenseitig unsere Anerkennung und Wertschätzung zum Ausdruck bringen. Und das haben wir uns doch auf unsere Fahnen geschrieben, oder?

Ruf an!

Was ist weit weg?

„Was heißt noch mal Tschüß auf ungarisch? War das Szio?“ „Wie? Nein Szia!“ „Und wenn man mehreren Leuten Tschüß sagt?“ Verwundertes Zögern – dann: „Sziastok“. Ein kleiner Stein mehr im Brett. „Du sollst endlich Wochenende machen“, kommt aus Budapest. „Mach ich doch. Ich steppe zwischen den Mails.“

Was macht Zusammenarbeit wirklich aus? Die räumliche Nähe ist es nicht. Zumindest heutzutage nicht mehr. Wenn ich den ganzen Tag mit meinem Kollegen aus Ungarn telefoniere, chatte und maile, verbringe ich subjektiv mehr Zeit mit ihm als mit meinem Gegenüber, der in einem ganz anderen Projekt unterwegs ist. Per Teamviewer kann man gemeinsam die Modelle oder den Code diskutieren. Es gibt Jenkins-Server, auf denen man zusammen die Compilierungsergebnisse anschauen kann.

Der wirklich entscheidene Punkt aber ist das persönliche Gespräch. Bei mir dauert es immer ein bisschen, bis das Eis gebrochen ist und ich mich überwinde, zum Telefonhörer zu greifen. Ich liebe es, Mails zu schreiben, man kann sich Zeit lassen beim Formulieren, man kann alle wichtigen Punkte ordentlich auflisten und vergisst dann auch nichts.

Aber die letzten Jahre und Projekte haben gezeigt, dass Mail sehr uneffektiv ist. Oft wird nur die erste Frage beantwortet oder mir geht es oft so, dass ich eine Mail auf meinem Smartphone lese, wo ich sie nicht bearbeiten kann – und dann vergesse.

In meinem jetzigen Projekt hat es fast ein halbes Jahr gedauert bis das verbindende Telefongespräch kam. Und kaum telefoniere ich öfter, merke ich, wie die Zusammenarbeit auflebt. Es ist fast so, als würden wir nebeneinander sitzen.

Ungenügende Absprachen

Wer kennt es nicht. Eben ist die Welt noch in Ordnung. Ich bin stolz, wie ich die verschiedenen Herausforderungen bewältige. Und dann treffe ich eine Entscheidung. Erst mal sieht alles gut aus. Aber kurze Zeit später merke ich: „Das war wohl nichts!“ So ging es mir in den letzten Tagen einige Male. Grund genug, das zum Thema der Woche zu küren.

Die Situation: Nachdem ich meine Analyse meinem Kunden vorgestellt hatte, erhielt ich erst mal keine Antwort. Da mir klar war, dass ich so oder so mit einem der Themen beginnen muss, beschloss ich, die Arbeit anzugehen. Es ging prima voran und bald konnte ich die ersten Ergebnisse einchecken. In der Zwischenzeit hatte ich auch schon kurz Rückmeldung bekommen, dass die Mails angekommen waren und auf einige meiner Fragen Antwort bekommen.

Als ich allerdings eingecheckt hatte, kam ein Aufschrei. Nein, so schlimm war es natürlich nicht, es war eigentlich nur die Bitte, dass wir uns doch erst absprechen müssten. Aber in dem Augenblick, in dem ich die Mail las, wurde mir klar, dass ich etwas voreilig gehandelt hattte. Insbesondere hatte ich nicht klar abgesprochen, ob die Richtung, die ich eingeschlagen hatte, gut war.

Das ist jetzt insgesamt kein Beinbruch, aber unangenehm angefühlt hat es sich schon. Obwohl ich genau weiß, wie wichtig klare Kommunikation ist, tappe ich immer wieder in die gleiche Falle. Ich mache nur halbe Absprachen und denke, dass der Rest dem anderen schon klar ist. Wenn sowas passiert, mache ich mir oft nachts noch Gedanken, wie ich das jetzt wieder ausbügeln kann. Auf jeden Fall schießt mir im ersten Augenblick das Adrenalin ins Blut und dann beschäftigt mich die Situation noch einige Zeit.

Ich bin natürlich sofort auf das Gesprächsangebot eingegangen und nach einem ausführlichen Telefonat war klar, wie wir unsere Arbeit koordinieren – und ich konnte einige unverhofft schöne Aufgaben übernehmen.

In diesem Fall ist die Geschichte positiv für mich ausgegangen.