An Ideen hat es mir bislang selten gemangelt. Eher war das Gegenteil der Fall.
Aus einer ursprünglichen Idee entstand eine weitere Funktion. Diese erforderte neue Logik, zusätzliche Grafiken oder eine technische Grundlage, die vorher nicht vorgesehen war. Während der Umsetzung kamen weitere Möglichkeiten hinzu, die das Projekt tatsächlich hätten verbessern können. Aus einem überschaubaren Vorhaben wurde so allmählich etwas, das in der verfügbaren Freizeit kaum noch zu bewältigen war.
Das ist keine ungewöhnliche Entwicklung. Gerade beim Programmieren ist es leicht, den nächsten interessanten Gedanken ebenfalls noch umzusetzen. Eine neue Funktion erscheint einzeln betrachtet oft harmlos. Sie muss jedoch entwickelt, in die bestehende Struktur eingefügt, getestet und später gewartet werden. Häufen sich solche Erweiterungen, verändert sich nicht nur der Umfang, sondern mitunter das gesamte Projekt.
Hinzu kommt, dass nicht jedes Problem mit vorhandenem Wissen gelöst werden kann. Manchmal erfordert eine Funktion eine neue Technologie, ein unbekanntes Framework oder ein Thema, mit dem man sich zunächst gründlich befassen müsste. Das Wissen wäre grundsätzlich erreichbar. Es fehlen jedoch die Zeit und gelegentlich auch die Muße, wochenlang Dokumentationen, Foren und Anleitungen zu durchforsten, bevor die eigentliche Arbeit fortgesetzt werden kann.
Ein Projekt gerät dann nicht unbedingt wegen eines einzelnen großen Hindernisses ins Stocken. Häufig ist es die Summe vieler kleiner Erweiterungen und offener Fragen.
Klein bedeutet nicht einfach
Wenn ich von kleinen Projekten spreche, meine ich damit keine hastig erstellten Programme mit möglichst wenigen Funktionen.
Ein kleines Projekt kann technisch anspruchsvoll sein. Es kann aus mehreren Komponenten bestehen, unterschiedliche Systeme verbinden und eine sorgfältige Gestaltung erfordern. Entscheidend ist nicht allein die Anzahl der Dateien oder Anwendungen, sondern ob das Vorhaben als Ganzes noch verständlich, beherrschbar und abschließbar bleibt.
Auch die Grenze eines Projekts lässt sich nicht immer eindeutig ziehen.
Eine separate Programmierschnittstelle kann beispielsweise technisch eine eigene Anwendung sein und dennoch unmittelbar zum Projekt gehören, wenn das eigentliche Programm ohne sie nicht wie vorgesehen funktioniert. Ein Dienst, der Bilder verarbeitet oder Daten bereitstellt, ist möglicherweise unabhängig ausführbar, aber dennoch Teil derselben Gesamtlösung.
Deshalb halte ich pauschale Regeln wie „Diese Funktion gehört nicht mehr zum Projekt“ für wenig hilfreich. Sinnvoller ist die Frage, ob eine neue Idee noch der ursprünglichen Zielsetzung dient und ob ihr Nutzen den zusätzlichen Aufwand rechtfertigt.
Das lässt sich nicht immer im Voraus zweifelsfrei beantworten.
Die Schwierigkeit des Weglassens
Nach der Planungsphase weitere Ideen zu haben, ist zunächst nichts Schlechtes. Planung kann nicht jeden späteren Gedanken vorwegnehmen. Manche Funktionen erkennt man erst während der Umsetzung als notwendig oder sinnvoll.
Problematisch wird es, wenn jede gute Idee automatisch auch umgesetzt werden soll.
Gerade als Entwicklerin fällt es mir bisweilen schwer, eine Funktion wegzulassen, von der ich überzeugt bin, dass sie das Ergebnis verbessern könnte. Die technische Möglichkeit ist vorhanden, der Nutzen erscheint nachvollziehbar und die Umsetzung wäre interessant. Trotzdem kann sie den vorgesehenen Rahmen sprengen.
Das ist eine typische Programmiererkrankheit: Weil etwas machbar und reizvoll ist, soll es nach Möglichkeit ebenfalls Bestandteil des Projekts werden.
Die eigentliche Entscheidung lautet dann nicht, ob die Funktion gut oder schlecht ist. Sie kann durchaus gut sein und dennoch vorerst entfallen müssen.
Ein bewusst begrenzter Umfang bedeutet daher nicht, dass keine weiteren Ideen erlaubt sind. Sie müssen lediglich gegen die ursprüngliche Zielsetzung, den erwartbaren Aufwand und die verfügbare Zeit abgewogen werden. Manche können für eine spätere Version vorgemerkt werden. Andere eignen sich vielleicht als Grundlage für ein eigenständiges Projekt.
Weglassen ist dabei keine technische Unfähigkeit, sondern eine Entscheidung über Prioritäten.
Was „fertig“ für mich bedeutet
Ein Programm wird nicht dadurch fertig, dass keine weiteren Ideen mehr existieren. Dieser Zustand tritt vermutlich nie ein.
Ebenso wenig bedeutet „fertig“, dass keinerlei Fehler mehr vorhanden sind. Jede hinreichend komplexe Software kann unbekannte Fehler enthalten. Auch „vollständig“ ist als allgemeiner Begriff wenig nützlich, da sich fast immer noch eine weitere Funktion ergänzen ließe.
Für mich ist ein Projekt fertig, wenn es gemäß der ursprünglich festgelegten Anforderungen funktional vollständig ist, geprüft wurde und möglichst wenige bekannte Fehler enthält.
Die ursprüngliche Festlegung ist dabei wichtig. Ohne sie verschiebt sich das Ziel während der Entwicklung fortwährend. Jede neue Idee wird dann zu einer vermeintlich fehlenden Funktion, und das Projekt kann seinen Endpunkt nicht mehr erreichen.
Natürlich dürfen Anforderungen während der Arbeit korrigiert werden. Manchmal zeigt sich erst in der Umsetzung, dass eine Annahme falsch war oder eine Funktion anders aufgebaut werden muss. Eine solche Änderung sollte jedoch eine bewusste Entscheidung sein und nicht bloß die Folge jeder neu auftretenden Möglichkeit.
„Fertig“ ist somit kein Urteil über theoretische Perfektion. Es bezeichnet einen nachvollziehbaren Stand, an dem das Projekt seine festgelegte Aufgabe erfüllt und veröffentlicht oder eingesetzt werden kann.
Veröffentlichung ist nicht das Ende jeder Arbeit
Ein abgeschlossenes Projekt muss nicht für alle Zeiten unverändert bleiben.
Pflege und Wartung gehören für mich zur Entwicklung dazu. Fehler werden möglicherweise erst nach der Veröffentlichung sichtbar. Betriebssysteme, Abhängigkeiten oder externe Dienste verändern sich. Manchmal sind Anpassungen notwendig, damit ein Programm weiterhin funktioniert.
Auch sinnvolle Erweiterungen sind nicht grundsätzlich ausgeschlossen.
Der Unterschied besteht darin, dass das vorhandene Projekt bereits einen funktional abgeschlossenen Zustand erreicht hat. Weitere Arbeiten bauen darauf auf, statt einen nie endenden ersten Entwicklungsstand fortzuführen.
Nicht jedes Programm muss auf Dauer wachsen. Manche Projekte benötigen regelmäßige Pflege, andere nur gelegentliche Korrekturen. Ein Projekt darf auch über längere Zeit unverändert bleiben, wenn es seinen Zweck weiterhin erfüllt.
Der Umfang muss zur verfügbaren Zeit passen
Ich entwickle meine eigenen Projekte nicht täglich und nicht nach einem festen Zeitplan. Deshalb messe ich ihre Größe auch nicht ausschließlich in Wochen oder Monaten.
Ein Vorhaben darf mehrere Monate dauern. Entscheidend ist, ob in dieser Zeit erkennbarer Fortschritt möglich bleibt und ob das Ziel weiterhin realistisch erscheint.
Wenn ein privates Projekt nach Jahren noch immer keinen funktionalen Abschluss erreicht hat, sollte das Konzept allerdings überprüft werden. Möglicherweise ist der Umfang zu groß geworden. Vielleicht haben sich die technischen Grundlagen verändert oder die ursprüngliche Struktur erschwert jede weitere Arbeit.
In einem solchen Fall kann ein Neuanfang vernünftiger sein als der Versuch, jede alte Entscheidung beizubehalten.
Das bedeutet nicht zwangsläufig, sämtliche bisherige Arbeit zu verwerfen. Erkenntnisse, Inhalte und einzelne Komponenten können weiterverwendet werden. Ein neues Konzept kann aber die Gelegenheit bieten, den tatsächlichen Kern des Projekts wieder sichtbar zu machen.
Anerkennung für große Projekte, ohne sie selbst nachzuahmen
Große Spiele und Anwendungen können beeindruckende Leistungen sein.
Bei umfangreichen Double-A- oder Triple-A-Spielen arbeiten zahlreiche Menschen über mehrere Jahre an Programmierung, Grafik, Animation, Ton, Gestaltung, Texten, Tests und vielen weiteren Bereichen. Ich bewundere die Arbeit, die dafür notwendig ist.
Gerade deshalb würde ich selbst kein vergleichbares Projekt beginnen.
Der Umfang solcher Produktionen lässt sich nicht sinnvoll auf eine einzelne Person in ihrer Freizeit übertragen. Der Versuch würde nicht zu einer kleineren Fassung desselben Ergebnisses führen, sondern wahrscheinlich zu einem dauerhaft unfertigen Projekt.
Meine eigenen Vorhaben müssen nicht mit großen Produktionen konkurrieren. Sie können einen kleineren Zweck verfolgen, eine einzelne Idee untersuchen oder eine bestimmte Spielmechanik und Atmosphäre in den Mittelpunkt stellen.
Ein begrenztes Projekt kann dennoch sorgfältig entwickelt sein. Seine Qualität hängt nicht davon ab, wie viele Funktionen, Spielstunden oder Systeme es enthält.
Eigenständig, aber nicht ohne Unterstützung
Eigenständige Entwicklung bedeutet für mich nicht, jede Aufgabe ohne fremdes Wissen oder Hilfsmittel erledigen zu müssen.
Ich verwende Bibliotheken, Entwicklungswerkzeuge, Dokumentationen und inzwischen auch generative Modelle. Bei Bedarf greife ich auf bestehende Lösungen zurück oder lasse mir unbekannte Ansätze erklären.
Eigenständig bleibt ein Projekt dadurch, dass ich seine Zielsetzung festlege, die technischen und gestalterischen Entscheidungen treffe und die Verantwortung für das Ergebnis übernehme.
Unterstützung kann verhindern, dass fehlendes Spezialwissen ein gesamtes Vorhaben zum Stillstand bringt. Sie ändert jedoch nichts daran, dass ich beurteilen muss, ob eine vorgeschlagene Lösung zum Projekt passt.
Gerade für eine einzelne Entwicklerin kann diese Verbindung aus eigener Entscheidung und verfügbarer Unterstützung den Unterschied zwischen einer begonnenen Idee und einem abgeschlossenen Projekt ausmachen.
Ein überschaubares Ziel
Jessa Studio soll Raum für Spiele, Anwendungen und Experimente bieten, ohne dass jedes davon zu einem langfristigen Großprojekt werden muss.
Ich möchte Vorhaben entwickeln, deren Umfang zu meiner verfügbaren Zeit passt. Sie dürfen technisch anspruchsvoll sein, mehrere Komponenten enthalten und sich während der Arbeit verändern. Sie benötigen aber eine erkennbare Zielsetzung und einen Zustand, an dem ihre ursprüngliche Aufgabe erfüllt ist.
Auch mein derzeitiges Projekt folgt diesem Ansatz. Schon während der Entwicklung entstehen weitere Ideen und mögliche Erweiterungen. Die eigentliche Arbeit besteht deshalb nicht nur in ihrer Umsetzung, sondern ebenso in der Entscheidung, welche davon für die erste vollständige Fassung tatsächlich notwendig sind.
Anmerkung: Auch dieser Beitrag entstand mit Unterstützung eines Sprachmodells. Inhalt, Positionen und Beispiele stammen von mir. Das Modell half bei der Gliederung, der Wortwahl und der stilistischen Überarbeitung.
Austausch
0 Kommentare
Kommentare werden vor der Veröffentlichung geprüft. Bleibe konstruktiv und beim Thema.