Wenn man an Softwareentwicklung denkt, kommt oft sofort das Bild eines Programmierers auf, der stundenlang in Codezeilen vertieft ist. Doch hinter dem Schreiben von sauberem, funktionierendem Code steckt viel mehr – eine Denkweise, ein Systemverständnis und eine Strategie, die darüber entscheidet, wie gut eine Lösung wirklich ist. Shadman Kudchikar, Tech Lead und Backend-Architekt mit fast einem Jahrzehnt Erfahrung, beschreibt diesen Prozess aus seiner Sicht in seinem Blog „Code with Shadman“ auf eine besonders anschauliche Weise. Der Kern seiner Lehre liegt in einem Spiel, das er als Kind unbeabsichtigt spielte – ein Spiel, das heute sinnbildlich für die Herausforderungen und Denkweisen eines Softwarearchitekten steht. Dieses „Spiel“ steht im Mittelpunkt einer tiefgreifenden Metapher, die viel über die Kunst der Softwareentwicklung verrät. In seiner Erzählung beginnt alles mit einem einfachen Kinderspiel. Eine Gruppe von Kindern sitzt mit Papier und Stift zusammen.
Sie zeichnen ein Raster aus Punkten – in der Regel neun mal neun oder ein ähnliches Format – und stellen sich einer Herausforderung: Sie müssen von Punkt zu Punkt Linien ziehen, ohne den Stift abzusetzen und ohne eine bereits gezogene Linie zu überqueren. Klingt simpel, ist es aber nicht. Denn die Schwierigkeit besteht darin, nicht nur den nächsten Schritt zu machen, sondern mehrere Züge vorauszudenken und den gesamten Pfad so zu gestalten, dass man am Ende alle Punkte verbindet, ohne in eine Sackgasse zu geraten. Dieser spielerische Ansatz ist eine subtile Einführung in das, was später im Erwachsenenleben zur Softwarearchitektur wird. Jeder Punkt in diesem Raster symbolisiert eine Anforderung, ein Feature oder einen Meilenstein in einem Softwareprojekt. Die Linien sind die Verbindungen, Entscheidungen und Implementierungen, die Entwickler treffen, um diese Punkte zu erreichen.
Die wichtigste Regel im Spiel – keine Strecke doppelt zu gehen – entspricht dabei dem Grundsatz, dass man in der Softwareentwicklung keine Lösungen bauen möchte, die sich später als Sackgasse oder unflexibel erweisen. Wer nicht nur an der Oberfläche kratzt, erkennt schnell Parallelen. Wenn Entwickler beispielsweise eine Funktion schreiben, die Emails versendet, könnte der unmittelbare Impuls sein, direkt eine Mail-API aus der Controller-Logik aufzurufen. Das scheint die schnellste, einfachste Lösung. Doch diese Herangehensweise ist kurzsichtig. Die reale Welt ist dynamisch: Anforderungen ändern sich, Technologien werden ersetzt, und Systeme wachsen. Wird nun eine Warteschlange für den Mailversand gewünscht oder ein Wechsel des Mail-Dienstleisters nötig, ist man gezwungen, den gefassten Entwurf grundlegend zu überdenken – man muss quasi „Linien zurückverfolgen“ und bereits bestehende Wege neu zeichnen. Hier kommt das Prinzip der Entkopplung ins Spiel.
Indem Entwickler Schnittstellen verwenden, Dependency Injection einsetzen oder Nachrichtenwarteschlangen einbauen, schaffen sie eine Architektur, die offen für Anpassungen ist. Diese Entscheidungen sind wie das bewusste Ziehen der Linien im Punkt-Raster mit Blick auf den gesamten Pfad, nicht nur den nächsten Schritt. Es ist eine Investition in Flexibilität und Wartbarkeit. Shadman beschreibt, wie er durch seine Erfahrungen als Tech Lead immer mehr dazu überging, weniger den „was“ und „wie“ Fragen zu folgen, sondern stattdessen tief in das „warum“ einzutauchen. Warum wählen wir eine bestimmte Technik? Warum halten wir uns an dieses Muster? Warum könnte diese Entscheidung in Zukunft problematisch werden? Dieses Hinterfragen ist der kritische Wendepunkt zwischen einfachem Coden und echtem Architekturverständnis. Diese Art des Denkens steht im Gegensatz zu einer kurzfristig orientierten Vorgehensweise, bei der schnelle Tricks und schnelle Lösungen dominieren.
Ein guter Entwickler sieht nicht nur den Code, sondern auch die Konsequenzen seiner Entscheidungen im Kontext der Gesamtarchitektur und der langfristigen Produktentwicklung. Es ist die Fähigkeit, das System als Ganzes zu betrachten, mögliche zukünftige Anforderungen vorherzusehen und so Entscheidungen zu treffen, die nachhaltig sind. Das Kinderspiel mit den Punkten ist kein bloßer Zeitvertreib mehr, sondern eine prägende Erfahrung, die Systemdenken und strategische Planung symbolisiert. Es trägt den Namen „The Architect’s Grid“ – das Raster des Architekten. So wie in dem Spiel mit den angrenzenden Punkten und Linien behandelt ein Softwarearchitekt nicht nur einzelne Features, sondern das gesamte Geflecht von Abhängigkeiten und Möglichkeiten, das ein Produkt ausmacht. Diese Denkweise ist unverzichtbar, wenn es um komplexe Systeme und moderne Softwareentwicklung geht.
Mit steigender Projektgröße, mehr Beteiligten und wachsender Komplexität wird es ohne vorausschauende Planung und kluge Architekturentscheidungen nahezu unmöglich, wartbare und skalierbare Systeme zu bauen. Die Metapher des Spiels zeigt, wie wichtig es ist, sich Zeit für das Nachdenken zu nehmen, bevor man den nächsten Schritt geht – sei es eine Codezeile, eine Architekturentscheidung oder eine Produktfunktion. Darüber hinaus zeigt Shadmans Erfahrung, dass der Job eines Tech Leads und Softwarearchitekten weit über das reine Programmieren hinausgeht. Es geht um Führung, Kommunikation und das Vermitteln einer Denkweise an das Team. Ein Tech Lead ist jemand, der nicht nur selbst in die Tiefe geht, sondern auch Kollegen dazu befähigt, die „Architektursicht“ einzunehmen und das Gesamtbild im Blick zu behalten. Auf diese Weise wird der einst kindliche Entdeckergeist mit der Zeit zur professionellen Kompetenz.
Die Herausforderung ist dabei immer dieselbe: nicht in der Detailversessenheit steckenbleiben, sondern das System komplex, aber handhabbar zu halten. Die besten Architekten sind diejenigen, die bereit sind, Fragen zu stellen, auf Veränderungen zu reagieren und ihr Design stets weiterzuentwickeln. Die Geschichte vom „Spiel, das wir nie zu spielen wussten“ ist somit mehr als nur eine Narrative aus den kindlichen Tagen von Shadman Kudchikar. Sie ist eine Einladung an alle Entwickler, Architekten und Technikinteressierten, den Blick zu weiten, den Wert von vorausschauendem Denken zu erkennen und den Mut zu entwickeln, das eigene Handeln beständig zu hinterfragen. Nur so kann man in der Welt der Softwareentwicklung wirklich gewinnen – nicht mit kurzfristigen Tricks, sondern mit nachhaltigen Lösungen, die auch morgen noch funktionieren.
Abschließend zeigt sich, dass der Weg vom Junior-Entwickler zum Tech Lead vor allem über die Einsicht führt, dass Softwareentwicklung ein Spiel mit vielen Regeln und langfristigen Konsequenzen ist. Wer die Spielelogik einmal verstanden hat, sieht nicht mehr nur Code, sondern ganze Wege und Pfade. Dieses Verständnis ist der Schlüssel, um effizienter, smarter und zukunftssicherer zu arbeiten – zum Wohl der Projekte, der Teams und natürlich auch der Nutzer, die am Ende von stabilen und durchdachten Systemen profitieren.
