Ein Projekt jenseits des Machbaren

Jeder Softwareentwickler kennt dieses Problem: man hat eine wirklich tolle Idee für eine Anwendung, App oder Spiel, mit einem großen Funktionsumfang, durchdachten Features, lauffähig auf mehreren Arten von Endgeräten, verfügbar in allen gängigen Stores und selbstverständlich bestens umgesetzt. Und leider ist das alles weit mehr, als eine einzelne Person in einem vernünftigen Zeitraum bewältigen kann. Faktisch weiß man schon beim ersten Überschlagen der notwendigen Entwicklungszeit, dass das Vorhaben vollkommen unrealistisch ist. Das Vorhaben ist definitiv für eine Einzelperson zum Scheitern verurteilt.

Und dennoch.

Dann gibt es da diese wenigen Menschen, Leuchtfeuer in rauer See, die das Unmögliche schaffen nach langen Jahren mühevoller Arbeit etwas erschaffen, was man sonst einem ganzen Team fähigster Entwickler, Designer und Manager nicht zugetraut hätte. Eric Barone (Stardew Valley), Luke Hodorowicz (Banished), Lucas Pope (Papers, please) und Zeng Xiancheng (Bright Memory) sind nur einige wenige Beispiele, denen es zu folgen lohnt. Aus dem Nichts, manchmal ohne nenneswerte Entwicklungs- und Projekterfahrung, haben sie es geschafft, geradezu außergewöhnliche Projekte umzusetzen, die Kritiker und Spieler gleichermaßen fesseln. Die meisten sagen von sich selbst, ganz normale Menschen zu sein – mit einem üblichen Bedürfnis an Schlaf und Erholung, normalen Jobs, einer Familie und kleineren oder größeren Problemen. Und wenn es für diese Menschen möglich ist, solche Projekte umzusetzen, dann stellt das den unumstößlichen Beweis dar, dass es nicht nur theoretisch, sondern auch praktisch machbar ist.

Ich selbst habe mich 2015 auf diese Reise begeben. Mein Projekt, eine Mischung aus Harvest Moon und Minecraft, hat es bisher noch nicht geschafft, Kritiker und Spieler zu begeistern und ein Blick in meine Projektplanung lässt mich aufgrund der noch anstehenden Aufgaben regelmäßig an meinem Verstand zweifeln. Aber: es geht stetig weiter – und auch wenn das Licht am Ende des Tunnels noch ein weit entfernter Lichtpunkt am Horizont ist, so ist der Weg dahin doch klar. Mein aktueller Projektplan sieht vor, das Spiel bis 2026 in einer grundlegend release-bereiten Version umgesetzt zu haben. Es wäre das Ende einer mehr als 10 Jahre langen Reise. Inwiefern diese Zeitplanung realistisch ist, wird nur die Zeit selbst zeigen. Im Folgenden nehmen wir an, dass du unter den gleichen Bedingungen ein Projekt ähnlicher Länge umsetzen möchtest.

Um in all den Jahren diesen Weg stur und stetig beschreiten zu können, galt es einiges zu beachten. An einigen Tagen stand ich an Abgründen und dachte “ok, es reicht!” und wollte aufgeben. Aber mit dem richtigen Framework schafft man es dennoch, sich immer wieder aufzurichten und weiterzuarbeiten. Ich arbeite an diesem Projekt in meiner Freizeit, d.h. nach Feierabend, an Wochenenden und im Urlaub. Parallel dazu sitze ich im Beirat einer Gesellschaft, kümmere mich um Haus und Hof und gehe einigen anderen Hobbys nach. Zeit ist stets ein knappes Gut. Ich möchte dir damit sagen, dass es auch machbar ist, ohne sich jeden Tag in Form eines 2. Vollzeitjobs für dein Projekt zu verausgaben – es ist einzig der Wille, es zu tun.

In den folgenden Kapiteln möchte ich dir erläutern, welche Rahmenbedingungen ich für die Umsetzung eines Projektes (unabhängig von der Art des Projektes, seiner Zielgruppe oder technischer Details) als notwendig oder sinnvoll erachte. Hierbei handelt es sich um meine persönlichen Erfahrungen und Ratschläge, keine in Stein gemeißelten Gesetze. Nutze und passe sie nach deinen eigenen Bedürfnissen an.

Schreibe einen Plan

