Warum diese Phase unterschätzt wird

Entwicklung ist die Phase, die jeder kennt. Wenn jemand fragt, was Softwareentwickler eigentlich tun, lautet die Antwort fast immer: Sie schreiben Code. Das stimmt und es ist gleichzeitig die oberflächlichste Beschreibung, die man geben könnte. Denn während alle anderen Phasen im SDLC erklärungsbedürftig sind, gilt die Entwicklung als selbstverständlich. Sie ist das Sichtbare, das Greifbare, das, wofür Entwickler bezahlt werden. Genau diese Selbstverständlichkeit ist das Problem.

Die verbreitete Vorstellung sieht so aus: Das Design ist fertig, die Anforderungen stehen, jetzt muss nur noch gebaut werden. Die Entwicklung ist Ausführung, keine Denkarbeit. Code schreiben ist Handwerk, kein Entwurf. Wer das glaubt, behandelt die Entwicklungsphase konsequenterweise als reine Produktionsstrecke. Tickets rein, Features raus. Velocity messen, Burndown-Chart beobachten, Fortschritt in Story Points ausdrücken.

Ein Muster, das sich wiederholt: Ein Team bekommt ein gut vorbereitetes Design übergeben. Architekturdiagramme, Datenbankmodell, Schnittstellenverträge. Die Entwicklung beginnt, der erste Sprint läuft. Dann kommt das erste Problem: Eine Designannahme hält in der Realität nicht. Eine Bibliothek verhält sich anders als erwartet. Eine Schnittstelle ist in der Praxis komplexer als gedacht. Was passiert? Das Team löst das Problem lokal, pragmatisch, schnell. Niemand fragt zurück, niemand aktualisiert das Design. Drei Monate später ist das System ein Hybrid: halb Design, halb gewachsener Kompromiss. Kein Fehler im klassischen Sinne aber ein schleichender Verfall, der sich erst später zeigt, wenn Änderungen plötzlich unerwartet teuer werden.

Was diese Phase wirklich ist

Die Entwicklungsphase übersetzt das, was das Design als technisches Konzept geliefert hat, in lauffähige Software. Architekturen werden zu Codestrukturen, Schnittstellenverträge zu konkreten Implementierungen, Datenmodelle zu Datenbanktabellen. Dieser Übersetzungsprozess klingt mechanisch, is es aber nicht.

Im Kern beantwortet die Entwicklungsphase drei Fragen:

• Wie wird aus einem Entwurf funktionierender Code?

• Wie bleibt dieser Code über Zeit verständlich und veränderbar?

• Wie stellt das Team sicher, dass das, was gebaut wird, auch das ist, was gebaut werden sollte?

Diese drei Dimensionen hängen untrennbar zusammen. Code, der heute funktioniert aber morgen niemand mehr versteht, ist keine vollständige Lösung. Code, der elegant ist aber kontinuierlich vom Design abweicht, untergräbt die Arbeit aller vorherigen Phasen. Und Code, der ohne ständige Rückkopplung mit Anforderungen und Design entsteht, läuft Gefahr, das Richtige falsch oder das Falsche richtig zu bauen.

Entwicklung lässt sich in zwei Dimensionen denken, die parallel laufen.

• Die erste ist die technische Umsetzung: Logik implementieren, Schnittstellen bauen, Daten persistieren, Fehler behandeln.

• Die zweite ist die handwerkliche Qualität: Code lesbar halten, Strukturen konsistent gestalten, Abhängigkeiten bewusst managen, Tests mitschreiben.

Beide Dimensionen sind gleichwertig. Teams, die nur die erste im Blick haben, bauen Systeme, die schnell wachsen und langsam sterben.

