# Wie Amateur-Softwareentwickler professionell scheitern > Zwei Spieleprojekte, zweimal derselbe Fehler. Unsere Software war nicht zu schwach für ihr Problem, sondern zu stark für unser Team. - Autor: Julian Siebert (https://www.julian-siebert.de/) - Veröffentlicht: 2026-10-25 - Thema: Digitalisierung & Transformation - Adresse: https://www.julian-siebert.de/beitraege/261025_wie_amateur-softwareentwickler_professionell_scheitern/ September 2024: Die Schule langweilte mich, und der Misserfolg unseres letzten Minecraft-Netzwerks „Uroria“ frustrierte mich noch immer. Trotzdem wollte ich es noch einmal versuchen und die Fehler von damals diesmal nicht wiederholen. Das war der Anfang von [o7studios](https://o7.studio). ## Vorgeschichte Bevor ich [Raphael](https://raphael-goetz.de/) kennenlernte, meinen wichtigsten Mitstreiter, entwickelte ich auf eigene Faust einen Minecraft-Server für einen kleineren Twitch-Streamer. Es war Anfang 2021, und der Corona-Lockdown ließ reichlich Zeit. Die Idee war einfach: Streamer wollen live mit ihren Zuschauern in einer Welt spielen, meist in kurzen Spielen, die selten länger als eine halbe Stunde dauern. Mit Java war ich damals noch nicht sehr vertraut und auf fertige Lösungen angewiesen, die meinen Ansprüchen nicht genügten. Außerdem war ich der Einzige, der wirklich mitarbeitete. In manchen Bereichen kam ich allein nicht weiter, vor allem beim Kartendesign. ### Uroria Im März 2021 lernte ich Raphael kennen. Er arbeitete damals an einem MMORPG namens „Uroria“. Er und sein Team überzeugten mich schnell: Sie waren das erste Netzwerk, das in der Minecraft Java Edition konsequent Resource-Packs nutzte. Die meisten Serverbetreiber hielten das damals für Unfug, aber die Möglichkeiten, die Resource-Packs dem Spieldesign eröffnen, konnte man nicht einfach liegen lassen. Umgekehrt überzeugte Raphael meine Idee, ein kleines Netzwerk für Live-Events mit Twitch-Streamern zu bauen. Wenige Monate später lief das erste Event: 80 Spieler gleichzeitig im PvP, für den Gewinner gab es einen Preis. Danach war auch der Rest des Teams überzeugt. Uroria wurde zum Event-Netzwerk, das MMORPG rückte in den Hintergrund. Das Team hätte kaum besser besetzt sein können. Raphael und Felix waren erfahrene Kartendesigner, Raphael versuchte sich außerdem am ersten Spielmodus „Ghosthouse“. Gebuildet war der Experte für Resource-Packs, RUBABLADADUDI machte das Grafikdesign, Jan entwickelte weitere Spielmodi, Nico baute die Website, und ich übernahm Lobby und Infrastruktur. *Wer lieber nicht mit Klarnamen auftaucht, steht hier unter seinem Pseudonym*. Natürlich gab es hin und wieder Streit, die Hälfte von uns war noch minderjährig. Kurz vor Weihnachten 2022 ging Uroria nach [einem Trailer](https://www.youtube.com/watch?v=FSv0zQjWYlg) online. Mit einer Handvoll befreundeter Streamer kamen wir auf rund 100 gleichzeitige Spieler. DDoS-Angriffe störten uns, und ich wusste damals noch nicht, wie man sie abwehrt. Trotzdem war die Resonanz bei Streamern, Spielern und Zuschauern groß. Vom Konzept waren wir überzeugt, von der Umsetzung nicht. Ich schlug vor, das Netzwerk komplett offline zu nehmen und zu überarbeiten. Die anderen stimmten zu. Ein fataler Fehler. ### Stillstand Unsere Software war der Komplexität der Laufzeitumgebung und unserer Konzepte nicht gewachsen. Inzwischen hatten wir Verstärkung bekommen, die eine eigene Cloud-Software baute: Sie sollte die einzelnen Minecraft-Server verwalten, denn ein großes Netzwerk muss automatisch horizontal skalieren. Die Idee war richtig, die Umsetzung unnötig komplex: mehrere Systeme in Rust, eigene UDP-Protokolle, Anbindung an die API der Hetzner Cloud. Nur eine Person konnte wirklich daran arbeiten, und die war durch ihr Informatikstudium ständig verhindert. Ich hatte derweil genug Zeit, das gesamte Backend innerhalb von sechs Monaten mehr als dreimal neu zu schreiben, jedes Mal anders. Erst mit Apache Pulsar, dann schien Apache Kafka besser geeignet, am Ende hielt ich RabbitMQ für die einzig brauchbare Lösung. Die anderen wussten es auch nicht besser, keiner von uns hatte mit solchen Systemen je gearbeitet. Ich suchte nach Entwicklern aus anderen Netzwerken, die vor ähnlichen Problemen standen und sich vielleicht von unseren Ideen überzeugen ließen. So stieß ich auf [Nextfight](https://nextfight.net/), ein beeindruckendes Battle Royale mit leerem Server, und traf zum ersten Mal Maxim, der es allein betrieb. Bei Uroria ging es trotzdem kaum voran. Nach etwa einem Jahr, Ende 2023, hatten wir alle die Motivation verloren. Einer nach dem anderen stieg aus, und Uroria wurde begraben. Einige wechselten zu Nextfight. Ich hielt mich von Minecraft erst einmal fern und widmete mich anderen Projekten. ## Neue Pläne Im September 2024 saß ich abends mit Raphael im Discord, und wir sprachen über die Szene, in der wir uns seit Jahren bewegten. Ernstzunehmende Konkurrenz für unsere Konzepte gab es noch immer nicht. Die meisten scheiterten an ähnlichen Problemen wie wir damals oder waren schlicht zu unkreativ. Auch bei Nextfight sahen wir große Probleme in der Infrastruktur, und die Nachfrage nach dem, was wir uns längst ausgedacht hatten, wurde immer größer. Also beschlossen Raphael und ich kurzerhand, ein Entwicklerstudio zu gründen. Es war, für meine Verhältnisse, spät am Abend, als mir der Name einfiel: „o7studios“. „o7“ war ein beliebtes Emote unter Twitch-Streamern und steht für einen Salut. Wir fanden das beide lustig. Wenige Tage später war das Logo gezeichnet, und die Entwicklung begann. ### Schon wieder Over-Engineering Diesmal hatten wir Erfahrung, und jeder kannte sich auf seinem Gebiet aus. Ich beherrschte inzwischen Kubernetes, das eine eigene Cloud überflüssig machte. Aber Kubernetes ist nur ein Beispiel für viele Systeme, mit denen wir uns enorm viel Komplexität in die eigene Verantwortung holten. Wir hofften, mit einer deklarativen Infrastruktur die Komplexität künftiger Laufzeitumgebungen und Konzepte schon im Voraus zu beherrschen. Die Ergebnisse waren vielversprechend. Nur bauten wir vorausschauend für künftige Projekte und nicht an dem, was tatsächlich mit dem Spiel zu tun hatte. Und wieder konnten nur wir Entwickler mit unserer eigenen Plattform umgehen. Wir hatten denselben Fehler wiederholt. ### Überforderung Gegen Ende 2025 wurde der Druck riesig. Wir hatten die [Heldeninsel](https://heldeninsel.net) als Projekt übernommen, die zuvor an ähnlichen Problemen gescheitert war. Viele von uns arbeiteten, wie ich, nebenbei hauptberuflich. Der Quellcode war inzwischen so komplex geworden, dass nur noch ich wirklich daran arbeiten konnte, weil den anderen die Zeit fehlte, sich einzuarbeiten. Am 23. Dezember 2025 wurde es mir zu viel. Mein Körper hatte schon länger Warnsignale gesendet, die ich ignoriert hatte. Ich stieg aus, von einem Tag auf den anderen. Gebuildet, Maxim und Raphael machten niedergeschlagen weiter und gaben zum Glück einige komplexe Systeme auf, die sie sich ohnehin nicht zutrauten zu warten. Im Hochsommer 2026 ging die Heldeninsel nach gewaltigen Rückschlägen und einer massiven Überarbeitung durch Raphael, Gebuildet, Maxim und allen anderen Beteiligten erfolgreich online. Vor dieser Leistung habe ich großen Respekt. ## Ashbys Gesetz Over-Engineering ist in der Softwareentwicklung extrem verbreitet. Man versucht, eine Software schon heute auf jede Situation vorzubereiten, die morgen eintreten könnte. Das klingt vernünftig und hat sogar eine kybernetische Begründung: Nach Ashbys Gesetz der erforderlichen Varietät kann ein System nur so viele Störungen ausgleichen, wie es selbst unterschiedliche Zustände annehmen kann. Wer die komplexen Probleme von morgen lösen will, braucht dafür komplexere Software. Was dabei vergessen wird: Ashbys Gesetz gilt zweimal. Die Software muss ihrem Problem gewachsen sein. Aber das Team muss auch seiner Software gewachsen sein. Jede Komplexität, die wir für die Probleme von morgen einbauen, müssen wir heute schon verstehen, warten und steuern können. Und die Probleme von morgen treten oft nie ein. ![Grafik: Zwei Balkendiagramme zur Varietät von Team, Software und Problem. Links angemessen, alle drei etwa gleich hoch. Rechts Over-Engineering: Die Software ist für Probleme gebaut, die es noch nicht gibt, und überragt das Team. Den Teil darüber kann das Team nicht mehr steuern.](../../assets/over-engineering.png) Genau das ist uns zweimal passiert. Bei Uroria konnte nur eine Person die Cloud bauen, bei o7studios nur ich den Quellcode. Die Software war nicht zu schwach für ihr Problem, sie war zu stark für ihr Team. Daraus können wir Softwarearchitekten und -entwickler lernen: Ein Softwaresystem sollte nur so komplex sein, wie das Problem es verlangt, das es **heute** lösen soll, und nur so komplex, wie das Team, das es betreut, heute beherrschen kann.