Ein gutes Projekt beginnt mit einem Plan. Halte zunächst schriftlich fest, was du dir für dein Spiel oder deine Anwendung wünschst, unabhängig davon, ob es realistisch umzusetzen ist oder einen Mehrwert bietet. Nimm jede Idee mit auf, die dir in denn Sinn kommt, schweife gerne etwas ab und unterhalte dich auch mit Freunden darüber. Es geht nicht um qualifizierte, ausgearbeitete Arbeitsschritte, sondern um ein Brainstorming.

Versuche jetzt, 1 – 2 absolute Kernelemente des Projektes herauszufiltern, ohne die deine Anwendung nicht lauffähig sein wird oder die als absolute Grundlage dient. Du kannst damit jetzt bereits mit der Implementierung anfangen. Auch hier geht es erstmal nicht um fertige, perfekt ausgearbeitete Inhalte – sehr wahrscheinlich wirst du diesen Teil der Arbeit auch wieder verwerfen. Dazu jedoch später mehr. Wichtig ist allein, bereits zu arbeiten. Sieh es entweder als Experimentieren mit neuen Technologien an oder alternativ um die Schaffung der grundlegenden Infrastruktur, z.B. Logging, Buildd-Pipelines, und mehr.

Jetzt der harte Teil der Planung. Dein Plan muss ausgearbeitet, verfeinert und in Arbeitspakete unterteilt werden. Versuche, die zuvor aufgenommenen Features grundlegend zu beschreiben, d.h. was verbirgt sich dahinter, welche Funktionen sollen bereitgestellt werden, was muss hierfür implementiert werden? Achte besonders darauf, dass die Features in dein Gesamtkonzept und deine Vision passen. Überlege, ob sie einen wirklichen Mehrwert bieten und die Erfahrung für den Kunden angenehmer gestalten – wenn nicht, dann kürze es ersatzlos heraus. Je nachdem, wie ausgiebig das vorherige Brainstorming betrieben wurde fallen in diesem Schritt sehr viele Ideen wieder weg. Je enger du dein Projekt auf wenige Features eingrenzen kannst, desto mehr Zeit sparst du auf lange Sicht. Vermeide den feature creep.

Jetzt hast du einen ersten Gesamtüberblick über das Projekt. Versuche, die Features jetzt in einer Reihenfolge zu sortieren, in der du sie implementieren möchtest. Die Sortierung muss nicht perfekt sein und einige Komponenten wirst du später parallel entwickeln müssen. Versuche sie so anzuordnen, dass du früh eine erste lauffähige Version bereitstellen könntest. Zu sehen, dass die Anwendung läuft, auch wenn noch keine tollen Funktionen umgesetzt sind, ist immer ein großer Motivationsschub.

Arbeite jetzt die Features im Detail aus, in der zuvor festgelegten Reihenfolge. Gehe hierbei ins Detail und halte alles in Schrift und Bild fest. Anforderungen, Implementierungsdetails, UI-Skizzen, Sound- und Musik-Proben, Verweise auf andere Vorbild-Projekte, u.v.m.

Arbeite stetig

Ein guter Plan ist allerdings auch nur der Anfang eines langen Weges. Man sollte nicht Gefahr laufen, das Projekt wochen- oder monatelang durchzuplanen, ohne dass effektiv eine einzige Codezeile geschrieben wird. Daher lohnt es sich, möglichst früh – noch während der Planungsphase – mit der Implementierung zu beginnen. Selbst wenn man später vielleicht Teile dieser Implementierung wieder überarbeiten oder entfernen muss, hat man allermindestens ein wenig Erfahrung oder wertvolle Erkenntnisse für die Planung gewonnen.

Mache dir zu Beginn keine Sorgen, dass dir wichtige Fähigkeiten fehlen, die du für die Umsetzung benötigst. Dieses ist ein Ausdauerrennen, kein Sprint, und es bleibt jede Menge Zeit, sich weiterzubilden. Setzt man sich erst einmal einige Wochen oder Monate mit der Materie auseinander, erlangt man schnell eine erstaunlich große Wissensbasis, und zuvor unlösbare Herausforderungen erscheinen machbar oder geradezu trivial. Aus meinen persönlichen Erfahrungen kann ich berichten, dass ich als Backend-Entwickler immer große Sorgen hatte, keine akzeptablen Spielgrafiken für mein Projekt umsetzen zu können. Mit den richtigen Tutorials, allesamt gratis und frei im Internet verfügbar, war es nach ein wenig (wirklich nur wenig) Übung dann plötzlich machbar.