Im SDLC steht die Entwicklungsphase an einem paradoxen Punkt. Sie ist die längste, aufwendigste und ressourcenintensivste Phase. Gleichzeitig ist sie die, in der fundamentale Fehlentscheidungen aus früheren Phasen zum ersten Mal wirklich spürbar werden. Eine lückenhafte Analyse zeigt sich, wenn Tickets täglich neu interpretiert werden müssen. Ein tragfähiges Design zahlt sich aus, wenn eine neue Anforderung sich organisch einfügt statt die Struktur zu sprengen. Die Entwicklung ist der Belastungstest für alles, was vorher passiert ist.

Das Verhältnis zu den angrenzenden Phasen:

Menschen, nicht nur Prozesse

Entwicklung wirkt von außen wie eine individuelle Disziplin. Eine Person, ein Bildschirm, ein Problem. In Wirklichkeit ist die Entwicklungsphase hochgradig kollektiv. Die sozialen Dynamiken, die hier wirken, sind subtiler und langlebiger als in jeder anderen Phase.

Formell sind in der Entwicklungsphase Entwicklerinnen und Entwickler, Tech Leads, manchmal Architektinnen und Architektinnen sowie Product Owner für Rückfragen beteiligt. Informell entscheidet etwas anderes: Welche Konventionen gelten wirklich, nicht im Styleguide, sondern im Pull Request? Wessen Code wird im Review tatsächlich hinterfragt, wessen wird durchgewunken? Wer schreibt Tests nicht, weil Zeitdruck herrscht und wer sagt es offen? Diese unsichtbare Schicht des täglichen Miteinanders bestimmt, wie gut die Entwicklungsphase wirklich läuft.

Besonders kritisch ist das Verhältnis zwischen Geschwindigkeit und Qualität. Es ist keine technische Frage, sondern eine kulturelle. Teams, in denen Geschwindigkeit offen oder implizit über Qualität gestellt wird, produzieren Code, der kurzfristig beeindruckt und langfristig belastet. Der Druck kommt selten als direktes Kommando. Er kommt als Sprint-Ziel, das zu ehrgeizig gesetzt wurde. Als Ticketstatus, der auf „done" gesetzt wird, obwohl der Test fehlt. Als Lob für denjenigen, der am meisten liefert. Unabhängig davon, was die Lieferung zurücklässt.

