Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Die Ausarbeitung von Architekturspezifikationen und das Simulieren von Ausnahmefällen im Kopf ist verlockend. Der Code im Kopf hat schließlich keine Bugs und ist perfekt. Aber wenn das Nachdenken ohne das Öffnen des Editors zu lange dauert, ist das keine Vorsicht, sondern einfach Angst – genauer gesagt, die Angst vor dem Scheitern. Ein gigantisches Designdokument, das erstellt wurde, um Unsicherheiten zu vermeiden, bricht beim ersten Anforderungswechsel sofort in sich zusammen.
Für Entwickler, die in einer Analyseparalyse feststecken und Zeit verschwenden, haben wir eine Arbeitsweise zusammengestellt, die den Perfektionismus durchbricht und noch heute einen Prototypen liefert.
Das Vergleichen verschiedenster Frameworks und Architekturen, bevor auch nur eine einzige Zeile Code geschrieben wird, führt zu einer extrem hohen kognitiven Überlastung. Sich an der Fehlerbehandlung für eine Wahrscheinlichkeit von unter 0,1 % festzubeißen oder Abstraktionsschichten aufzubauen, obwohl noch nicht einmal die Anforderungen feststehen, ist eine klassische Risiko-Aversion.
Untersuchungen von McKinsey und Leadership IQ bei Fortune-500-Unternehmen zeigen, dass durch Entscheidungsschwäche und übermäßige Analyse jährlich über 53.000 Tage verschwendet werden. Umgerechnet auf die Lohnkosten bedeutet das, dass 250 Millionen Dollar ohne jegliche Ergebnisse im Nuland verpuffen. Auch die persönliche Produktivität von Entwicklern sinkt durch Vorab-Optimierung um über 40 %.
Wenn man das Gefühl hat, dass die Simulation im Kopf zu lange dauert, muss man sie systemisch abbrechen. Man wendet einfach das Spike-Solution-Pattern aus dem Extreme Programming (XP) im Alltag an:
Wer zwei Wochen lang in der Planungsphase feststeckt, hat nicht zu wenige Spezifikationen, sondern keinen Ausführungskontext. In solchen Fällen sollte man alle Designdokumente schließen und ein 30-Minuten-Timeboxing ansetzen.
Ein Prototyp mit 30 % Vollständigkeit lässt die Ausnahmebehandlung, Datenbankintegration und UI-Verfeinerung komplett weg. Es wird nur geprüft, ob bei der Eingabe das gewünschte Ergebnis herauskommt. Genau das ist der Grund, warum Produkttteams im Silicon Valley Meetings nicht mit abstrakten Anforderungsdokumenten, sondern mit direkt funktionierenden Prototypen abhalten. Erst wenn man die Benutzeroberfläche selbst ausprobiert, verschwinden die Unsicherheiten.
Betrachten wir das Ganze anhand der Verzögerungskosten (Cost of Delay). Wenn vier Ingenieure mit einem Wochengehalt von jeweils 2.025 $ zwei Wochen lang nur Architektursitzungen abhalten, entstehen direkte und indirekte Verluste in Höhe von 16.200 $.
| Bewertungskriterium | Spezifikationsbasierte Entwicklung | Prototypenorientierte Entwicklung | Effekt |
|---|---|---|---|
| Definition der Erstanforderungen | 2 bis 4 Wochen (Dokumentenerstellung) | 30 Minuten bis 1 Tag (Spike-Erstellung) | 90 % Zeitersparnis |
| Planungsänderungsmeetings | Durchschnittlich 8 bis 12 Mal (abstrakte Debatten) | Durchschnittlich 2 bis 3 Mal (demonstrationsbasiert) | 70 % weniger Meetings |
| Korrektur von Richtungsfehlern | Kompletter Umbau der Struktur | Verwerfen des 30-Minuten-Entwurfs | Minimierung der Nacharbeitskosten |
| PR-Prüfungsgeschwindigkeit | Es kommt zu Engpässen | Vorab-Veröffentlichung als Draft PR | 30 % schnellere Reviews |
Wenn sich Denken und Implementierung vermischen, blickt man beim Schreiben des Codes ständig zurück. Genau deshalb sollte man die Arbeitszeit eines Tages strikt in eine Analysephase und eine reine Implementierungsphase unterteilen. Das ist vergleichbar mit dem Prinzip „Feste Zeit, variabler Scope“ aus der Shape-Up-Methodik von Basecamp. Man legt die Zeit im Voraus fest und wirft Funktionen weg, wenn sie innerhalb dieser Zeit voraussichtlich nicht fertig werden.
Tritt ein Engpass auf, folgt man als Richtlinie zur Umgehung anstelle von tiefem Grübeln dem Konzept der „bewussten und überlegten Schulden“ aus Martin Fowlers Tech Debt Quadrant. Handelt es sich um Code, der später leicht geändert werden kann, ist es besser, den einfachsten Workaround zu wählen und direkt zu committen.
Jeff Bezos sagte einmal, man solle Entscheidungen treffen und handeln, wenn eine Sicherheit von etwa 70 % erreicht ist. Auf eine Perfektion von über 90 % zu warten, bedeutet, die Geschwindigkeit zu töten.
Wenn man unperfekten Code versteckt, führt das später zu noch größerem Nacharbeitsaufwand. Das Engineering-Team von Shopify erstellt Draft PRs nicht, um perfekt geschriebenen Code prüfen zu lassen, sondern um die Arbeitsrichtung zu validieren.
Es empfiehlt sich, die PR-Größe unter 200 bis 300 Zeilen zu halten. Wenn man einen WIP-Tag mit dem Hinweis „Feedback nur zur Struktur und Ausrichtung des Algorithmus erwünscht“ anbringt, reduziert das auch die Belastung für den Reviewer.
Der initiale Code ist kein Kunstwerk, sondern lediglich eine Hypothese, die es zu überprüfen gilt. Kommt Feedback, setzt man es schnell um und macht weiter.
Eine perfekte virtuelle Architektur kommt nie über den eigenen Kopf hinaus. Die heute geschriebene, unvollkommene, aber funktionierende Codezeile macht die eigene wahre Kompetenz aus. Erst wenn man die Ausrede des Perfektionismus ablegt, entkommt man dem Sumpf der Verzögerungskosten.