Implementiere jedoch nicht einfach blind drauf los. Deine zuvor definierten Features lassen sich hervorragend in Arbeitspakete herunterbrechen, die man gezielt nach und nach abarbeiten kann. Der Einsatz eines Kanban-Boards ist hier sinnvoll, um Arbeitspakete schriftlich festzuhalten und deren Fortschritt zu tracken. Warum das auch für dich als einzigen Projektbeteiligten wichtig ist, wird in folgenden Kapiteln erläutert. Zu Beginn reicht es zu verstehen, dass es sinnvoll ist, eher kleine Arbeitspakete umzusetzen, die allerdings möglichst feature-complete, getestet und dokumentiert sein sollten. Dies gibt nicht nur die Motivation, etwas “fertiges” geschaffen zu haben, sondern ist auch eine gute Grundlage für die auf diesen Komponenten aufbauenden Projektteile.

Aber eines solltest du jeden Tag konsequent tun: arbeite JEDEN Tag an deinem Projekt. Das muss nicht unbedingt etwas Großes sein oder Stunden in Anspruch nehmen. Es geht hierbei eher darum, einen stetigen Projektfortschritt zu generieren, die eigene Motivation zu erhalten (dazu gleich mehr) und das Wissen und die eigenen Fähigkeiten kontinuierlich zu erweitern. An manchen Tagen schafft man so ganze Komponenten, an anderen nur 2 Codezeilen – das ist egal. Es geht nur um das kontinuierliche weitermachen. Du kannst dies auch tun, wenn du keinen Computer zur verfügung hast, beispielsweise auf Geschäftsreisen oder im Urlaub. Nutze diese Zeiten, um deine Planung zu verfeinern und anzupassen, gestalte Skizzen von Benutzeroberflächen oder schreibe einen Pseudo-Code deiner nächsten Komponente. Ein Notizbuch muss hierfür dein fester Begleiter sein, der ebenso wie Smartphone und Hausschlüssel stets an deiner Seite ist.

Motivation erhalten

Die erste wirklich große Herausforderung eines Langzeitprojektes ist es, die eigene Motivation zu erhalten. 10 oder mehr Jahre an einer Anwendung zu entwickeln und zwischenzeitlich nicht das Interesse verlieren, ist nahezu unmöglich. Was zu tun ist, wenn die Motivation doch einmal fehlen sollte und man sich in Nebenprojekte flüchtet, das wird in folgenden Kapiteln erläutert. Doch was für Möglichkeiten bieten sich, die eigene Motivation lange und möglichst durchgehend zu erhalten?

Eine gute Maßnahme ist, Freunden, Verwandten und Gleichgesinnten von deinem Projekt zu erzählen. Der regelmäßige Austausch gibt nicht nur wichtiges Feedback, sondern auch das Gefühl, dass die eigene Arbeit zählt und Interesse weckt. Dabei geht es nicht so sehr darum, objektive Meinungen einzuholen, sondern mehr um eine positive Reaktion. Natürlich wird auch der ein oder andere mit “das interessiert mich nicht” reagieren, doch die meisten Menschen spüren intuitiv ehrliche Begeisterung für ein Thema (auch wenn sie damit nicht vertraut sind) und werden bei stetigen Statusberichten mit Lob und Nachfragen nicht sparen. Wichtig ist hierbei das Wort “stetig”.

Lies Bücher, siehe Filme und schaue YouTube-Channels zum Thema deiner Anwendung. Dadurch kann man nicht nur das notwendige know-how zur Umsetzung des Projektes erlangen, sondern erhält auch die Bestätigung, dass es viele andere Menschen gibt, die sich für das gleiche Thema interessieren. Eine Volksweisheit besagt, dass man den Mitmenschen, mit denen man tagtäglich Kontakt hat, sowie der direkten Umwelt immer ähnlicher wird – und das stimmt durchaus. Warum also nicht die eigene Umwelt so anpassen, dass sie einen stetig mit Input für das eigene Projekt versorgt?

Nicht zu vergessen ist ein allgemein stabiles Umfeld in dem du lebst. Mit Freude eine Anwendung zu entwickeln, während man sich um seinen Job, Beziehung oder Gesundheit sorgen muss, erzeugt über die Monate und Jahre einen enormen Druck, an dem selbst willensstarke Menschen zerbrechen. Überlege also gut, ob dein Umfeld dich unterstützt und dir den Rücken freihält (oder dir allermindestens nicht in den Rücken fällt). Wenn das nicht der Fall ist, dann sollte dein primärer Fokus nicht auf deinem Projekt, sondern in der Schaffung einer stabilen und nachhaltig sicheren Arbeitsatmosphäre liegen.

