Am Anfang eines größeren Projekts steht bei mir heute oft erstaunlich wenig. Manchmal ist es nur ein Satz, eine Beobachtung oder das Gefühl, dass sich ein bestehender Ablauf besser lösen lassen müsste.
Früher hätte ich wahrscheinlich relativ schnell angefangen, über Datenmodelle, Klassen, Benutzeroberflächen oder technische Komponenten nachzudenken. Heute versuche ich genau das zunächst zu vermeiden.
Ich beginne nicht mit Code.
Ich beginne mit Fragen.
Die erste Idee landet bei mir meistens in ChatGPT. Dort beschreibe ich zunächst, was mir vorschwebt, ohne schon jedes Detail geklärt zu haben. Anschließend lasse ich mir Fragen stellen. Viele Fragen. Bei größeren Themen können daraus sehr lange Gespräche werden.
Das Ziel dabei ist nicht, möglichst viel Text zu produzieren. Ich möchte herausfinden, welche Entscheidungen in meiner ersten Idee noch fehlen.
Eine Idee ist noch keine Anforderung
Eine Produktidee klingt am Anfang häufig erstaunlich vollständig.
„Ich möchte ein System, das meine IT-Geräte automatisch erkennt und darstellt.“
„Ich möchte eine Anwendung, mit der ein Kunde unterwegs Informationen erfassen kann.“
„Ich möchte Aufgaben automatisch von Codex bearbeiten lassen.“
Solche Sätze erklären schon ziemlich gut, worum es grundsätzlich geht. Für eine Umsetzung reichen sie aber nicht annähernd aus.
Schon nach wenigen Rückfragen entstehen neue Themen.
Wer darf die Funktion benutzen? Welche Daten müssen gespeichert werden? Was passiert, wenn eine Verbindung abbricht? Was bedeutet „automatisch“ genau? Welche Informationen sind zuverlässig und welche nur Schätzungen? Was passiert bei widersprüchlichen Daten? Welche Funktionen gehören ausdrücklich nicht zum ersten Stand? Welche Entscheidungen dürfen später noch verändert werden, ohne die Architektur neu bauen zu müssen?
Je länger ich mich mit einer Idee beschäftige, desto deutlicher wird meistens, wie viele Annahmen ich im Kopf bereits getroffen hatte, ohne sie jemals ausgesprochen zu haben.
Genau dort hilft mir ChatGPT am meisten.
Mein heutiger Entwicklungsprozess ist stark davon geprägt, Anforderungen aus mehreren Blickwinkeln zu betrachten. Bei der Konzeptarbeit versuche ich deshalb nicht nur zu beantworten, was eine Funktion im Normalfall tun soll. Ich möchte auch wissen, wo sie scheitern kann, wer sie später benutzen soll und welche Auswirkungen eine Entscheidung auf andere Bereiche hat.
Ich lasse ChatGPT bewusst fragen
Viele Menschen benutzen ChatGPT vor allem, um Antworten zu bekommen. Bei größeren Softwarethemen benutze ich es oft in die andere Richtung.
Ich möchte Fragen bekommen.
Dabei geht es nicht um irgendeinen festen Katalog. Je nach Thema interessieren mich unterschiedliche Bereiche. Bei einer Benutzeroberfläche sind Bedienung und Verständlichkeit wichtig. Bei einer Netzwerkfunktion spielen Sicherheit, Erreichbarkeit und Fehlerfälle eine größere Rolle. Bei einer automatisierten Aufgabe kommen zusätzlich Zustände, Abhängigkeiten, Wiederholungen und Abbruchbedingungen hinzu.
Eine Frage führt dabei häufig zur nächsten.
Wenn ich entscheide, dass eine Aufgabe automatisch wiederholt werden darf, entsteht sofort die nächste Frage: Wie oft?
Wenn ich sage, dass nach drei Fehlversuchen Schluss sein soll, stellt sich die Frage: Was genau gilt überhaupt als Fehlversuch?
Wenn ich festlege, dass Codex das entscheiden soll, muss wiederum geklärt werden, wie Codex diese Entscheidung an das übergeordnete System zurückmeldet.
So wächst das Konzept nicht wie eine Checkliste, sondern eher wie ein Baum.
Eine beantwortete Frage schließt ein Thema. Gleichzeitig öffnet sie möglicherweise zwei neue.
Ich möchte Entscheidungen möglichst früh treffen
Das klingt zunächst sehr nach klassischer Vorabplanung. Und tatsächlich plane ich heute an manchen Stellen wieder deutlich ausführlicher, bevor die eigentliche Implementierung beginnt.
Der entscheidende Unterschied ist für mich aber, dass diese Planung nicht starr sein muss.
Wenn ich nach zwanzig Fragen feststelle, dass die ursprüngliche Idee nicht sinnvoll ist, ändere ich sie. Wenn sich zwei Anforderungen widersprechen, kann ich sie neu bewerten. Wenn aus einer kleinen Funktion plötzlich ein eigenständiges Modul wird, kann die gesamte bisherige Diskussion neu strukturiert werden.
Das kostet vergleichsweise wenig.
Gerade deshalb lohnt sich für mich heute eine Tiefe in der Anforderungsanalyse, die ich früher bei kleinen oder mittleren Projekten vermutlich nicht betrieben hätte.
Ob diese Arbeitsweise eher an Wasserfall, agile Entwicklung oder etwas völlig anderes erinnert, ist für mich selbst eine interessante Frage. Auf den ersten Blick wirkt eine ausführliche Spezifikation sehr klassisch. Gleichzeitig bleibt sie während des gesamten Gesprächs beweglich.
Ich würde das deshalb eher als eine intensive Discovery-Phase betrachten, an deren Ende ein belastbares Arbeitsdokument steht.
Irgendwann müssen die Fragen aufhören
Ein Konzept wird nie vollständig.
Das ist ein wichtiger Punkt, weil die Methode sonst schnell absurd werden könnte. Wenn man lange genug fragt, findet man immer noch einen weiteren Sonderfall, eine mögliche spätere Erweiterung oder irgendeine theoretische Ausnahme.
Mein Ziel ist deshalb nicht, wirklich an alles gedacht zu haben.
Das wäre ohnehin unrealistisch.
Ich möchte an genügend Dinge gedacht haben, damit Codex bei der Umsetzung nicht ständig Produktentscheidungen für mich treffen muss.
Das ist für mich die entscheidende Grenze.
Technische Detailentscheidungen darf und soll Codex treffen, wenn sie sich aus der vorhandenen Architektur und den Anforderungen sinnvoll ableiten lassen. Wenn es aber darum geht, wie sich das Produkt fachlich verhalten soll, möchte ich diese Entscheidung vorher getroffen haben.
Je größer und grundsätzlicher eine Entscheidung ist, desto weniger möchte ich, dass sie während der Implementierung nebenbei entsteht.
Aus dem Gespräch wird eine Markdown-Datei
Wenn das Konzept ausreichend weit entwickelt ist, lasse ich das gesamte Gespräch konsolidieren.
Das Ergebnis ist bei mir meistens eine Markdown-Datei.
Diese Datei ist die eigentliche Übergabe zwischen der Konzeptphase und Codex.
Darin stehen nicht einfach alle Fragen und Antworten chronologisch untereinander. Das wäre für die Umsetzung kaum hilfreich. Stattdessen wird aus dem Gespräch eine strukturierte Spezifikation.
Dazu gehören je nach Projekt beispielsweise:
- Ausgangslage und Ziel
- gewünschtes Verhalten
- Benutzerabläufe
- fachliche Regeln
- technische Rahmenbedingungen
- Abhängigkeiten
- Fehlerfälle
- Sicherheitsanforderungen
- bewusste Abgrenzungen
- noch offene Punkte
- Test- und Akzeptanzkriterien
Die Markdown-Datei ist damit wesentlich mehr als ein langer Prompt.
Sie ist das verdichtete Ergebnis der Konzeptarbeit.
Danach übernimmt Codex eine andere Rolle
Mit dieser Datei wechsle ich zu Codex.
Ab diesem Punkt erwarte ich nicht mehr dieselbe Art von Gespräch wie in ChatGPT. Codex arbeitet näher am tatsächlichen Projekt. Es kann das Repository analysieren, vorhandene Strukturen berücksichtigen und feststellen, wie sich das neue Konzept technisch in das bestehende System einfügt.
Gerade bei größeren Projekten ist das wichtig.
Eine fachlich sinnvolle Idee kann technisch mehrere vorhandene Komponenten betreffen. Ein neues Feature kann Datenmodell, Benutzeroberfläche, Schnittstellen, Hintergrunddienste und Tests gleichzeitig verändern.
Codex soll deshalb nicht einfach die Markdown-Datei lesen und blind anfangen, Dateien zu verändern.
Es soll zunächst verstehen, was bereits vorhanden ist und welche Auswirkungen das Konzept darauf hat.
ChatGPT und Codex haben in meinem Prozess deshalb bewusst unterschiedliche Aufgaben. Das eine System hilft mir dabei, herauszufinden, was ich eigentlich bauen möchte. Das andere arbeitet näher an der Frage, wie dieses Ziel innerhalb des vorhandenen Systems umgesetzt werden kann.
Bei größeren Themen entsteht daraus nicht sofort Code
Eine weitere Veränderung meiner Arbeitsweise ist Agenda.
Bei umfangreicheren Konzepten soll Codex nicht zwingend direkt mit der Implementierung beginnen. Stattdessen zerlegt es die Spezifikation in einzelne Aufgaben und trägt diese in Kosmos.Agenda ein.
Damit entsteht zwischen Konzept und Umsetzung noch eine weitere Ebene.
Aus einer größeren Idee werden mehrere möglichst eigenständige Arbeitspakete. Abhängigkeiten können sichtbar gemacht werden. Aufgaben können priorisiert werden. Vor allem kann ich entscheiden, welche Arbeit tatsächlich gestartet werden darf.
Das gefällt mir aus zwei Gründen.
Zum einen muss Codex nicht versuchen, ein großes Konzept in einem einzigen Arbeitsgang vollständig umzusetzen.
Zum anderen behalte ich einen klaren Freigabepunkt.
Ich kann ein komplettes Thema vorbereiten lassen, ohne damit automatisch alle Änderungen zu starten.
Erst wenn ich eine Aufgabe freigebe, beginnt die eigentliche Umsetzung.
Meine Rolle verschiebt sich dadurch
Früher bestand ein erheblicher Teil meiner Entwicklungsarbeit daraus, die konkrete Umsetzung selbst durchzuführen.
Heute verschiebt sich das immer stärker.
Ich verbringe mehr Zeit damit, die richtige Frage zu stellen, Entscheidungen zu treffen, Anforderungen zu präzisieren und zu beurteilen, ob ein Ergebnis wirklich zu meinem ursprünglichen Ziel passt.
Die eigentliche Implementierung wird dagegen zunehmend delegierbar.
Das bedeutet nicht, dass ich weniger über Software nachdenke. In manchen Bereichen denke ich sogar mehr darüber nach als früher.
Ich denke nur auf einer anderen Ebene.
Statt mich sofort damit zu beschäftigen, wie ich eine bestimmte Klasse schreibe, beschäftige ich mich zunächst damit, ob diese Klasse beziehungsweise die Funktion dahinter überhaupt existieren sollte, welches Verhalten sie haben muss und welche Auswirkungen daraus entstehen.
Die Methode funktioniert nicht automatisch
Auch dieser Prozess hat Schwächen.
ChatGPT kann wichtige Fragen übersehen. Es kann sich an einer falschen Annahme festhalten. Es kann Nebenthemen zu wichtig nehmen und zentrale Punkte zu schnell abhaken.
Eine ausführliche Diskussion erzeugt außerdem nicht automatisch eine gute Spezifikation.
Wenn ich widersprüchliche Entscheidungen getroffen habe, können diese auch in einer sehr langen Markdown-Datei widersprüchlich bleiben.
Und selbst eine hervorragende Spezifikation garantiert nicht, dass die Umsetzung richtig wird.
Danach kommen schließlich noch Entwicklung, Tests, Integration und Betrieb.
Deshalb sehe ich diesen Prozess nicht als Methode, mit der ich Fehler abschaffe.
Ich versuche lediglich, Fehler möglichst früh entstehen zu lassen – nämlich in einem Gespräch, in dem sie billig korrigiert werden können, statt später in einer fertigen Implementierung.
Für mich beginnt Entwicklung heute früher
Früher hätte ich den Beginn eines Softwareprojekts wahrscheinlich ungefähr dort gesehen, wo die ersten Dateien, Klassen oder Datenbanken entstehen.
Heute beginnt Entwicklung für mich deutlich früher.
Sie beginnt bei der ersten Frage:
Was möchte ich eigentlich erreichen?
Und direkt danach kommt die wichtigere:
Woran habe ich dabei noch nicht gedacht?
Genau diese zweite Frage ist für mich einer der größten Vorteile von ChatGPT in meiner heutigen Arbeitsweise.
Erst wenn darauf genügend Antworten gefunden wurden, bekommt Codex Arbeit.
Und selbst dann ist die Spezifikation nicht in Stein gemeißelt. Neue Erkenntnisse können jederzeit dazu führen, dass ich zurück in die Konzeptphase gehe, Entscheidungen ändere und die nächste Runde beginne.