Eine weitere Spannung entsteht zwischen dem Einzelnen und dem Team. Entwicklung ist das Gegenteil von Teamarbeit in dem Moment, in dem jeder seinen Bereich bewacht. Wenn Code nicht geteilt, erklärt oder kritisch hinterfragt wird, entstehen Wissensinseln. Schlüsselpersonen, ohne die niemand versteht, wie ein bestimmter Service funktioniert. Systeme, die de facto nur von einer Person gewartet werden können, obwohl formal das ganze Team zuständig ist. Kollektives Eigentum am Code (das Prinzip, dass niemand „seinen" Code hat, sondern alle für das Gesamtsystem verantwortlich sind) ist leicht als Wert deklariert und schwer als Praxis gelebt.

Typische Reibungspunkte in dieser Phase:

• Technische Schuld als stilles Einverständnis: Shortcuts werden genommen, weil alle wissen, dass die Deadline Vorrang hat. Niemand spricht aus, was passiert. Das TODO-Kommentar im Code ist das ehrlichste Dokument des Projekts und das am wenigsten gelesene.

• Designdrift: Die Implementierung weicht Stück für Stück vom ursprünglichen Design ab, weil lokale Lösungen einfacher erscheinen als Rückfragen. Nach mehreren Sprints ist das tatsächlich gebaute System nicht mehr das, was das Design vorgesehen hat. Niemand hat je eine bewusste Entscheidung getroffen, es zu ändern.

• Review-Kultur ohne Feedback-Kultur: Pull Requests werden kommentiert aber keine Meinung gesagt. Kritische Hinweise werden als persönliche Kritik empfunden oder vermieden, weil das Klima es nicht erlaubt. Code Reviews verkommen zur Formalie.

• Scope-Creep im Kleinen: Entwickler interpretieren Anforderungen großzügig, bauen Features aus, die nicht beauftragt wurden, oder lösen „gleich das eigentliche Problem dahinter". Gut gemeint aber ungeklärt.

Die wirksamste Gegenmaßnahme ist keine neue Toolchain, sondern eine gelebte Norm: Entscheidungen, die über die eigene Aufgabe hinausgehen, werden sichtbar gemacht. Nicht jede Abweichung ist falsch aber jede Abweichung sollte bewusst sein.

Woran du erkennst, ob es läuft

Gute Entwicklung erkennt man nicht daran, dass viel Code geschrieben wird. Man erkennt sie daran, dass das System nach dem dritten Monat genauso gut navigierbar ist wie nach dem ersten. Man erkennt sie daran, dass ein neues Teammitglied nach einer Woche versteht, wie die Codebasis aufgebaut ist. Man erkennt sie daran, dass eine Änderung an einer Stelle keine Überraschungen an drei anderen erzeugt. Schlechte Entwicklung erkennt man zuverlässig an ihren Nebenwirkungen: an den Bugs, die kurz vor dem Release auftauchen; an den Deployments, die immer aufwendiger werden; an den Abweichungen, die niemand erklärt.

Messbar wird Qualität in der Entwicklung dort, wo sie nicht nur produziert, sondern gepflegt wird:

• Lesbar: Ein Entwickler, der den Code nicht geschrieben hat, kann ihn verstehen. Nicht weil Kommentare jeden Schritt erklären, sondern weil Namen, Strukturen und Muster für sich sprechen.

• Testbar: Funktionalität ist so implementiert, dass sie isoliert geprüft werden kann. Was nur als Ganzes getestet werden kann, kann nur als Ganzes verändert werden.

• Konsistent: Ähnliche Probleme werden im System ähnlich gelöst. Wer eine Komponente verstanden hat, kann die nächste zumindest plausibel lesen.

• Nachvollziehbar: Die Commit-Historie und Code-Reviews dokumentieren nicht nur Was geändert wurde, sondern geben Hinweise auf das Warum. Geschichte ist lesbar.

• Nah am Design: Abweichungen vom ursprünglichen Design sind bewusst entschieden und kommuniziert worden, nicht still entstanden.

Die weichen Warnsignale sind hier besonders aufschlussreich. Wenn Entwickler sagen, sie kennen „ihren Teil" des Systems aber nicht den der anderen, ist kollektives Ownership eine Illusion. Wenn jede neue Anforderung als unverhältnismäßig aufwendig beschrieben wird, hat die Architektur an Flexibilität verloren. Und wenn Tests nicht geschrieben werden, weil „keine Zeit" ist, ist das kein Zeitproblem, sondern ein Prioritätsproblem.

Die Übergabe in die Testphase ist der nächste Belastungstest. Was diese Phase konkret liefern sollte:

Entscheidungen, die morgen noch gelten

Das Besondere an Entscheidungen in der Entwicklungsphase ist ihre Kleinteiligkeit. Es gibt keine einzelne große Weichenstellung wie in der Planung oder im Design. Stattdessen hunderte kleiner Entscheidungen täglich. Wie eine Funktion heißt. Ob ein Fehler lokal behandelt oder weitergegeben wird. Ob eine Abhängigkeit abstrahiert oder direkt eingebunden wird. Jede dieser Entscheidungen erscheint trivial. In Summe ergeben sie eine Codebasis, mit der das Team die nächsten Jahre lebt.

Nachhaltige Entwicklungsarbeit bedeutet nicht, perfekten Code zu schreiben. Das wäre nicht nur unmöglich, sondern aktiv schädlich, weil es paralysiert und verlangsamt. Nachhaltige Entwicklungsarbeit bedeutet, Entscheidungen so zu treffen, dass sie die Handlungsfähigkeit des Teams erhalten (heute und auch noch in zwölf Monaten). Konkret heißt das:

Lesbarkeit vor Cleverness: Code wird häufiger gelesen als geschrieben. Eine elegante, komprimierte Lösung, die nur der Autor versteht, ist langfristig teurer als eine schlichte, verständliche Alternative. Der klügste Code ist oft der, der am wenigsten Erklärung braucht.

Technische Schuld bewusst eingehen: Shortcuts sind manchmal richtig. Aber sie sollten eine Entscheidung sein, keine Gewohnheit. Wer ein TODO hinterlässt, sollte wissen, was darin steckt und wann es adressiert werden soll.

Tests als Teil der Implementierung, nicht danach: Tests, die als separater Schritt nach dem Code entstehen, entstehen meist unter Zeitdruck und decken nur die einfachen Fälle ab. Tests, die parallel zur Implementierung entstehen, definieren Verhalten, nicht nur Ergebnis.

Abweichungen sichtbar machen: Wenn die Realität der Implementierung vom Design abweicht, ist das kein Fehler sondern eine Information. Diese Information gehört in einen expliziten Austausch, nicht in den Kommentarbereich eines Pull Requests.

Das häufigste nachhaltige Problem der Entwicklungsphase ist nicht "der große Fehler", sondern die akkumulierte Gleichgültigkeit. Ein Naming, das nicht ganz passt aber niemanden stört. Eine doppelte Logik, die man irgendwann aufräumen wollte. Ein Test, der seit Wochen auf Rot steht aber ignoriert wird, weil er als „flaky" gilt. Jedes dieser Details ist für sich genommen klein. Zusammen beschreiben sie eine Codebasis, in der das Team nicht mehr gerne arbeitet.

Am Ende der Entwicklungsphase lohnt sich deshalb eine ehrliche Rückfrage:

Wenn in sechs Monaten jemand diesen Code anfassen muss, der heute nicht dabei war ... würde er verstehen, was das System tut, warum es so gebaut wurde und wo er anfangen soll?

Wenn die Antwort zögerlich ist, ist die Entwicklung noch nicht fertig.

Weiterdenken

Entwicklung ist die Phase im SDLC, in der sich zeigt, ob alle vorherigen Entscheidungen tragfähig waren. Hier treffen Planung auf Realität, Design auf Implementierungsdetail, Anforderungen auf Interpretation. Wer diese Phase als reine Ausführung behandelt, verschenkt ihr eigentliches Potenzial: die Möglichkeit, durch handwerkliche Sorgfalt ein System zu schaffen, das nicht nur heute läuft, sondern morgen noch pflegbar ist.

Das interessanteste an der Entwicklungsphase ist nicht die Frage, welche Sprache oder welches Framework das Team verwendet, sondern wie das Team mit dem täglichen Widerspruch umgeht: zwischen Druck und Qualität, zwischen Geschwindigkeit und Verständlichkeit, zwischen dem, was schnell funktioniert und dem, was langfristig hält.

Nimm dir etwas Zeit und reflektiere die folgenden Fragen:

• Wie viel des Codes in eurem aktuellen System könnte eine neue Entwicklerin nach einer Woche selbständig lesen und einordnen (ohne Einweisung)?

• Werden Abweichungen vom Design in eurer Entwicklung sichtbar gemacht oder entstehen sie still, weil niemand den Aufwand für Rückfragen scheut?

• Welche technische Schuld in eurer Codebasis ist eine bewusste Entscheidung und welche ist einfach passiert?

• Wann habt ihr zuletzt einen Entwicklungsstandard nicht nur beschlossen, sondern tatsächlich im Review konsequent eingehalten?

Die nächste Phase, das Testing, baut direkt auf dem auf, was die Entwicklung geliefert hat. Dort wird aus Vertrauen Evidenz. Was das Team für korrekt hält, muss sich unter kontrollierten Bedingungen beweisen. Wie systematisch und effektiv dieser Nachweis gelingt, hängt unmittelbar davon ab, wie testbar der Code entwickelt wurde.