• Ist mein Job sicher? Sollte ich mich weiterqualifizieren und spezialisieren, um mein Gehalt zu erhöhen oder mich “unersetzbar” und damit unkündbar zu machen?
• Sind meine Finanzen solide? Habe ich am Ende des Monats Geld übrig und verfüge ich über einen Notfallfond? Habe ich gar Schulden oder lebe über meine Verhältnisse?
• Bin ich gesund? Treibe ich Sport und halte mich körperlich fitt (kein Spaß, das ist WIRKLICH wichtig – du selbst bist deine größte Einkommensquelle und die gilt es zu pflegen)? Könnte mich eine Krankheit in Engpässe treiben?
• Habe ich ein positives Umfeld (Familie, Freunde), das mich unterstützt?

Solltest du mehr als eine dieser Fragen mit nein beantworten, gilt es hier als allererstes anzupacken.

Der Druck der Nebenprojekte

Es heißt, Nebenprojekte seien der Tod jeden Projekts. Das stimmt in vielen Fällen und dein Langzeitprojekt ist davor nicht gefeilt. Es gibt Menschen (und ich gehöre eindeutig nicht dazu), denen es gelingt, über lange Zeit alle Gedanken an Nebenprojekte beiseitezuschieben und sich voll und ganz auf ihr aktuelles und wichtigstes Projekt zu fokussieren. Wie gerne hätte ich nur 10 % dieser Willenskraft. Doch wie geht man jetzt damit um, wenn man weiß, dass man der Versuchung des Zweit- oder Drittprojektes nicht wiederstehen kann?

Meine Methode, mit der ich bislang sehr gut gefahren bin, lautet: don’t resist. Es hat keinen Sinn dagegen anzukämpfen. Aber zum Glück gibt es Möglichkeiten, diese Zweitprojekte so anzugehen, dass das Hauptprojekt nicht gefährdet wird.

Sehen wir es ein: das Zweitprojekt ist meist eine Impulsivhandlung, geboren aus einer fixen Idee und oft ohne großen Plan dahinter. Es wird niemals ein fertiges Produkt daraus. Mal sieht man eine Serie und denkt sich “Wow, das wäre ein cooles Szenario für ein Spiel” oder hat ein Alltagsproblem, dass man mit einer großartigen App lösen könnte. Aber das für 10 Jahre im Hinterkopf behalten? Oder einfach so vergessen? Beides unmöglich! Ein Ansatz zur Lösung des Dilemmas:

• Bringe dein Hauptprojekt auf einen Stand, dass du in 2-4 Wochen noch weißt, wo du aufgehört hast und keine angefangenen Arbeiten zurücklässt – so viel Disziplin muss sein!
• Lege einfach mit deinem Zweitprojekt los. Ohne Plan, ohne absolutes Ziel.
• Die ersten Hindernisse in der Entwicklung tauchen auf: komplexe Fragestellungen, keine klare Zielsetzung, keine Planung, hastig geschriebener Code.
• Nach wenigen Tagen oder Wochen verfliegt der überschäumende Enthusiasmus oft so schnell, wie er gekommen ist. Das Szenario aus der Serie war irgendwie doch nicht so spannend oder die App gibt es schon in 25 verschiedenen Ausführungen im App-Store.
• Am Ende geht das Zweitprojekt den Weg, den schon endlos viele Projekte vor ihm gegangen sind: in den Ordner mit halbfertigen, aufgegebenen Porjekten.

Jetzt, da der Druck weg ist, kann man direkt (und oftmals auch mit frischen Ideen und Energie) zum Hauptprojekt zurückkehren. Der kurze Exkurs hat ja meist auch Spaß gemacht und war wohlmöglich eine ersehnte Abwechslung zum immer gleichen Projekt. Sofern man sich zuvor an die Prinzipien der Code-Qualität (dazu später mehr) gehalten hat, sollte der erneute Einstieg kein Problem sein.

Gleichgesinnte suchen

Dieser Punkt wird mit zunehmendem Projektfortschritt stetig wichtiger werden. Die Grundlagen deiner Anwendung wirst du mit etwas Erfahrung gut allein implementieren können, doch irgendwann kommt der Zeitpunkt, an dem der Rat von fachlich geschulten Personen unabdingbar wird. Daher lohnt es sich zu jedem Zeitpunkt grundsätzlich zu netzwerken. Die Frage ist natürlich, wo man fündig werden kann:

