Vor ungefähr einem Jahr habe ich den Talk „The Best Programmer I Know“ von Daniel Terhorst-North von der GOTO-Konferenz 2024 in Amsterdam gesehen. Einige von Euch kennen diesen Vortrag sicherlich (falls nicht, findet ihr ihn auch nochmal direkt am Ende des Artikels). Daniel spricht darin über einen Kumpel, der für ihn der beste Entwickler ist, den er kennt (wie der Titel auch schon vermuten lässt). In dem Talk beschreibt er nacheinander Verhaltensweisen dieses Kumpels, die ihn aus Daniels Sicht auszeichnen.

Der Talk ist hervorragend und einige seiner zentralen Punkte sind mir bis heute sehr präsent im Kopf geblieben, derart, dass ich immer wieder versuche, einiges davon bewusst in meine täglichen Arbeit einfließen zu lassen. Viele seiner Punkte sind nämlich nicht spezifisch für Programmierung, sondern lassen sich wunderbar und unverändert auf viele andere Bereiche der Softwareentwicklung, insbesondere auch auf Architekturarbeit übertragen.

Von diesen Punkten will ich hier einen aufgreifen, der mir in besonderer Weise im Kopf geblieben ist, vor allem, weil ich mich während des Schauens ertappt gefühlt habe: Just Start!

Just Start

Als ersten Punkt, der seinen Kumpel auszeichnet, nennt Daniel die Fähigkeit, die Arbeit erledigt zu bekommen („He gets the job done.”). Das macht er, indem er der Versuchung widersteht zu prokrastinieren und einfach anfängt Code zu schreiben. Vielen Menschen fällt es schwer einfach loszulegen, unter anderem, weil sie den Anspruch haben, ein tolles Ergebnis zu produzieren. Damit steigt der Druck und anzufangen wird zu einem riesigen Hindernis, dessen Überwindung extrem schwierig wird. Wo soll man da anfangen? Also sitzen sie vor dem weißen Blatt, denken nach, lesen noch etwas nach und plötzlich sind Stunden vergangen, aber ohne Ergebnis:

„I have always struggled with just starting. What I do is, I procrastinate. I don’t call it procrastinating, I call it „research“ I call it „looking up things“ I call it „preparing myself“. It’s procrastinating. […] When I put code into a computer, I want it to be good code. I am proud, I call it perfectionism. Perfectionism isn’t about wanting to build the perfect thing, it is about having a very fragile ego and not wanting to get wounded.“

Ich kenne das bei der Architekturarbeit genauso. Es gibt dutzende Anforderungen zu beachten, viele Dinge, die man gerade nicht weiß, verschiedenste Möglichkeiten etwas umzusetzen und alles versucht man im Arbeitsgedächtnis zu behalten und dafür ein funktionierendes, geeignetes und gleichzeitig elegantes Design hinzustellen. Schwierig. Dafür den ersten Pinselstrich zu machen ist eine riesige Überwindung.

Sketch and Iterate Wildly

Der Schlüssel um diese Hürde zu überwinden ist ein einfaches Umdenken: Wir fangen nicht an ein Meisterwerk zu erschaffen, sondern wir beginnen mit einer Skizze (mit Bleistift und Radiergummi, sozusagen). Dabei akzeptieren wir, dass das, was wir jetzt hinschreiben oder aufmalen, in zehn Minuten so nicht mehr existieren wird. Also können wir irgendetwas hinschreiben; es muss nicht toll sein, es muss noch nicht mal komplett richtig sein, Hauptsache es ist etwas da. Denn Dinge die schon dastehen, muss ich nicht mehr alle gleichzeitig in meinem Kopf haben. Und damit weiterzumachen ist viel leichter, als vorher tausende Optionen zu durchdenken. Und alleine damit habe ich mich freigemacht, vom Erfolgsdruck, der größten Hürde, die mich vom Loslegen abhält.

Über die Skizze iterieren wir dann so lange, bis sie uns gut genug erscheint. Und anstatt zu versuchen, alles am Anfang zu wissen, zu lernen und perfekt hinzubekommen, akzeptieren wir, dass wir wiederholt Schrittchen machen, die alle nicht perfekt sind, aber uns sukzessive dem Ziel näher bringen:

„Rather than waiting until I learned Node.js, learned React, learned Rust, learned CQRS, the thing whatever it is I am going to try and do, I just iterate through it. And I iterate knowing I’m gonna mess it up. And knowing that every time I mess it up I learned a tiny thing. So I come out the other side the person who knows the thing now. But I’ve got no idea what the journey was going to look like until I took it. So just start.“

Bei Architekturarbeit ist es genauso: Ich kann nicht alles wissen, bevor ich loslege um ein Design zu entwickeln: Alle Anforderungen, die in der Zukunft kommen werden, alles was in der Domäne wichtig ist, jedes Architekturmuster, das potentiell zum Einsatz kommen könnte, etc. Aber all das zu wissen ist keine Voraussetzung, um loszulegen. Sonst hänge ich nämlich in der „Analysis Paralysis“ fest. Stattdessen ist es wichtig ein Design hinzulegen, das ich nutzen kann, um dann mit Leuten darüber zu sprechen und es kontinuierlich weiterzuentwickeln.