• Konferenzen: sofern für dein Themengebiet verfügbar, melde dich auf Konferenzen an und sprich mit Ausstellern, Vortragenden, aber auch einfach mit anderen Teilnehmern. Die allerwenigsten davon beißen und sind ganz im Gegenteil sogar sehr mitteilungsfreudig.
• Meetups und Discord-Gruppen: schaue dich in deiner Umgebung nach Meetups um oder bringe in Erfahrung, ob beispielsweise YouTuber oder Coaches deiner Fachrichtung Discord-Communities bereitstellen.
• Je nach Produkt kannst du auch direkt mit deinen Kunden in Kontakt treten und Anforderungen und Feedback direkt während der Entwicklung abgreifen.
• Schreibe fachkundige Personen einfach an, ob per Email, Xing, LinkedIn, o.a.

Wichtig beim Netzwerken ist natürlich das, was auch bei jeder anderen sozialen Interaktion zählt. Falle nicht mit der Tür ins Haus, formuliere dein Anliegen klar, deutlich und präzise, sei freundlich, fordere keine Lösungen deiner Probleme ein und vor allem vergeude nicht die Zeit deines gegenüber. Außerdem sollte selbstverständlich sein, dass Interaktionen keine Einbahnstraße sind. Hilf, und dir wird geholfen. Wenn also in einem Discord oder Meetup nach einem Ratschlag gefragt wird und du die Antwort weißt, zögere nicht, dich mitzuteilen – du wirst mit deiner Projekterfahrung oftmals einiges besser wissen als andere, vielleicht ohne es selbst zuvor bemerkt zu haben. Teile dein Wissen daher gerne und vor allem ohne Hintergedanken mit. Erwarte keine direkte Gegenleistung – sie wird von ganz alleine kommen.

Code-Qualität

Damit kommen wir zu dem vielleicht wichtigsten Faktor für den langfristigen Projekterfolg: die Qualität deines Codes, deiner Dokumentation, deiner gesamten Arbeit. Aber, warum eigentlich? Muss der eigene Code überhaupt kommentiert oder dokumentiert werden? Muss man sich an alle Codekonventionen halten, wenn es doch eh niemand anderes zu Gesicht bekommt? Kennt man sich im eigenen Projekt nicht besser aus als alle anderen Menschen auf diesem Planeten?

Die klare Antwort darauf lautet: ja und nein. Gehen wir doch einfach ein paar Jahre zurück in deiner Tätigkeit als Entwickler. Damals hast du bestimmt schon das ein oder andere Programm oder Spiel geschrieben, kaum mehr als ein paar Tausend Codezeilen groß und nach wenigen Wochen oder Monaten fertig entwickelt. Natürlich hast du weder den Code kommentiert noch eine Dokumentation verfasst, denn das Projekt war so klein, dass man stets den Überblick über alle Komponenten und Anforderungen hatte. Ganz grob erinnerst du dich heute auch noch daran, wie klever du einige Komponenten damals implementiert hast. Öffne jetzt bitte eines dieser Projekte. Es wird jetzt folgendes passieren – vielleicht nicht alles davon, aber devinitiv einiges:

• Die Anwendung lässt sich nicht mit deiner IDE öffnen.
• Der Code lässt sich nicht kompillieren, Librarys und Packages fehlen und für einige der “exotischeren” Packages lässt sich die Quelle kaum noch finden.
• Der Code ist eine absolut unverständliche Ansammlung von Methoden und Variablen. Der Zweck von vielen davon ist dir selbst bei mehrmaligem Hinsehen schleierhaft.
• Du findest diversen auskommentierten Code. War der noch wichtig? Oder nur zu Testzwecken auskommentiert?
• An einigen Stellen findest du derart merkwürdige Codekonstrukte, dass du dir nicht sicher bist, ob du das damals aus Unwissenheit oder als Workaround implementiert hast.
• Du verbringst eine Menge Zeit damit überhaupt zu verstehen, wie der Code in seinem grundlegenden Ablauf, geschweige denn in seinen Details funktioniert.
• Du findest diverse //ToDos, hättest aber keine Ahnung, wie du diese jetzt noch in den Code einpflegen könntest, ohne evtl. neue Bugs in deine Anwendung einzubauen oder die Funktion anderer Komponenten zu beeinträchtigen.
• War die Anwendung damals eigentlich fertig entwickelt oder blieben noch Punkte offen? Wenn ja, welche?
• Alles in allem war es nett, mal wieder in ein altes Projekt zu schauen, aber Freude an einer Weiterentwicklung hat das nicht gerade geweckt. Lieber die IDE schnell wieder schließen.

Hast du dich darin wiedererkannt? Keine Sorge, du bist damit nicht allein. So ziemlich jeder Entwickler wird diese Erfahrung in seinem Leben gemacht haben, oftmals mehrfach. Aber was kümmert mich eigentlich so ein altes Projekt? Es hat mit meinem jetzigen Projekt doch Garnichts zu tun und da muss ich mich doch nicht an all diese Details erinnern. Das ist richtig. Aber jetzt bedenke, dass du an einem Projekt arbeiten möchtest, dass dich 5 oder 10 oder vielleicht noch mehr Jahre beschäftigen wird. Du wirst Komponenten implementieren, auf denen deine gesamte Anwendung fußt und die danach für Monate oder Jahre nicht mehr angefasst werden. Sie laufen all die Zeit im Hintergrund und tun ihren Dienst. Aber dann kommt der eine Tag, an dem du eine Änderung an dieser Komponente vornehmen musst. Jetzt läufst du in die oben aufgeführten Stolpersteine. Nur diesmal kannst du sie nicht ignorieren. Für eine Änderung von wenigen Zeilen wirst du Stunden, vielleicht sogar Tage benötigen. Und ob die Anwendung danach noch stabil läuft, ließe sich auch nur durch ausführliches Testen herausfinden.

• Kommentiere Klassen, Methoden, Variablen und Code. Wenn Methoden und Variablen nicht vom Namen her absolut selbsterklärend sind, erläutere kurz, wofür sie gut sind und was sie tun. Allgemein sollte dem zukünftigen Leser nicht nur klar sein, was der Code tut, sondern auch, welches konkrete Problem er löst oder welche Anforderungen er umsetzt – dies gilt im Besonderen bei Workarounds.
• Achte beim Kommentieren auch darauf, nicht ausschließlich immer nur die nächsten paar Codezeilen zu beschreiben. Eine detaillierte Ausführung über der Klasse, die die grundlegende Funktion und Funktionsweise des gesamten Codes der Klasse beschreibt, kann viel Arbeit sparen, sollte man den Code für Jahre nicht mehr anfassen.
• Halte deine Dokumentation up to date. Wenn du existierenden Code veränderst, gehe direkt mit der Einstellung daran, dass dazu auch das Durchlesen und evtl. Anpassen der Dokumentation gehört. Wenn es nichts anzupassen gibt, kannst du dich ein wenig über gesparte Arbeit freuen.
• Arbeite nicht auf Basis von PoCs, Prototypen oder temporärem Code weiter. Schreibe deine Klassen und Methoden vollständig und “production ready”. Wenn du auf diesem Code mit weiteren Komponenten aufbauen willst, muss das Fundament solide sein und kein Patchwork. Dazu gehört auch, Methoden zu schreiben, die man jetzt noch nicht, aber voraussichtlich wohl später benötigen wird – entfernen kann man diese später immer noch, wenn man ihn nicht benötigt.
• Verhalte dich wie ein Pfadfinder: lasse deine Umgebung immer ein wenig besser zurück als du sie vorgefunden hast. Wenn du während deiner Arbeit über alten Code stolperst, der nicht mehr verwendet wird oder noch dokumentiert werden muss, dann mach es genau jetzt!
• Baue Validierungen in deine Methoden ein. Überprüfe Parameter auf valide, vordefinierte Wertebereiche und melde Fehleingaben so laut wie möglich (via Log oder direkt als ArgumentException).
• Behandle Fehlerquellen in deinem Code mit angemessener Fehlerbehandlung. Aber achte dabei darauf, keine Fehler zu verschlucken, die besser an aufrufende Instanzen weitergereicht werden sollten.
• Schreibe dir robuste, leicht verwendbare Tools für Logging, Debugging und Notifications, die du überall in deiner Anwendung einsetzen kannst und sollst. Wenn du die extra Zeit aufwenden willst, schreibe sie gleich als eigenständige Library – dann kannst du sie auch in anderen Projekten 1:1 übernehmen.
• Halte deinen Projekstand und deine Gedanken fest. Auch wenn du allein arbeitest, ein Kanban-Board macht immer Sinn, v.a. wenn man Monate später wieder darauf schaut und direkt wieder weiß, wo man stehen geblieben ist.
• Verwende eine Versionsverwaltung, z.B. Git, um deinen Code besser verwalten und im Notfall Änderungen rückgängig machen zu können. Erstelle Feature-Branches für neue Features und halte deinen master-Branch frei von broken builds. Folge allgemein dem Git Flow Prinzip.
• Habe immer eine lauffähige Version deiner Anwendung parat. Wenn du dem Git Flow folgst, sollte dein master-Branch diese Bedingung immer erfüllen können.
• Falls für deine Anwendung notwenig: dokumentiere den Build- und Deployment-Prozess sauber, inklusive IDE, Librarys, Build-Settings, Anforderungen an die Laufzeitumgebung und mehr.
• Schreibe Tests für mindestens alle kritischen Komponenten. Die Tests müssen aussagekräftig für die Funktionalität dieser Komponenten sein, d.h. es müssen sowohl korrekte, als auch Fehlerzustände überprüft werden. Dies hilft v.a. bei einer Migration ungemein (dazu gleich mehr).
• Allgemein: nimm dir Zeit, deinem Code eine hohe Qualität zu verleihen!