Natürlich sollte ich auch vermeiden, völlig blauäugig loszulaufen. Mit keinen oder unpräzisen Anforderungen oder völlig ohne Domänenwissen ein System entwickeln zu wollen ist naiv. In so einer Situation müssen wir selbstverständlich mehr an den Voraussetzungen arbeiten.

Wenn man aber einen ausreichenden Stand geschaffen hat, muss es losgehen. Durch die Arbeit am Design lernt man nämlich wiederum auch für die Anforderungen, denn Anforderungen und Architekturdesign bedingen sich gegenseitig (siehe Twin Peaks-Modell) und so kann man Anforderungen und Design gemeinsam iterativ weiterentwickeln.

Remove Impediments

Loslegen ist also der Schlüssel um Fortschritt zu machen und die Arbeit zu erledigen. Damit wir aber gut loslegen können, müssen wir versuchen, möglichst viele Hürden zu beseitigen, die uns daran hindern. Dafür einige Tipps:

• Annahmen treffen: Wie oben erwähnt, wissen wir nicht alles. Aber anstatt zu versuchen alles nachzulesen oder mit Leuten zu klären, die dann sicher gerade nicht verfügbar sind, etc. können wir einfach Annahmen treffen. Damit können wir jetzt einfach weitermachen und Fortschritt generieren. Wichtig ist, dass wir diese Annahmen ebenfalls aufschreiben, so dass wir diese später hinterfragen und bei Bedarf ändern können.
• Low-Fidelity Design: Um loszulegen brauchen wir kein elaboriertes Modellierungswerkzeug, denn dann sind wir mehr damit beschäftigt, uns um Formalia und definitorische Feinheiten zu kümmern, als inhaltlich voranzukommen („Verstecken hinter Arbeit“). Alles was wir brauchen ist ein Blatt Papier und einen Stift, oder, maximal Draw.io, o.ä. Wir wollen keine finale Spezifikation erstellen, sondern Ideen ausarbeiten.
• Das Naming Things-Loch vermeiden: Naming things ist eins der zwei schwierigen Probleme der Informatik. Haltet Euch beim Loslegen nicht damit auf. Man kann Stunden damit zubringen über den besten Namen für eine Entität zu philosophieren. Darum geht es jetzt aber nicht und hält uns nur vom Vorankommen ab. Vergebt einen Namen, der erstmal gut genug ist (zur Not „Klaus“) und weiter geht’s.
• Gedanken aufschreiben: Wenn es mir schwerfällt loszulegen, hilft es mir auch häufig meine Gedanken einfach aufzuschreiben, unter Umständen auch genau so, wie ich sie im Kopf habe. Das können Dinge sein, die ich schon sicher weiß, Fragen, die ich gerade nicht beantworten kann, Folgerungen, die sich aus Sachverhalten ergeben, Dinge, auf die ich im Design achten muss, usw. Auch hier gilt, wenn sie aufgeschrieben sind, muss ich sie nicht mehr im Arbeitsgedächtnis behalten und es fällt mir leichter, mich auf das Wesentliche zu konzentrieren.
• Und wenn ich trotzdem nicht vorankomme, hilft es mir in den allermeisten Fällen, mich mit einer Kolleg:in darüber auszutauschen. Ähnlich wie beim Rubber Duck Debugging, hilft allein die Verbalisierung dessen, wo man gerade steht und warum man es gerade nicht schafft loszulegen häufig schon dabei den Knoten zu zerschlagen.

Fazit

Einfach loslegen ist der erste Schritt um gute Ergebnisse zu produzieren. Und das gelingt am einfachsten, indem wir unsere Haltung zu dem, was wir machen, nur leicht ändern: Wir akzeptieren, dass das, was wir machen, eine temporäre Skizze ist. Über die drehen wir so lange Iterationen, bis das Ergebnis gut (genug) ist. Das gilt bei der Programmierung genauso wie beim Architekturdesign.

Ich finde es auch nicht immer leicht, so zu agieren. Aber diese Geisteshaltung und die Verhaltensweise kann man üben. Und das sollte man auch, denn „done is better than perfect“. Also, legt einfach los.

Hier ist das Video zum Nachschauen. Viel Spaß!

Nachtrag

Der eine oder andere Spürhund unter Euch hat vielleicht einen (zumindest augenscheinlichen) Widerspruch entdeckt: Der erste Satz auf meiner Team-Seite lautet: Wenn ich eins nicht leiden kann, dann ist das „einfach mal loslegen“. Wie passt das zusammen mit diesem Artikel? Ich beziehe mich an den jeweiligen Stellen auf unterschiedliche Arten des Loslegens: Ich finde es nicht gut, ohne einen guten Plan einfach mit der Umsetzung anzufangen („Wird sich später schon alles finden.“). Andererseits finde ich es aber total gut, ohne Zaudern anzufangen einen solchen Plan zu entwickeln. Auf letzteres bezieht sich dieser Artikel.