Keine Angst vor Migrationen

Kaum eine Branche entwickelt sich so schnell weiter wie die IT. In manchen Berufsfeldern muss man mit der Zeit gehen, um nicht zurückzubleiben – in der IT muss man rennen. In diesem Kontext sollte man sich vor Augen halten, dass ein Projekt mit 10 Jahren Entwicklungszeit in dem Moment, in dem es abgeschlossen wird, technisch komplett veraltet sein wird. Denken wir zurück, mit welchen Technologien wir vor 10 Jahren gearbeitet haben, so würden wir diese vielleicht nicht als antiquiert, aber allermindestens als sehr in die Jahre gekommen betrachten. Um dem entgegenzuwirken, ist es zwangsläufig notwendig, das Projekt alle paar Jahre auf die aktuelle Version einer Programmiersprache, Framework, o.ä. zu migrieren. Dass hierbei einigen Entwicklern mehr als mulmig wird, ist verständlich. Lauffähige Versionen werden plötzlich nicht mehr kompillierbar sein, Librarys sind nicht mehr verfügbar, Komponenten verhalten sich anders als zuvor und man hat das Gefühl, Wochen oder im schlimmsten Fall Monate in der Arbeit zurückgeworfen zu werden.

An dieser Stelle sei eine Lanze für die Migration zu brechen. Produkte mit veralteten Sprachen oder Frameworks zu veröffentlichen ist auf vielfältige Art gefährlich:

• Keine Garantie, ob die Anwendung auf den angepeilten Endgeräten später lauffähig sein wird.
• Die großen App-Stores können die Anwendung schlicht ablehnen.
• Bekannte Sicherheitslücken können nicht mehr geschlossen werden und bieten ein Einfallstor für Hacker und Schadsoftware.
• Die Performance der Anwendung bleibt suboptimal.
• Neue Features eines Frameworks können nicht verwendet werden.

Bereits die ersten drei Punkte sind jeder für sich ein Showstopper. Halten wir die Nachteile einer Migration dagegen:

• Die Anwendung ist nach der Migration nicht mehr kompillierbar.
• Einige Librarys sind nicht mehr verfügbar oder bieten die bislang verwendeten Methoden nicht mehr an.
• Die Anwendung verhält sich zur Laufzeit anders als zuvor.
• Die Migration korrumpiert Teile des Projekts.

Wenn man ein wenig nachdenkt, kommt man sicherlich zu der Erkenntniss, dass keiner dieser Punkte ein Showstopper ist, denn sie lassen sich alle beheben oder allermindestens revidieren. Man sollte sich natürlich keine Illusionen hingeben und erwarten, dass eine Migration ohne Probleme abläuft, nur um dann von der Realität schwer enttäuscht zu werden. Stattdessen lohnt es sich, hier erst einmal mit Stolpersteinen zu rechnen und sich zu freuen, wenn sie ausbleiben sollten.

Kompillierfehler sind nahezu immer zu erwarten. Mittels einer modernen IDE kann man diese jedoch meißt schnell in den Griff bekommen – zuvor geschriebene Tests stellen dann zudem sicher, dass die Anwendung und ihre Komponenten auch zur Laufzeit noch so funktionieren wie gewünscht. Fehlende Librarys sind ein Ärgernis, aber oftmals steht man mit diesem Problem nicht allein da. Das Internet wimmelt nur so von Antworten auf eingestellte Librarys und wie man diese mit modernen Frameworks doch noch zum Einsatz bringen kann oder (besser) welche Alternativen man jetzt verwenden sollte. Und korrumpierte Dateien oder Projekte lassen sich dank Git auch mit wenigen Befehlen schnell wieder auf den Status Quo zurückdrehen, um die Migration vielleicht mit leicht anderen Parametern durchzuführen.

Ein etwas allgemeinerer Tipp zu Migrationen: wenn man die Wahl hat, mit welcher Programmiersprache, Framework oder Engine man arbeiten möchte, sollte man bei einem Langzeitprojekt auch ein wenig auf die Anbieter hinter diesen Technologien blicken.

• Sind diese Firmen zukunftssicher?
• Wurden die Produkte in der Vergangenheit gut gepflegt und erweitert?
• Gibt es für die Produkte eine Roadmap?
• Gibt es Konkurrenzprodukte, die das Produkt absehbar obsolet machen werden?
• Gibt es zu dem Produkt eine große, aktive Community – bestenfalls eine, die das Produkt aktiv erweitert?

All diese Fragen lassen sich mit einer kurzen Google-Suche problemlos beantworten. Wenngleich manche Nieschenprodukte ein für das eigene Projekt interessantes Portfolio an Funktionen bieten, sollte man sich zweimal überlegen, ob dies die Gefahr eines eingestellten Produktes und damit fehlenden Supports aufwiegt.

Wann ist ein Langzeitprojekt nichts für mich?

Manchmal muss man der Realität allerdings auch einfach ins Auge sehen. Unter bestimmten Umständen macht es einfach keinen Sinn, ein Langzeitprojekt zu starten, da die Chancen auf einen erfolgreichen Abschluss zu gering sind. Statt Luftschlössern hinterherzujagen ist es dann besser, die bittere Pille zu schlucken und das Projekt frühestmöglich einzustellen.

Insbesondere Personen, die sich schnell durch einen äußeren Reiz begeistern lassen, diese Begeisterung aber ebenso schnell wieder verlieren, sind keine guten Kandidaten für ein Langzeitprojekt. Deine Idee muss dich lange (manchmal monatelang) umtreiben und nachts nicht schlafen lassen – dann ist das ein gutes Zeichen, dass die Motivation auch langfristig stimmen kann. Wenn man für eine Idee jedoch Feuer und Flamme ist, nach 2-3 Nächten jedoch die große Ernüchterung einsetzt, dann war es auch nicht das Richtige.

Man muss bereit sein, den gesamten Weg bis zum Projektabschluss alleine zu gehen. Natürlich kann man sich Rat und Tat von Gleichgesinnten oder auch zugekaufter Arbeitskraft organisieren, aber die erste Prämisse sollte stets sein, dass man bereit ist, die Anwendung komplett alleine umzusetzen. Wer einen Partner findet, mit dem man die Arbeit teilen kann: sehr schön! Aber man darf sich niemals darauf verlassen, dass die Motivation des Partners im gleichen Maße erhalten bleibt wie die eigene, nur um dann aufzuhören, wenn der Partner abspringt. Wenn dein Projekt darauf basiert, dass andere Personen (auf nicht monetär vergüteter Basis) am Projekt mitwirken sollen und das auch noch über einen langen oder den kompletten Entwicklungszeitraum, ist das Projekt mit hoher Sicherheit zum Scheitern verurteilt.

Zu guter letzt musst du dir selbst die Frage stellen, ob deine Lebensplanung es erlaubt, das Projekt langfristig angehen zu können. Möchtest du in den nächsten 10 Jahren eine Familie gründen? Ein Haus bauen? Karriere machen? All diese Punkte sind wunderschön und erstrebenswert – und vielleicht der Todesstoß für dein Projekt. Rede mit Freunden und Verwandten, die eine Familie haben, ein Haus gebaut haben, Karriere gemacht haben. Frage sie, wie sie mit ihrer Zeit umgehen und wie sich ihr Leben verändert hat – und stelle dir dann die ernsthafte Frage, ob ein Langzeitprojekt dann noch das richtige für dich ist.

Ich hoffe, dir mit diesem Beitrag ein paar Tipps mit auf den Weg gegeben zu haben, die vielleicht der Start in ein erfolgreiches Langzeitprojekt darstellen können – oder dir mehr Motivation und Handlungsweisen an die Hand geben, wenn du bereits an einem solchen Projekt arbeitest. Berichte auch gerne von deinen Erfahrungen, denn davon können sicherlich viele Menschen profitieren!