# Scaling Legacy Dev Principles for Modern Enterprise Architecture

**Podcast:** Software Architektur im Stream
**Published:** 2026-05-18

## Transcript

So, herzlich willkommen zu einer weiteren Episode von Software-Harchitecture im Stream.
Heute über John Romeros Prinzipien mit Tom.
Tom, möchtest du dich erstmal vorstellen und zwei Worte über dich sagen?
Ja, sehr gerne.
Ich weiß nicht, ob ich schon zwei Worten schaffe, aber ich versuche es kurz zu halten.
Tom Arsel, 45 Jahre, ich bin Software-Architekt aus Südhessen.
Ich arbeite bei Tangible Concepts.
Wir machen agile Architekturarbeit, habe das Unternehmen vor vier Jahren mitgegründet.
Ich war in der Vergangenheit viel in Rollen unterwegs, die mit Architekturverantwortung zu tun hatten.
Und heute mache ich mehrheitlich Beratung und Coaching, Training rund um Softwarearchitektur.
Ja, Brückenschlag zum heutigen Thema ist also so eine Lieblingsaufgabe dabei ist, Teams architekturfähig zu gestalten.
Und dabei sind halt eben Prinzipien total hilfreich.
Also da können wir dann bestimmt gleich ein bisschen anknüpfen daran.
Darüber hinaus, ich bin viel in Communities unterwegs, im ISAKB, in der DDD-Community, in der Komo-Community.
Und ja, so ein Schwerpunkt dabei ist die kollaborative Architekturarbeit.
Genau.
Und Aufhänger war, dass wir uns auf den Dev Days gesehen haben.
Und da hatte der John Romero diesen Vortrag gehalten und den gab es vorher schon mal auf dem World Wide Developer Congress.
We are Developers World Congress, glaube ich.
Und wir verlinken da auch nochmal ein Video.
Und da spricht er halt irgendwie über seine Karriere und halt über diese Prinzipien insbesondere.
Und du kamst dann halt mit der Idee, auf mich zu, da zu mal eine Episode zu machen und diese Prinzipien halt zu diskutieren.
Ja, genau soweit richtig.
Die Konferenz, auf der wir es gesehen hatten, war die DevLand.
DevLand.
Genau.
Okay, ja.
Sorry.
Die heißen alles so ähnlich.
Genau.
Sollten wir erstmal über John Romero reden und warum man überhaupt ihm zuhören sollte und halt seine Prinzipien vielleicht sich anschauen sollte.
Willst du, soll ich was dazu sagen?
Ich glaube, wir können da beide was dazu sagen.
Fangen doch du mal so mit den Hard Facts an.
Genau, also John Romero ist einer von den Menschen hinter id Software.
id Software ist die Firma, die halt unter anderem Doom und Quake.
hergestellt hat und damit halt gleich mehrere Dinge revolutioniert hat.
Also einmal Shareware als Vertriebsmodell.
Traditionell ist es halt so, dass wir sollten vielleicht sagen, das sind Computerspiele, First-Person-Shooter und tatsächlich die ersten First-Person-Shooter so richtig.
Naja, kann man jetzt drüber diskutieren.
Also vielleicht ist Wolfenstein 3D, was die auch gemacht haben, noch davor ein First-Person-Shooter gewesen, aber dieses Genre haben sie zumindest im Wesentlichen beeinflusst.
Dann hat Shareware als Vertriebsmodell ein Thema.
Das heißt, wenn man halt Doom kann, kann man einfach runterladen.
Kann man immer noch einfach runterladen.
Man kriegt, glaube ich, die ersten vier Levels mit und die restlichen Levels, die kriegt man halt, wenn man den vollen Preis zahlt.
Dann haben sie halt dieses Thema mit den Spiele-Engines.
Hat auch als Erste sich überlegt.
Also Doom ist eben eine Spiele-Engine.
Das heißt, das, was man dort bekommt, ist halt ein Programm, was eben letztendlich ein eigenes Format auslesen kann, also diese Word-Files.
Und das bedeutet, dass man damit prinzipiell halt auch andere Dinge bauen kann.
Das heißt also, in diesen Word-Files sind halt die Grafiken drin, die Levels.
Und das bedeutet, man kann halt dann mit der Doom-Engine andere Sachen halt bauen.
Und dadurch ist dieser Markt entstanden, der halt heute durch sowas wie Unity oder Unreal Engine dominiert wird.
Da waren die halt die Ersten.
Und das ist halt ein Open-Source, auch ein Open-Source-Thema.
Das heißt, die ganzen Sachen sind halt später dann als Open Source rausgekommen, nach einiger Zeit.
Und das führt dann wieder zu, dass halt Doom immer noch weiterentwickelt wird mit anderen Grafikbasissachen.
Und deswegen gibt es ja auch diese berühmte Geschichte mit Kenneth Run Doom, wo man eben Doom dann auf Küchenweckern und Küchenmaschinen und irgendwas laufen lässt.
Und das ist, glaube ich, so das, was erstmal die Firma und ihn selber ausmacht.
Genau.
Da kann man vielleicht ergänzen.
Also was halt total spannend ist, die waren unglaublich produktiv.
Also die haben mit einem sehr kleinen Team, also Doom ist noch mehrheitlich mit vier Entwicklern entstanden in sehr, sehr kurzer Zeit.
Also die haben in sehr kurzer Zeit wahnsinnig viel Output mit einer extrem hohen Qualität erzeugt.
Und allein das ist schon mal so was, wo man mal drauf gucken kann.
Also ist das eine Sache, die halt damals ging, aber heute so vielleicht gar nicht mehr?
Wenn ja, warum sollte das so sein?
Er hat diesen Vortrag.
ein paar Mal gehalten auf verschiedenen Konferenzen über viele Jahre hinweg.
Der hat sich auch inhaltlich gar nicht groß verändert.
Naja, klar, ist ja...
so retrospektiv quasi, was haben wir denn damals Cooles gemacht, um so erfolgreich zu sein.
Aber das ist dann schon ganz spannend, wenn er da so Prinzipien nennt, die Sie da zu befähigt haben, so produktiv zu sein und halt eben die Sachen in der Qualität rauszuhauen.
Von daher lohnt es, glaube ich, sich das mal anzuschauen.
Ich fand den Talk zumindest mal ganz interessant und bin da ja, also selber in meiner Jugend, habe ich mich sehr viel mit den Produkten des Softwarehauses ID auseinandergesetzt, also wie vielleicht viele so in unserer Altersgruppe.
Also ja, so.
War für mich ganz spannend, mal so viele Jahre später zu hören, wie kam es denn eigentlich dazu?
Genau.
Coding Popo Tentakel auf Twitch wirft noch ein Doom in einem PDF.
Ich glaube, es gibt es auch in Excel.
Also das läuft irgendwie tatsächlich überall.
Und noch so eine kleine Kleinigkeit ist halt, dass die Firma It, und das hat er meiner Ansicht nach im Talk auch gesagt, tatsächlich so ein bisschen mit Next verbandelt ist.
Also die Firma, die hat Steve Jobs zwischen seinen beiden Aufenthalten bei Apple mitgegründet hat, weil sie halt auf den Maschinen letztendlich entwickelt haben und auch einige von den Entwicklungstools, also die Leveleditoren für Doom und Quake, das sind halt Next-Step-Anwendungen, die halt irgendwie auf den Next-Maschinen laufen.
Das ist vielleicht noch so ein ganz, vielleicht ein nettes Detail.
Genau.
Hier steht noch Voraussetzung.
Ich weiß gar nicht, ob wir das jetzt alles ab...
Ich glaube, ich würde mal so noch einsteigen.
Also er hat einen Talk gehalten über Prinzipien und jetzt kann man natürlich erst mal die Frage stellen, also ist das überhaupt heute noch relevant?
Also er sagt selber in seinem Talk, so manche davon sind vielleicht heute auch noch wichtig.
So in Anführungszeichen quasi.
Also es lohnt da mal drauf zu gucken, welche davon sind denn wirklich für uns relevant?
Vielleicht auch außerhalb der Domäne der Spieleentwicklung.
Also so eine Frage, die wir uns natürlich stellen können mit einer Architektenbrille ist, ist das überhaupt was?
Was man übertragen kann auf zum Beispiel Informationssysteme oder sind das einfach nur Dinge, die spannend sind, wenn ich selber Games entwickeln möchte?
Also ich selber habe überhaupt keine Ahnung vom Game Design, von Spieleentwicklung.
Ich bin ja nur auf der Konsumentenseite.
Aber am Ende des Tages ist auch das Software.
Und das ist durchaus spannend, sich anzuschauen, also welche Sachen funktionieren denn da gut und die können wir uns vielleicht ja auch abgucken, auch dann, wenn wir in einem ganz anderen Umfeld unterwegs sind und mit Teams irgendwie im Informationssystem, im Enterprise-Bereich unterwegs sind.
Vielleicht ist ja das durchaus spannend für uns.
Also gerade wenn man sich anguckt, wie unglaublich produktiv die waren und was für ein Qualitätsbewusstsein dahinten dran gesteckt haben muss.
Genau, und in dem Kontext, also das ist halt ein Startup, die haben keine andere Chance.
Also die müssen halt mit den vier oder fünf Leuten...
loslegen und halt irgendwie erfolgreich sein.
Das ist im Enterprise-Kontext was anderes.
Und ich glaube, ein Team, das halt die Mission-Critical-Anwendung baut für irgendeine Versicherung oder Bank, und das sind nämlich vier Leute, das wird möglicherweise als Risiko angesehen.
Und das ist so ein bisschen, weil du halt abhebst auf diese Produktivität, das ist nachvollziehbar.
Ich glaube ja auch, dass Produktivität ein wichtiger Punkt ist, aber die Enterprise-Umgebung ist halt eine andere und ich glaube, es ist kein Zufall, dass da größere Teams sind.
So, jetzt hat Coding Purpotentake geschrieben, kann man generell sagen, dass eine nischige Branche grundsätzlich produktiver ist, als wenn die dann Mainstream wird?
Ich glaube, das gleich in der Veranstaltungstechnik gesehen zu haben, seit es dort eine Ausbildung gibt, gibt es Leute, die das nur als Job machen.
Kann das sein?
Ja, also es ist ein bisschen das, was ich vorhin versuchte zu sagen.
Ich glaube aber, dass es ein Startup-Thema ist.
Also wenn wir uns jetzt zusammensetzen und zu vierten Startup gründen, müssen wir, komme was wolle, mit vier Leuten das halt hinbekommen.
Und in einem Enterprise-Umfeld ist das halt irgendwie was anderes.
Und ich glaube, dass deswegen das Umfeld das sicher determiniert.
Und ja, also, ja, kann halt sein, dass eben Leute, die das tatsächlich irgendwie als Job machen, um halt Geld zu bekommen, vielleicht eben nicht diese ...
24 Stunden am Tag entwickelte ich Mentalität haben.
Die waren damals eben auch jung.
Und ich glaube, dass der halt kein ernsthaftes Leben aussah, also keine großen Familienverpflichtungen oder sowas hatten außerhalb der Arbeit.
Ich glaube, das kann man so aus den Kommentaren und dem, was auch Romero in dem Vortrag so nebenbei so fallen gelassen hat, durchaus rausziehen.
Also diese Produktivität, die haben sie sich halt mit so etwas wie 30 Stunden am Stück durch Coden auch erhalten oder erkauft.
Und man kann darüber streiten, ob das nachhaltig ist.
Ob das sinnvoll ist, aber wie du gerade richtigerweise sagst, also im Startup-Mode ist man halt auch anders unterwegs, als wenn ich einen 9- bis 5-Job als Angestellter in einem Versicherungsunternehmen oder in irgendeinem anderen größeren Unternehmen habe.
Die Randbedingungen sind unterschiedlich.
Und da würde ich gerne bei dem, was wir jetzt gleich machen, wenn wir uns die Prinzipien einzeln angucken, mal so ein Augenmerk drauflegen.
Also vielleicht ist nicht nur das Prinzip an sich, die sind halt sehr knackig formuliert, spannend, sondern sich Gedanken zu machen, was braucht es denn so an Randbedingungen, damit das funktionieren kann, damit es erfolgreich ist.
Und ist das wirklich eine Randbedingung, die wir haben oder die wir wollen?
Das ist, glaube ich, so etwas, was da hinten dran steht.
Ja, für mich spielt da noch was anderes eine Rolle.
Also tatsächlich ist es halt, mache ich demnächst wieder, weil letztes Jahr dort und dieses Jahr wieder diese TechStream-Konferenz, die hat auch im Wesentlichen tatsächlich Coding Pro Potentage mit organisiert.
Und das ist halt eine Konferenz, die hat tatsächlich, glaube ich, also einmal bei Twitch stattfindet und glaube ich auch einen stärkeren Bezug zu Game Development hat.
Das ist einmal eine andere Welt und insbesondere bei Romero ist es halt so, dass er sozusagen keine formale Ausbildung halt durchlaufen ist.
Und ich finde es halt interessant, also nach meinem Wissensstand, das mag falsch sein, ich finde es halt interessant, welche Prinzipien sich sozusagen herauskristallisieren, wenn man einfach sagt, okay, ich versuche mal Software zu entwickeln.
Und dann sehe ich mal, wie ich erfolgreich bin und wie das irgendwie abgeglichen ist mit dem, was eben die akademische Forschung und irgendwie auch sonst die Enterprise-Umgebung sagen.
Und das ist ein ganz wichtiger Punkt.
Also man muss da aufpassen, dass wir jetzt nicht so Opfer dieses Survivorship-Bias werden.
Also die haben Erfolg damit gehabt.
Die haben das geschafft, über viele, viele Jahre da sich einen Ruf aufzubauen.
Die haben es geschafft, dass man dann irgendwie 30, 40 Jahre später sich Vorträge dazu anhört.
Wie habt ihr das denn Tolles gemacht?
Diese Vorträge sehen wir und hören wir.
Wir hören nicht die Vorträge von den 150 anderen Teams, die es nicht geschafft haben, obwohl die ebenfalls brillante Köpfe hatten und die damit halt grandios gescheitert sind.
Also alles, was wir jetzt besprechen, muss man sich, glaube ich, so mit einem kleinen Quäntchen Salz genießen.
Und man muss ein bisschen aufpassen, wie man das nimmt.
Also ich glaube, eine Warnung sollten wir aussprechen vorneweg.
Ich glaube, auch Romero würde das nicht als Blueprint sehen.
Im Sinne von, mach das so wie wir, dann seid ihr ultimativ erfolgreich.
Sondern naja, es hat halt für sie in der Zeit geklappt.
Nichtsdestotrotz gucken wir drauf.
Vielleicht sind ein paar Sachen drin, die wir heute auch nutzen können.
Ich sage jetzt nochmal zwei Sätze.
Romero konnte halt an die Erfolge mit id Software nicht anknüpfen.
Also, nach Quake hat er das Unternehmen verlassen.
Und danach hat er halt durchaus auch in der Branche noch weitergearbeitet.
Aber es ist halt nicht mehr so dieses durchschlagende Ding rausgekommen.
Während halt Carmack ja unter anderem dann bei Oculus mitgearbeitet hat an dem VR-Thema.
Das ist vielleicht auch nochmal so ein Punkt, den man halt machen muss.
Genau.
Aber dann wollen wir jetzt tatsächlich die Prinzipien uns anschauen.
Muss ich mal sehen.
Was war das?
Genau.
Da ist also der erste Bildschirm und das wäre halt das erste Prinzip.
Also, no prototypes, keine Prototypen.
Bau einfach das Spiel.
Just make the game polish as you go.
Also, polier es halt oder verbessere es halt, während du halt entwickelst.
Und don't depend on polish happening later.
Also, verlass dich nicht darauf, dass du es halt später irgendwie sozusagen besser, hübscher machen kannst und besser machen kannst.
Always maintain constantly triple code.
Also sorg halt dafür, dass es immer Code gibt, den man ausliefern kann und dass der Code halt immer in einem auslieferbaren Zustand ist.
Tom, was denkst du darüber?
Ja, das macht was mit mir.
Das triggert mich.
Das ist gleich dieser erste Satz, nur Prototypes.
Also warum?
Also Prototypen sind für mich ein sehr, sehr wichtiges Werkzeug, also um halt eben schnell...
Erkenntnisse zu sammeln.
Also wenn wir halt irgendwie Hypothesen haben, die wir überprüfen wollen, dann sind Prototypen natürlich was, was total hilfreich sind.
Und hier steht ja so ganz knallhart, nee, machen wir nicht.
Jetzt muss man das ein bisschen in den Kontext setzen.
Also eine Möglichkeit, mit Prototypen sinnvoll zu arbeiten, ist halt schnell Feedback zu bekommen.
Wenn ich das nicht habe, wirft das natürlich Fragen auf, wie komme ich denn an Feedback?
Was mache ich denn stattdessen beispielsweise?
Und ich glaube, man muss jetzt ein bisschen versuchen zu verstehen, wie, also möglicherweise ist es nicht so strikt gemeint, wie es da jetzt steht.
Ich glaube, was er sagen wollte, ist, sie haben nicht erst eine Demo produziert, dann irgendwie das Leuten gegeben und geguckt und dann mal irgendwie weitergemacht, sondern sie haben halt ein Spiel gemacht.
So, in sehr engem Zeitrahmen und der ließ halt wahrscheinlich wenig Platz für Experimente.
Er hat so ein paar Anekdoten dazu erzählt.
Also zum Beispiel auch, dass alle Leute von Anfang an eine sehr starke Vision hatten.
Also alle hatten das Spiel konkret im Kopf, wenn sie angefangen haben zu arbeiten.
Letztlich hatten sie dann eine Liste von Items, die sie runterarbeiten müssen.
Für mich klingt das total brutal nach Wasserfall.
Also war in dem Kontext vielleicht genau das Richtige und hat da vielleicht gut funktioniert.
Aber heißt halt eben auch, also er nennt es auch Rapid Development to the Extreme.
Also sie haben halt extrem schnell was entwickelt und das setzt natürlich voraus, dass alle wissen, was sie da tun.
Also ich würde das jetzt so interpretieren, die waren sich so sicher.
bei dem, was sie vorhaben, dass sie vielleicht gar nicht diesen Mechanismus gebraucht haben, über Prototypen einzelne Hypothesen zu überprüfen oder halt eben mehr Feedback zu bekommen.
Sie haben es halt einfach gemacht, wirft natürlich trotzdem so ein paar Fragen auf.
Das ist jetzt so das Erste, was es mit mir gemacht hat, als ich es gehört habe.
Wie sieht es bei dir aus?
Also ich glaube, das Prinzip zeigt schon so ein bisschen die Schwäche, die ich glaube ich bei dem ganzen Thema sehe.
Das ist nicht wirklich, sauber nochmal hingeschrieben und sauber nochmal sozusagen auf das ganz Wesentliche und auf den Kern reduziert.
Also eigentlich sind das ja drei Prinzipien, also da steht halt einmal keine Prototypen, darauf bist du jetzt abgehoben und hast halt gesagt, naja, das ist halt, also ich würde behaupten, die Aussage ist falsch und es ist für mich schwer vorstellbar, dass die tatsächlich, also dass die das tatsächlich gelebt haben.
weil ohne einen Prototypen kriege ich keinen Product-Market-Fit hin.
Und wenn ich halt nicht dazu in der Lage bin zu sagen, okay, hier ist eine Idee, ich baue das mal kurz und dann schaue ich halt, ob sie halt funktioniert, dann werde ich halt nicht zum Ergebnis kommen.
Und ich glaube auch nicht, also mindestens bei Doom 3, da habe ich das sozusagen selber erlebt, aber das ist eben nach seiner Zeit, war es eben so, dass das fertige Produkt deutlich anders war als das, was man mal als Demos gesehen hat.
Deswegen finde ich das schwierig und ich glaube, dass er in Wirklichkeit dann, Das meint, was hier in dem zweiten Absatz steht.
Also sorgt halt dafür, dass die Codequalität immer stimmt.
Und da ist halt, also das unterstelle ich, ich glaube, dass er damit eben innere Qualität meint, also Codequalität, Änderbarkeit, sowas nicht unbedingt äußere Qualität.
Also ob das Spiel jetzt irgendwie nach draußen gut wirkt oder irgendwie nicht.
Den Punkt kann man nachvollziehen, der kommt uns an unterschiedlichen Stellen nochmal zum Tragen.
Ich kann an der Qualitätsschraube zwar drehen, aber wenn ich an der Qualitätsschraube drehe und sage, weniger Qualität ist okay, dann bedeutet das, dass ich mindestens in Erwartungen Schwierigkeiten habe und man kann sich jetzt überlegen, an welcher Stelle dieses Problem mit der schlechten Wartbarkeit zuschlägt.
Das heißt, ich habe vielleicht einen kurzfristigen Vorteil.
Die Frage ist, wie kurzfristig der ist und dann ist es halt, dass man halt sagt, okay, wir verzichten komplett auf diesen kurzfristigen Vorteil und wir setzen halt auf eine nachhaltige Entwicklung, die halt das dann im Wesentlichen sagt.
Der letzte Punkt, da mit dem nicht immer wartbaren, immer auslieferbaren Code erstellen, ich glaube, da haben wir ja auch im Vorhinein nochmal drüber diskutiert.
Das ist heute, glaube ich, etwas, was typischerweise irgendwie eh klar ist nicht.
Wir haben CI-Pipelines, wo man halt Continuous Integration betreibt.
Wir haben Continuous Delivery Pipelines, mit denen wir halt Sachen in Produktion bringen.
Das ist eine gute Idee, wenn diese Sachen halt irgendwie konstant in Produktion gebracht werden können.
Damals war das was anderes.
Ich habe halt auch nach der Jahrtausendwende in einem Projekt gesessen, wo wir halt 14 Tage halt den Spaß hatten, also ich nicht, wo 14 Tage Menschen den Spaß hatten, dafür zu sorgen, dass erstmal die verschiedenen Änderungen der dass man die verschiedenen Änderungen der verschiedenen Teams irgendwie zusammenbekommt und dafür sorgt, dass sie überhaupt erstmal kompagieren.
Und das ist deutlich entfernt von diesem konstant auslieferbaren Code haben.
Das ist aber etwas, was, ich habe es ehrlich gesagt nicht detailliert nachrecherchiert, aber etwas, was Microsoft zum Beispiel in den 90ern auch gemacht hat, um eben dazu in der Lage zu sein, auch halbfertige Produkte jederzeit ausliefern zu können.
Und von daher ist das jetzt irgendwie nichts, was IT alleine sich überlegt hat.
Aber damit haben wir halt irgendwie so drei Prinzipien und das ist halt irgendwie, ja, schwierig.
Ich glaube, es lohnt nochmal, sich so ein bisschen in die Zeit reinzuversetzen.
Also du hast es auch gerade CI genannt.
Also CI gab es vielleicht damals auch schon, vielleicht nicht überall, vielleicht nicht so weit verbreitet.
Den Begriff kannte vielleicht auch nicht jeder in der Industrie.
Nicht mit der Bedeutung, wie wir es heute haben.
Vor allem sind wir heute in einer verdammt komfortablen Position, zumindest mal jetzt im Bereich Informationssysteme.
Also wenn ich jetzt zum Beispiel feststelle, dass ich irgendwo einen Fehler eingebaut habe, zum Release-Zeitpunkt ist der noch drin, dann ist das im Zweifel einfach, einen Patch nachzuschieben und ein System, das irgendwo auf dem Server läuft, mit einer aktuelleren Version auszurollen.
Damals, in den guten alten Zeiten, Da bedeutete halt Release und Shipping, na ja wirklich, da hat jemand angefangen, Dinge in eine Poststation zu tragen.
Die waren dann drei Tage per Mail unterwegs, also wirklich per physischer Post und sind dann beim Kunden gelandet.
Und dann hast du natürlich eine ganz andere Situation, wenn dir drei Tage nach dem Release auffällt, oh, wir haben da irgendwie noch einen Bug, der ist irgendwie not nice, den möchte ich noch rauskriegen.
Also das Qualitätsversprechen, was man da abgeben musste, das war halt vielleicht nochmal eine Spur härter.
Und so erklärt sich, glaube ich, auch so diese Striktheit in diesem Prinzip.
Und wir werden nachher noch ein paar Prinzipien sehen, die das wieder so aufgreifen.
Oh ja, da kommt gerade ein Kommentar des Kettenzeit.
Also die Anekdote, die Romero da in dem Talk mitbrachte, ist halt auch nice.
Also wie haben sie Code geteilt?
Es gab zu dem damaligen Zeitpunkt natürlich schon Versionskontrollsysteme.
Also CVS gab es damals schon namentlich und auch noch andere.
Aber er sprach halt davon, dass sie halt Code auf...
Disketten kopiert haben und sich dann durch den Raum durchgeworfen haben.
Also das war ihre CI-Pipeline, wie sie integriert haben.
Different zu dem, was wir heute kennen, hoffe ich zumindest.
Coding Purportentagel hat noch gefragt, wie passt der letzte Punkt mit Refactoring zusammen?
Ich sehe eigentlich, also das ist ein guter Punkt, ich sehe eigentlich das Thema Refactoring eher bei diesem Polish as you go.
Also das ist eigentlich für mich dieses, ich versuche halt das System wenn es denn da tatsächlich um innere Code-Qualität geht, konstant zu verbessern.
Das, by the way, ist auch eines der Probleme, was ich halt so ein bisschen habe.
Ich glaube, da kommen wir jetzt bei den späteren Prinzipien auch nochmal dazu.
Refactoring bedeutet ja, dass ich den Code ändere und zwar sozusagen vom Aufbau ändere, aber dabei das Verhalten gleich lasse.
Das heißt, es gibt unendlich viele Möglichkeiten, wie man halt ein Stück Code refactoren kann.
Und dieser zweite Punkt hat so ein bisschen, also dieses, dass ich das poliere, hatte halt so ein bisschen das Problem, dass man sich auch totrefaktoren kann.
Und dass ich dann halt in einem Loop bin, wo ich halt irgendwie nur sage, es muss noch besser werden, es muss noch besser werden und halt nicht mehr dazu komme, Code halt sozusagen zu shippen.
Ich glaube, das ist sogar eins von den nächsten Prinzipien, wenn ich es richtig sehe.
Es gibt ein paar, die sind nicht so wirklich trennscharf, finde ich.
Ich habe die auch in der Reihenfolge jetzt so angeordnet, wie ich sie sinnvoll aufeinander aufbauend sehe.
Das war nicht unbedingt die Reihenfolge, die er in seinem Talk hatte.
Aber ja, ich glaube, man kann es dann erkennen.
Wenn wir zum nächsten springen, greifen wir so ein paar von den Sachen nochmal auf, die wir gerade gesehen haben.
Genau, also da steht, we are our best testing team, also wir sind unser bestes Test-Team und should never allow anyone else to experience bugs or see the game crash.
Also wir sollten nie dafür sorgen, dass halt, oder nie erlauben, dass halt irgendjemand anders bugs sieht oder dass das Spiel halt abstürzt.
Und dann ist halt der zweite Absatz, don't waste others time, also verschwende nicht die Zeit anderer.
Und dann steht da test thoroughly before checking in your code, also teste halt dein Code ausführlich, bevor du ihn eincheckst.
Genau, willst du dazu was sagen?
Ja, eine ganze Menge.
Also was mir da so auffällt ist, Da haben wir wieder das Gleiche drin wie in dem vorigen Prinzip.
Also hier geht es darum, dass wir nicht abhängig sein wollen davon, dass andere irgendwie noch was tun.
Im vorigen Prinzip ging es darum, dass dann später nochmal irgendwelches Polishing stattfindet durch uns oder durch andere.
Hier nochmal, dass andere irgendwie was beitragen müssen zum Testen.
Also das finde ich nochmal ein ganz, ganz spannendes Ding.
Was da für mich rauskommt, auch dieses Don't waste others' time, das ist ganz klar.
Also die saßen halt zu viert irgendwie in...
in einem Raum und haben dann halt sich die Disketten zugeworfen.
Und wenn dann was nicht geklappt hatte, dann warst du quasi dafür daran schuld, dass das Team jetzt nicht vorankommt.
Und was das, glaube ich, ganz schnell auslöst, ist eine ganz krasse kognitive Last.
Also für mich erst mal was, was negativ ist.
Zum einen, sie hatten natürlich offensichtlich ein sehr, sehr starkes...
Qualitätsbewusstsein, alle im Team.
Das ist eine gute Sache.
Ich glaube, jedes Team profitiert davon, wenn wir alle eine klare Vision haben, wenn wir alle genau wissen, was wollen wir eigentlich tun, was ist das Ziel, was wir erreichen und welchen Qualitätsstand erwarten wir davon.
Auf der anderen Seite ist es natürlich auch irgendwie belastend, wenn ich jetzt weiß, ich kann mir keinen Fehler erlauben und das muss absolut perfekt sein.
Ansonsten hängen wir irgendwie alle da mit dran.
Also das ist auch so ein bisschen, muss man hinterfragen.
Also gerade auch mit den Werkzeugen, die Sie damals da irgendwie hatten.
Genau.
Also, Coding-Pur-Portentake wirft halt erstmal ein, findet unser Test hier bestimmt super, wenn die nichts mehr machen müssen.
Also, da sind ja, ich würde behaupten, da sind wieder zwei Prinzipien.
Das erste ist halt die Aussage, teste halt selber so ausführlich, dass halt niemand sonst Fehler sieht oder dafür sorgt, dass das Spiel halt irgendwie zerbricht.
Ich kann mich bei Enterprise-System dem nicht anschließen.
Weil das impliziert, dass die Menschen, die vor dem Rechner sitzen, genügend fachliches Wissen haben, um dafür zu sorgen, dass sie ja tatsächlich alle Fehler finden.
Das ist absurd.
Und das impliziert, dass ich andere Leute habe, die halt insbesondere aus einer fachlichen Perspektive dann nochmal drauf gucken müssen.
Also selbst wenn ich es schaffe, den Code, also Perfekt Requirements umzusetzen in Code, das ist schon schwierig.
Aber wenn ich das schaffe, selbst dann werde ich noch fachliche Fehler haben.
weil irgendwelche Dinge in den Requirements nicht stimmen.
Und dann halt den Anspruch zu haben, dass halt niemand jemals einen Bug sieht, sehe ich halt irgendwie nicht.
Und ich glaube, der Hinweis von Coding Pro Potentacle ist halt auch richtig.
Es gibt halt Testteams, die sind anders aufgesetzt.
Ich sehe nicht so unbedingt, dass man jetzt sagt, also das ist tatsächlich ja die letzte Konsequenz.
Die brauchen wir halt nicht mehr.
Finde ich komisch.
Also es gibt die aus dem Grund.
Und es ist insbesondere ja so, dass man da nochmal möchte, dass halt ein...
zweites paar Augen drauf gucken.
Wenn ich etwas baue und denke, das ist perfekt, habe ich mein eigenes Ding, von dem ich denke, wie es sein sollte.
Das finde ich dann schwierig.
Kuding Pro Potentake schreibt, ich würde dem ersten Punkt sogar widersprechen.
Eigentlich bist du selber sogar der schlechteste Tester, weil du weißt ja, was man machen muss.
Software geht meist kaputt, wenn Leute daran kommen, die nicht wissen, was sie machen müssen.
Die Art und Weise, wie BenutzerInnen die Software benutzen, kann man nicht vorhersehen.
Ich glaube, hier spielt bis zu einem gewissen Maß auch der Sonderfall eine Rolle, dass eben der Mensch, der vor dem Rechner sitzt, also in dem Fall der John Romero, zum einen auch ein Kunde ist, weil das Leute sind, die selber Computerspiele spielen.
Und man muss vielleicht auch darauf eingehen, dass die Rolle von dem John Romero so ein bisschen, wie soll ich sagen, also ich glaube, Ich hatte es nochmal nachgelesen als Vorbereitung hier drauf und er hat zum Beispiel ganz viel Level-Design gemacht.
Das ist was anderes als die Engine selber bauen.
Ich glaube, das war irgendwie der John Carmack eher.
Und das bedeutet halt, dass er vielleicht irgendwie tatsächlich so eine Dominen-Experte ist.
Das ist maßlich, weil er eben sich halt überlegt, wie die Levels halt aussehen.
Aber ja, das wird das, was mir dazu noch einfällt, zu dem ersten Teil.
Ich glaube, das ist ein ganz wichtiger Punkt, der da drin steckt.
Also versuchen wir es mal konstruktiv auszudrücken.
Also was nehmen wir denn da für eine Lehre aus diesem Prinzip mit raus?
Also was wir, glaube ich, sagen können ist, die Situation, die Randbedingungen, die wir hier hatten, die ist eine andere, als wir in den meisten Unternehmen finden würden.
Denn wir haben hier ein vollständig empowertes Team.
Die haben alles Wissen, was sie brauchen, um sämtliche Entscheidungen selber zu tragen.
Also genau deswegen brauchten sie diese Testabteilung und das Domänenwissen von anderen Experten nicht.
Sie waren ihre eigenen Domänen-Experten.
Das ist natürlich eine sehr komfortable Rolle, wahrscheinlich auch sehr anstrengend, aber immerhin, da war alles an Wissen da.
Und wenn man jetzt dieses Prinzip nimmt und sagt, hey, der Mann spricht mir aus der Seele, das will ich mit meinem Team ganz genau so machen.
Das verkaufe ich jetzt meinem Business auch so.
Wir machen jetzt die Romero-Prinzipien.
Dann sollte man sich genau diese Randbedingungen angucken und überlegen, sind wir in einer Situation, dass das bei uns auch funktionieren würde?
Und da glaube ich halt, die meisten Teams, die ich bisher gesehen habe, sind nicht in dieser komfortablen Position.
Und Eberhard, du hast das vorhin genannt, also die Fachlichkeit.
Kann ich die Fachlichkeit wirklich so durchdringen?
Ja, die konnten das, weil die halt die Kunden ihrer eigenen, also ihre eigenen Kunden quasi waren.
Dogfooding at its best.
Die waren halt einfach begeisterte Gamer.
Das könnte ich jetzt von den wenigsten Teams behaupten, die jetzt in einer sehr komplexen Domäne unterwegs sind.
Also da sind sie nicht unbedingt diejenigen, die am meisten Ahnung von haben.
Ja, und ich habe tatsächlich mit einem ausgewiesenen Domäne-Experten gesprochen, der tatsächlich lange Zeit in der Domäne, die dort für die Software entwickelt wird, gearbeitet hat.
Und der hat halt sowas gesagt im Sinne von, also ich mache das ja schon lange, aber ich bin immer wieder überrascht, was die Leute da draußen für komische Ideen haben.
Also nicht, und das ist jemand, der tatsächlich aus der Domäne kommt, also nur eine Ausbildung in der Domäne hat, Fachexperte ist bei einem Hersteller von Standardsoftware für eine bestimmte Domäne.
Und das fand ich halt irgendwie spannend.
Und ich fand es halt auch spannend, dass er dann halt diesen, sozusagen einen offenen Geist hat und gesagt hat, okay, die kommen da irgendwie auf coole Ideen, lass uns das unterstützen.
Der zweite Punkt, also mit diesem, nicht, du solltest halt den Code, ausführlich testen, bevor du ihn eincheckst.
Das finde ich nachvollziehbar.
Bis zu einem gewissen Maße.
Ich finde es immer so wahnsinnig schwierig, mit diesen krassen Qualitätsansprüchen, weil das, also wir machen halt Fehler.
Wir machen halt irgendwie alle Fehler.
Und das impliziert, dass man halt irgendwann mal auch Blödsinn eincheckt und halt irgendwelchen Unsinn produziert.
Und das, also damit muss man sozusagen umgehen können.
Also es kann halt möglicherweise in so eine komische Fehlerkultur umschlagen, wo man irgendwie sagt, warum hast du diesen Mist irgendwie eingecheckt?
Und naja, nicht, also passiert halt, ist halt irgendwie doof.
Und was mir da irgendwie noch auffällt, ist halt, das ist ein bisschen fast ein Widerspruch zu via Review und Pull Request.
Also das habe ich so, ja, weiß ich gar nicht, warum ich da den, vielleicht ist das halt auch kein Widerspruch, aber dieses, ich baue das halt irgendwie perfekt.
Von dort aus ist es, glaube ich, nicht weit zu.
Und deswegen brauche ich auch kein Feedback mehr, weil das ist ja perfekt.
Und das ist, glaube ich, so ein bisschen, also kann man darüber reden, das ist halt nicht ein echter Widerspruch, aber es sind halt durchaus unterschiedliche Dinge, wie man darüber denkt, glaube ich.
Ja, also das kann natürlich diesen krassen Druck aufbauen, von dem ich vorher gesprochen hatte.
Also dieses muss alles perfekt sein oder vielleicht die Fehlernahme, ich bin perfekt, das muss ich ja nicht mehr testen, das ist natürlich alles irgendwie Mist und schädlich.
Und noch ein Punkt, der mir da noch einfällt dazu.
Also solche Sachen wie halt saubere CI-Pipelines, damit, wenn Fehler auftauchen, wir die halt auch finden können und da auch uns drauf verlassen können, sind halt essentiell.
Und das kann man missverstehen als wir trauen unseren Leuten nicht oder das ist irgendwie alles doof.
Und das Gegenteil ist eigentlich der Fall.
Also wenn es auf einmal nicht mehr wehtut und nicht mehr schlimm ist, wenn ein Fehler gefunden ist, weil das halt die...
ein ganz schnelles Feedback gibt, dann ist es kulturell natürlich ein Riesengewinn.
Also dann muss ich halt auch keine Angst mehr haben, dann geht das Blame-Gain hoffentlich auch nicht los.
Aber das hat vielleicht der eine oder andere auch selber erlebt.
Es gibt natürlich auch Organisationen, bei denen das Gegenteil der Fall ist und wo halt eben dann erstmal die Frage ist, wer hat denn jetzt hier eigentlich diesen Murks eingecheckt und nicht, wie kriegen wir denn jetzt eine Lösung hin?
Ja, also ich merke das auch, dass ich persönlich diesen Feedback-Zyklus, den ein ECI-Pipeline darstellt, für wahnsinnig wichtig hat und halt für zentral.
Ich habe das Gefühl, dass es halt immer noch nicht, also wie soll ich sagen, ich habe das Gefühl, ich habe eine Extremistenposition, also im Sinne von, dass halt viele Menschen das irgendwie nicht so sehen und halt sagen, was soll's, und das finde ich halt irgendwie schwierig.
Wollen wir das nächste Prinzip machen?
Genau, ich glaube, das nächste ist gar nicht, da haben wir schon ziemlich viel vorweggenommen.
Also, Assou und S.W.C.
Bug, you fix it, do not continue on, da haben wir jetzt auch schon ein bisschen drüber gesprochen.
oder zumindest mal auf die Konsequenzen, die wir sowas haben könnte, natürlich erstmal eine sinnvolle Sache.
Also ich glaube, wenn wir jetzt sagen, ich habe irgendwie Wissen darüber, dass da ein Problem ist, dann verschließe ich nicht die Augen und verschiebe das auf später oder mache halt irgendwie mein Ticket und dann ist es das Problem von jemand anderem, der das lösen muss oder sowas, sondern sich aktiv um eine Lösung zu bemühen.
Das ist sicherlich ein hilfreiches Prinzip.
Und auch das Zweite, das ist ja für mich eher die Begründung für diesen ersten Abschnitt.
Also was passiert, wenn wir es nicht tun?
Genau, da steht, also if you don't fix your bugs, your new code will be built on a buggy code base and ensure an unstable foundation.
Also wenn ich eben den Bug nicht sofort fixe, dann habe ich eben eine federafte Basis und komme halt dadurch nicht weiter.
Das tut natürlich besonders viel, wenn ich halt wirklich Shipping über Post mache, wie wir es vorhin gesagt hatten, und ich halt gar keine Möglichkeit mehr habe, dann was nachzureichen.
Dann ist der Bug halt für immer da drin.
Ja, das ist für mich eigentlich ausformuliert.
Wenn du halt Qualitätskompromisse machst, kriegst du halt möglicherweise sehr schnell Ärger und zwar nicht Ärger in Bezug auf Qualität, sondern auch in Bezug auf Produktivität.
Und ich habe ja schon gesagt, ich bin halt der Meinung, dass man halt die perfekte Software nicht bauen kann, aber das hier würde ich eben tatsächlich mehr oder minder unterschreiben.
Vielleicht noch, also Kullingpur Potentakel hat gerade noch geschrieben, so ein bisschen als Rückgriff auf das, was wir vorher diskutiert haben.
Bei meiner alten Firma war das so und das führte dazu, dass du irgendwann keine Fehler mehr zugibst in der Hoffnung, dass sie nicht auffallen.
Ganz schlechte Richtung.
Genau.
Und das ist halt auch der Grund, warum ich irgendwie auch bei uns in der Firma rumlaufe und halt sage, das sind irgendwie Dinge, die ich irgendwie auch suboptimal gelöst habe, einfach um irgendwie zu sagen, das machen wir halt irgendwie alle.
Es geht halt darum, dass wir da irgendwie besser werden und dass wir daraus lernen.
Also könnte ich jetzt eigentlich eine Fehler, eine Chance zu lernen.
Das würde ich jetzt vielleicht nicht so unterschreiben.
Ich finde auch dieses nicht move fast and break things schwierig, weil das ist irgendwie das umgekehrte Qualitätsbewusstsein.
Aber nicht, wenn etwas schief geht, dann, ich glaube, das ist der Punkt, man muss sich halt erstmal vergegenwärtigen, dass es sehr sicher nicht die Absicht der Person war, dass es halt schief geht.
Und dann muss irgendwie die Frage sein, warum ist es schief gegangen und man muss es halt irgendwie fixen.
Und das ist so ein bisschen der Punkt.
Genau, ich kann jetzt nochmal die Werbeeinblendung für Airclash Investigations machen, was ich jetzt wieder angefangen habe zu gucken.
Und da ist es eben auch so, dass man halt sagt, okay, der Pilot hat also irgendwie Mist gebaut.
Warum?
Hat ihm irgendjemand gesagt, dass er das so nicht so machen soll?
Ist er ausgebildet worden?
Ist er irgendwie ausreichend erholt gewesen?
Und davon können wir uns, glaube ich, auch eine Scheibe abschneiden.
Es ist bemerkenswert, wie viele kulturelle Aspekte doch in der Softwareentwicklung wir da drinstecken.
Also vielleicht, wenn man da reinrutscht in diese Profession, oftmals gar nicht so bewusst.
Und später stellt man fest, naja, wir machen halt Software mit Menschen, für Menschen.
Also auch wenn da irgendwie viele Maschinen mit dabei sind am Ende des Tages, am Ende der Kette sitzt immer ein Mensch, der Nutzen davon haben muss.
Und diese kulturellen Aspekte entscheiden letztlich über, ja nicht nur produktiv oder nicht produktiv, sondern halt eben im Extremfall über Erfolg oder nicht Erfolg.
Und das geht oftmals verloren.
Also das Unternehmen, von dem da gerade berichtet wurde in dem Kommentar, ich glaube, das kenne ich auch.
Oder zumindest andere, die sich eh nicht verhalten.
Und da kann man was dagegen tun.
Und wenn man zum fünften Mal kaputten Code einreicht, könnte man vielleicht mal reden.
Aber wenn ich so selten Bugs einreiche, das ist sicher auch nicht hilfreich, das direkt mal zu blamen.
Kultur halt.
Exakt, ja.
Und das ist genau das, was ich halt sage.
Also Piloten sind halt im Extremfall dafür zuständig oder daran schuld, in Anführungsstrichen, dass halt Menschen sterben.
Trotzdem stoppen die nicht da, wo sie halt sagen, ja, der ist halt schuld, das war's.
So, jetzt gibt es über das Formular eine Aussage.
Muss ich mal kurz schauen, was da steht.
Nummer drei, also das, was wir gerade diskutieren, klingt für mich auch zu absolutistisch.
Wenn es ein kleiner Schönheitsfehler ist, kann es doch trotzdem sinnvoll sein, eine Story, die gerade implementiert wird, nicht zu unterbrechen, oder?
Naja, ein Schönheitsfehler ist kein Bug.
Und ich, also, ich finde das...
Das ist halt dieses Problem mit dieser Qualitätsschraube.
Und so wie es hier formuliert ist, würde ich es, glaube ich, unterstreichen, insbesondere mit dieser Begründung.
Sonst ist es eben auch deswegen schwierig, weil in einem System gute und schlechte Teile sein werden.
Und wenn man halt sagt, alles muss perfekt sein, dann stellt man das halt in Abrede.
Und wenn man halt sagt, ich habe halt gute und schlechte Teile in einem System, dann muss ich eigentlich sagen, Also dann habe ich nur noch die Wahl, es zu steuern oder hinzunehmen.
Und das ist, glaube ich, für mich irgendwie dieses Problem.
Ich finde den Begriff absolutistisch halt gut.
Also solche Sachen, die halt sagen, du musst halt immer die maximale Qualität liefern.
Ja, cool.
Das heißt, am Ende hast du halt überall perfekten Code.
Also vielleicht haben die das bei Doom wirklich hinbekommen.
Keine Ahnung, ich kenne das System nicht intern, sonst würde mir irgendwie noch Tech oder Metafront einfallen.
wo es ja diese berühmte Bug-Bounty gab, die sich irgendwie mit jedem Bug der Betrag verdoppelt.
Und das ist eben tatsächlich der Versuch, eine perfekte Code-Basis zu bauen.
Also nicht das von Donald Knuth, der hat dieses System gebaut, um damit seine Bücher zu schreiben.
Das ist halt ein System, was so Seitenbeschreibungen umfasst und Font-Seite generieren kann.
Und er hat halt irgendwann gesagt, er fängt halt an und Es gibt halt jedem, der einen Fehler findet, eine Bug-Bounty und die verdoppelt sich halt mit jedem Fehler, der gefunden worden ist.
Und nachdem das ein exponentielles Wachstum ist, muss er sich sehr sicher sein, dass er dicht an Perfekt ist.
Oder dass er sich für den Code interessiert.
Coding Poper Tentakel hat geschrieben, zumal die guten Leute mitunter nicht geübt sind, darin Fehler zu machen, weil sie seltener welche machen.
Das ist interessant, nicht?
Lassen wir mal so stehen.
Das nächste Prinzip wird ganz spannend, weil da führen wir einen neuen Begriff ein und da können wir darüber diskutieren, ob es das eigentlich bei uns auch gibt.
Ja, genau.
Also da steht halt It's incredibly important that your game can always be run by your team.
Also es ist unglaublich wichtig, dass dein Spiel immer von dem Team laufen gelassen werden kann.
Und dann steht da halt Bulletproof your engine by providing defaults upon load failure.
sicher halt dein System oder deine Engine ab, indem du halt Defaults anbietest, wenn halt irgendwas beim Laden schief geht.
Und da sollte man vielleicht eben sagen, dass es halt um diese Engine geht und das ist irgendwie nachvollziehbar.
Das heißt, wenn ich gerade dabei bin, ein Level zu designen, brauche ich halt die Engine, damit ich die halt irgendwie anschauen kann und halt durchspielen kann.
Und daher ist das halt tatsächlich sehr wichtig.
Wobei ich nicht sicher bin, ob wir sowas halt bei uns, diese klare Trennung zwischen Engine und diesen Levels, da bin ich mir halt nicht sicher, ob wir sowas haben.
Und es ist halt in gewisser Weise auch ein Sonderfall, weil eben, wie ja schon gesagt, diese Engine halt etwas Wiederverwendbares ist.
Das heißt, ich kann eben die Engine nutzen von heute Unreal oder eben damals auch von It.
und damit halt selber mein System bauen, dann habe ich das Problem halt nicht.
Also mindestens das zweite Problem habe ich dann halt nicht, von wegen, dass ich ja mein Engine absichern muss, weil das ist halt für mich hoffentlich getan.
Sonst habe ich halt eine andere Art von Problem.
Ich würde das gerne challengen.
Okay.
Also die Aussage, das haben wir so, also ja, wir haben vielleicht keine Game-Engine, die Informationssysteme bauen.
Ich glaube, wir haben Dinge, die zumindest mal den Platz einnehmen, wie eine Game-Engine bei der Produktion von Videospielen.
Nach meinem laienhaften Verständnis aus der Konsumentenperspektive ist eine Engine so ein Ding, was ich nehme, um ein Produkt drumherum zu bauen.
Also das kümmert sich dann halt eben ums Heavy Lifting, zum Beispiel das Rendering von 3D-Szenen, darum, dass es eine Physik gibt in dem Spiel.
Also ich muss mich da nicht darum kümmern, ob Sachen nach unten fallen und sowas.
Das macht alles die Engine für mich und ich kann mich mehr oder minder aufs Level-Design und die spielerischen Aspekte konzentrieren und muss mich natürlich noch um so Sachen wie meine Grafik und sowas kümmern.
Aber den restlichen Teil nimmt die Engine ab.
Das ist mein Verständnis.
Und das hat für mich sehr, sehr viel Analogie zu Dingen, die wir durchaus kennen bei der Softwareentwicklung in Informationssystemen.
Also zum Beispiel haben wir sowas wie Application Programming Frameworks.
Also jetzt in der Java-Welt sowas wie Spring beispielsweise.
Das wäre für mich was, was einen vergleichbaren Status hat mit so einer Engine, wenn ich ein Spiel entwickle.
Also da ist auch das Framework das Ding, was mir hilft, mein Produkt zu entwickeln und was mir ganz, ganz viel Arbeit abnimmt.
Und wo es sich total lohnt, dass ich also immer in der Lage bin, dieses Ding vernünftig auch einzusetzen.
Diese Bulletproof-by-Default-Geschichte, also dafür zu sorgen, dass diese Engine immer irgendwie mit sinnvollen Defaults, das ersetzt sich zum Beispiel eins zu eins auf den Bootstrapping-Prozess.
Also dass die Anwendung entweder klar definiert in einen Fail-Fast-Zustand übergibt und sagt, okay, wir wissen, warum es gescheitert ist und es geht halt nicht in einen fragwürdigen Zustand.
irgendwie in Betrieb oder aber wir haben das Ding so weit vorkonfiguriert, dass es zumindest mal sauber läuft und niemanden aufhalten wird beim Arbeiten.
Also das wäre für mich so eine Analogie zu Engine und ich würde noch einen draufsetzen.
Bei Doom.
War das so?
Oder jetzt bei id Software, der John Carmack hat die Engine geschrieben, saß mit im Raum und hat quasi 24-7 oder vielleicht auch 35-7, wenn man den Legenden glauben darf, nur Engine gemacht.
Brutales Hirn.
Die anderen haben drumherum das genutzt, um das Spiel zu bauen.
Das heißt also, wenn es da ein Problem mit der Engine gab, waren die Wege immerhin noch kurz.
Wenn wir das mal übersetzen in die Realität, in den Organisationen, zumindest mal soweit ich das miterleben durfte, Das sind Engines, dann oftmals sowas wie selbstgebaute Frameworks, um die herum dann irgendwas gebaut wird.
Die haben dann vielleicht sowas wie ein Spring oder so noch im Herzen drin, aber die sind dann dafür da, um andere Ziele zu erreichen, weniger Tedious-Arbeitsschritte zu haben, irgendwie Wiederverwendung zu haben, immer wieder Dinge gleichartig zu lösen und davon kann man sich halt krass abhängig machen.
Und um in der Doom-Sprache zu bleiben, Wenn ich meine eigene Engine dann baue, dann geht das in Richtung Hurt Me Plenty.
Da muss ich auch dafür sorgen, dass ich da keinen großen Schmerz habe, wenn da was nicht funktioniert.
Namentlich, wenn der Entwickler dieser Engine, dieses Frameworks oder dieses was auch immer spannenden Plugins im Build-Prozess, ohne dass niemand leben kann, wenn der halt gerade mal in einem anderen Projekt ist oder nicht verfügbar ist.
Also das wäre für mich eine Analogie zum Thema Engine.
Wie siehst du das?
Mir fehlt halt...
Also ja, sowas mag es halt geben.
Mir fehlt halt eine Warnung und wir haben später ja noch ein Prinzip, was sogar das Gegenteil eigentlich sagt.
Sowas will man nicht.
Du willst keine Engine bauen.
Absolut.
Und aus den Gründen, die du halt irgendwie auch genannt hast.
Und ja, es gibt dann irgendwie Menschen, die sowas irgendwie auf die Reihe bekommen.
Also der John Carmack hast du halt genannt, bei Spring ist es halt im Wesentlichen, glaube ich, der Jürgen Höller, der irgendwie dafür sorgt, dass eben das Core-Framework so gut funktioniert.
hat oder funktioniert, wie es halt irgendwie funktioniert.
Und sowas hast du firmenintern nicht und es macht auch keinen Sinn.
Und das ist dort, glaube ich, irgendwie das Problem.
Der Okay is not okay bei YouTube hat er mir gesagt, dass man den ersten Satz, also dieses, es ist halt unwahrscheinlich wichtig, dass das System halt immer ausführbar ist.
dass man das halt so verstehen kann, dass die Software niemals broken da liegen darf.
Das ist, glaube ich, tatsächlich etwas, was halt sehr wichtig und sinnvoll ist und was wir durch CI und CD Pipelines mittlerweile absichern.
Und ich habe tatsächlich, das war auch so um die Jahrtausendwende, da war ich halt irgendwie technische Konsulten.
Ich habe mal einen Tag damit verbracht, dass ich halt, also ich war für einen Tag eingekauft, ich habe den Tag damit verbracht, dass ich neben jemandem gesessen habe.
der versucht hat, die Anwendung so zum Kompetieren zu bringen, dass wir uns anschließend um das technische Problem lösen konnten.
Und ich glaube, das haben wir nicht hinbekommen oder er hat es nicht hinbekommen.
Und das ist halt der Zustand, den wir damals hatten.
Und ich glaube, da sind wir, also ich würde halt erwarten, dass das Typische ist, dass ich den letzten Bild bekomme und der letzte Bild ist eben von, weiß ich nicht, von der letzten Codeänderung oder von gestern oder so, aber auf keinen Fall sowas, wie ich da halt erlebt habe.
Das wäre halt wirklich schlimm.
Ja, der Romero hatte das auch noch so genannt, also wenn du halt ein großes Team hast, wenn du 100 Leute hast, die ein Spiel entwickeln und die Engine läuft halt nicht sauber, dann bezahlst du 100 Leute fürs Rumsetzen.
Also das, was du im Kleinen erlebt hast, das tut dir halt eben, und nicht nur im Game Development, sondern halt eben auch in Organisationen weh.
Ich hab irgendwie das Gefühl, das kommt trotzdem ganz oft vor und es ist aus irgendeinem Grund...
akzeptiert, dass man solche Sachen auch hinnehmen muss.
Das sollte nicht so sein.
Also ganz klar, wenn man solche Abhängigkeiten hat, dann muss man das auflösen.
Ansonsten kostet es unglaublich Geld und Zeit.
Genau, und das würde das bedeuten nicht.
Heutzutage kaufst du, also ich kann mir nicht vorstellen, dass jemand als Spielestudio anfängt, eine eigene Engine zu bauen, weil das einfach ökonomisch wenig Sinn macht, weil die Lizenzkosten insbesondere für kleine Unternehmen sehr gering sind.
Wie soll ich sagen?
Das ist der Grund, weswegen wir versuchen, Infrastruktur zu benutzen, statt sie selber zu entwickeln.
CoolingPropotentakel hat geschrieben, Nachfrage ist mit der Engine-Analogie eben Runtime oder Buildtime gemeint gewesen, weil hier ist ziemlich sicher Bulletproof Runtime gemeint.
Diese klassische Default-Textur, zum Beispiel, die mega hässlich aussieht, aber die Runtime kann weiterlaufen.
Das ist...
Es ist die Runtime gemeint, nicht?
Also, by the proof your engine by providing defaults upon load failure, bedeutet ja, dass ich eben dazu in der Lage bin, wenn das System halt hochfährt, dass es dann halt auf jeden Fall läuft.
Und by the way, also das war auch noch etwas, wo du, glaube ich, Tom, etwas gesagt hast, wo ich mir nicht sicher bin.
Also ich weiß nicht, ob du das wirklich gesagt hast, beziehungsweise wenn du das gesagt hast, dann bin ich halt einer anderen Meinung.
Ich glaube, der zweite Punkt ist halt auch deswegen schwierig, weil Wenn ich halt Defaults habe und die sind nicht transparent und ich glaube, das System arbeitet halt mit dem Einstellung und dem Zeug, was ich halt irgendwie eingestellt habe und es läuft dann los und sagt, nee, mache ich halt nicht, benutze halt die Defaults, dann sehe ich nicht unbedingt, dass es wirklich besser ist, diese Defaults zu haben, weil das kann die Fehlersuche verschlimmern.
Also wenn das Ding halt irgendwie loslegt und sagt, hey, ich kann deine Konfigurationsdatei, die du angegeben hast, nicht finden, ich beende mich jetzt mal, ich bin mir nicht sicher, ob ich das nicht vielleicht wirklich als Verhalten haben möchte, dass es mir vielleicht lieber, als wenn das Ding losläuft und sagt, hey, ich habe da übrigens Defaults geladen, ich sage es dir jetzt aber nicht, sondern das darfst du selber herausfinden, dass da irgendwelche Defaults sind und nicht die Einstellungen, von denen du dachtest, die da sind.
Also das meinte ich ja vorhin auch mit Fail Early.
Also das sollte eine ganz bewusst Entscheidung sein.
Will ich mit Defaults arbeiten, damit ich irgendwas tun kann?
Oder will ich ganz bewusst sagen, es macht überhaupt keinen Sinn, dass dieses Ding überhaupt zur Laufzeit verfügbar ist.
Wenn bestimmte Sachen nicht da sind, dann möchte ich lieber fail early, aber dann auch mit einer ganz klaren Fehlermeldung, an der ich festmachen kann, was ist hier eigentlich mein Konfigurationsproblem?
Und hoffentlich kann dann auch jemand was damit anfangen und ich brauche halt eben nicht diese eine Person, die dieses Spezialwissen hat.
Das ist ja dann so ein anderes Ding, aber wir machen da zu viel auf, fürchte ich, sonst kommen wir gar nicht durch.
Genau.
Sorry, dann hattest du das tatsächlich so gesagt und dann habe ich das halt nur nicht verstanden.
Prinzip 5.
Keep your code absolutely simple.
Also halte deinen Code absolut einfach.
Keep looking at your functions and figure out how you can simplify them further.
Also guck halt an deine Funktion und schau halt nach, wie du die weiter vereinfachen kannst.
Das finde ich schwierig, weil das halt möglicherweise wirklich in so ein Todrefaktoren kommt.
Also wie schon im Prinzip das, was ich sagte, also ich werde halt gute und schlechte Teile im Code haben, ich kann nicht alles perfekt machen, das glaube ich nicht, oder es wird immer Teile geben, die besser und schlechter sind, komparativ.
Und wenn ich da irgendwie rangehe und sage, ich möchte halt die Sachen immer noch besser, noch besser, noch besser machen, irgendwann muss ich halt Schluss machen.
Und gerade bei Refactoring ist es halt so, dass man Sachen halt Also subjektiv, was besser ist an einigen Stellen, glaube ich, besser zu verstehen ist.
Ja, also ich tue mir mit dem Prinzip auch ein bisschen schwer.
Also was da steht, klingt natürlich super.
Also wer will dem denn widersprechen?
Also natürlich, okay, gut.
Aber sowas wie, ich möchte simplen Code haben, ist ja prinzipiell was Gutes.
Das ist das Problem, was ich sehe.
Also wenn du dir anguckst, was sind denn so Maßstäbe für gute Prinzipien, da gehört halt mit dazu, dass halt das Gegenteil nicht automatisch irgendwie Unsinn sein sollte.
Deswegen glaube ich erstmal, das ist kein so wirklich sinnvolles Prinzip.
Der Punkt, den du hast, warum du dem widersprichst, ist ja, okay, wann ist es denn gut genug?
Oder wie kann ich denn da das greifbar machen, wie weit ich optimieren möchte?
Ansonsten bin ich da vielleicht irgendwie, habe ich den schönsten Code aller Zeiten, aber meine Ziele halt eben nicht erreicht.
Das ist ja eher das größere Problem, was dahinter steckt.
Exakt.
Das ist halt so ein bisschen der Punkt.
Ja, also ich halte es für kein glücklich formuliertes Prinzip, auch wenn ich die Motivation dahinter verstehen kann und die wahrscheinlich eher mehrheitsfähig sein könnte.
Ja, also ich bin mittlerweile tatsächlich der Meinung, dass, und also wie soll ich sagen, das wäre vielleicht irgendwie ein Panel in sich wert, diese sehr starke Orientierung auf Qualität, die ja Software-Crossmanship eingeführt hat, finde ich echt schwierig, weil, und das ist hier ja manifestiert, also das ist halt die Aussage, du willst halt wirklich die aller, aller, aller beste Qualität erreichen.
Ich kenne kein System, was das halt irgendwie erreicht.
Das wird halt nicht passieren.
Und okay, ist not okay, schreibt halt gerade, keep your unit test code, absolutely simple.
Ja, also das ist halt dasselbe Thema, nicht?
Also ich glaube, ich wäre absolut überrascht.
Wenn ein Entwickler ehrlich ist, wenn er irgendwie nicht sagen kann, also in dem System an dieser Stelle irgendwo habe ich halt irgendwie Sachen, die sind halt suboptimal und mit denen lebe ich jetzt erstmal.
Also das kann ich mir nicht vorstellen.
Weil sowas würde dann irgendwie zu unwirtschaftlichen Lösungen führen.
Gut, dann haben wir das nächste.
Great Tools help make great games.
Also gute Werkzeuge sorgen dafür, dass wir halt auch gute Spiele schreiben können.
Spend as much time on tools as possible.
Also verwende so viel Zeit wie möglich auf deine Tools.
Das hören manche bestimmt total gerne.
Romero hat gesagt, ich soll ganz viel Zeit ins Tooling versenken.
Dann machen wir das jetzt mal.
Der Mann muss ja recht haben.
Also ich würde behaupten, dieses Prinzip ist tatsächlich, ich kann es für Spieleentwicklung nicht endgültig bewerten.
Softwareentwicklung im Allgemeinen halte ich das für falsch und gefährlich falsch.
Also das Gegenteil ist richtig.
Was ich eigentlich machen möchte, ist, ich möchte, also der erste Teil stimmt natürlich nicht.
Gute Werkzeuge sorgen halt dafür, dass ich gute Spiele machen kann.
Wobei, okay ist not okay, hat auch gerade gesagt, nicht, a fool with a tool is just a fool.
Also jemand, der hat nichts kann, ist auch, wenn er Werkzeuge hat, irgendwie immer noch jemand, der hat nichts kann.
Aber da steht ja auch hilft, also das bedeutet nicht, sorgt sofort dafür, dass es halt gute Spiele gibt.
Und in gewisser Weise ist das nachvollziehbar, nicht?
Also wenn ich halt jetzt eine gute Entwicklungsumgebung oder so nutze, das ist mir nachvollziehbar.
Aber der zweite Satz ist halt absurd.
Meiner Ansicht nach ist der richtige Ansatz, die Sachen halt zu kaufen.
Und das ist ja lustigerweise mit id Software genau das.
Also der Vorteil von id Software und den Technologien, die sie gehabt haben, ist, dass man halt plötzlich sich hinstellen konnte und sagen konnte, okay, da gibt es also Doom.
Doom ist dann technisch Maßstäbe gesetzt.
Ich kann diese Technologie einfach benutzen.
Ich kann sie lizenzieren und kann selber ein Spiel machen, was halt technisch genauso gut ist, ohne mich anzustrengen.
Das heißt, ich habe jetzt ein Problem in Inhalt.
Also ich muss irgendwas haben, weil mir das Level-Design super ist.
ist eigentlich ja das, was sie eben pioniert haben.
Und das bedeutet, die Zeit, die ich auf Tod verwende, ist halt, ich wähle eins aus.
Das ist wenig Zeit.
Ich glaube, es wird ein Schuh draus, wenn wir den Adressaten von diesem Prinzip wechseln.
Wenn das nicht die Entwickler sind, sondern vielleicht diejenigen, die dafür verantwortlich sind, dass ein Entwicklungsteam handlungsfähig ist.
Macht nämlich total Sinn, dass wir sagen, hey, die Entwickler sollen bitte nicht...
die Tools schreiben oder da, also da möchte ich auch keine Zeit rein versenken.
Es muss gegeben sein, dass wir vernünftige Tools haben.
Aber auch das ist so eine Sache, die man immer wieder erlebt, also dass wir halt eben dann doch viel zu viel Zeit damit verbringen, dafür zu sorgen, dass wir vernünftig arbeiten können an der IDE rumdoktern, dafür zu sorgen, dass unsere VMs genug RAM haben oder dass wir halt überhaupt irgendwie eine Entwicklungsumgebung haben, die den Namen verdient.
Und deswegen sage ich Adressat wechseln.
Also ich glaube, es ist sinnvoll, dass man sich viel Gedanken über ein saumäßig gutes Tooling macht, weil das hält einen im Game, also im Spiel, um was entwickeln zu können.
Aber ich möchte natürlich nicht meine Entwicklerzeit darauf verschwenden, irgendwie zu fixen, was irgendwie an Setup nicht da ist.
Also Leuten zu erklären, dass sie den Virenscanner so konfigurieren, dass der mir halt nicht meinen Bildprozess langsam macht.
Also solche Sachen sind dann die Dinge, die uns beim Entwickeln tierisch auf die Füße fallen.
So kann man das lesen und ich glaube, so macht es auch Sinn.
Blankosheim hat gesagt, aber das widerspricht, also auf Twitch hat gesagt, das widerspricht ja irgendwie dem Punkt, dass das Einbinden bereits bestehender Frameworks notwendig ist.
Das war die Aussage zuvor, um Zeit zu sparen.
Ich weiß nicht genau, wo der Widerspruch ist, aber ja.
die sollte man halt irgendwie einsetzen und nutzen.
Und also das haben die ja auch gemacht.
Also die haben halt einen C-Compiler benutzt und haben halt den natürlich dann irgendwie nicht selber eingeschrieben.
Also Klammer auf, wobei ich glaube, das stimmt nicht ganz, weil sie haben meiner Ansicht nach einen Cross-Compiler von dem GNU-C für DOS selber gebaut, also den Port gebaut, aber Also sie haben halt dann die Sachen eingebunden und sich halt darum gekümmert und das ist, glaube ich, auch richtig oder der richtige Ansatz.
Ich weiß nicht genau, wo der Widerspruch halt ist.
Gut, wie ist das Prinzip oder wollen wir dazu noch was sagen?
Ne, das nächste ist auch recht spannend, also da steckt ja noch ganz viel dahinter.
Genau, da steht Use a development system that is superior to your target, also benutze ein Entwicklungssystem, das dein Zielsystem überlegen ist.
Ja, also aus der Geschichte, so diese Überlieferung, die haben halt für DOS-PCs gearbeitet, haben am Anfang auf DOS-PCs programmiert und debuggt und dann halt ...
damit sind sie nicht produktiv genug.
Auch wenn die Tools nett sind, aber sie können das sich irgendwie viel besser vorstellen und haben dann halt die Plattform gewechselt, haben also ihr Level-Editing und alles drum und dran gebaut, um das halt eben auf deutlich leistungsfähiger Hardware und Software zu betreiben.
Das waren dann Next-Maschinen.
Ich glaube, da schlägt dein Herz höher.
Du bist da irgendwie emotional in der Welt verhaftet.
Sag doch was dazu, warum Next?
Sag du doch was dazu, ja genau.
Also tatsächlich ist es halt so, dass die Next-Maschinen damals halt maßgeblich waren und gerade auch in Bezug auf Entwicklung.
Also sie haben halt eine objektorientierte Entwicklungsumgebung mitgebracht mit dem Interface-Builder.
Sie haben Objective-C gehabt, womit man halt eben objektorientiert mit C entwickeln kann und so weiter und so weiter.
Ich glaube, der wesentliche Punkt...
Es gibt dieses Mastersoft Doom, ich habe nochmal nachgeguckt, da stand es nicht drin, aber irgendwo habe ich das Buch über eben, wie damals diese, ich verlinke das auch nochmal, wie damals diese Systeme entwickelt worden sind.
Irgendwo habe ich einmal aufgeschnappt, dass eigentlich der wesentliche Punkt war, dass sie einen Editor hatten und dann halt, also einen einigermaßen vernünftigen Editor, ich glaube sie haben den eingebauten Editor benutzt, der heute ja bei macOS im Prinzip auch noch so unverändert da ist.
Und dann halt ein Kommandozeilen-C-Compiler.
Das heißt, sie haben halt diese ganzen fancy Entwicklungswerkzeuge gerade nicht benutzt, außer eben, um sowas wie den Level-Editor zu bauen oder so, die eben auf Next Step gelaufen sind.
Und ich fand das halt eigentlich erstaunlich, aber am Ende ist eben der Punkt, dass wahrscheinlich zu dem damaligen Zeitpunkt Next mit einer vernünftigen Hardware-Ausstattung und viel RAM und vielleicht auch einem besseren Prozessor, das sind halt immerhin...
Motorola-Prozessoren, die sind wahrscheinlich besser gewesen damals als das, was man irgendwie auf DOS hatte.
Und ein Betriebssystem, wo eben nicht irgendeine Anwendung dafür sorgen kann, dass der ganze Computer irgendwie sich verabschiedet, dass das halt insgesamt zu einer besseren Produktivität geführt hat.
Das ist aber, wie soll ich sagen, im Vergleich zu dem, womit wir uns heute rumschlagen, unspektakulär.
Also ich erwarte von jedem Gegenbetriebssystem, Windows, macOS, Linux und was auch immer, dass es eben nicht einfach so mal kurz abstürzt, weil man halt irgendeinen grönen Fehler gemacht hat mit dem Bufferflow oder was auch immer, sondern nicht, dass das Betriebssystem das halt irgendwie abfängt.
Und ich würde halt auch erwarten, dass halt heute sowas wie ein Editor, ein vernünftiger Compiler oder so auf all diese Plattformen halt üblich ist.
Und deswegen ist es, glaube ich, sie hätten wahrscheinlich mit Sun-Maschinen oder irgendwelchen anderen Unix-Maschinen Ähnliches erreicht.
Die Nix-Maschinen waren nur Nur hübscher wäre jetzt mein Gefühl.
Sie waren damit auf jeden Fall produktiver und von daher passt das schon.
Dann gibt es noch diese Kuriosität, dass Romero davon berichtet, dass sie irgendwann mal einen Deal gemacht hatten mit Cray.
Der ist dann aber irgendwann später nicht zustande gekommen.
und sich zum halben Preis tatsächlich so eine Cray 6400 zulegen wollten.
Es ist mir so ein bisschen unklar, was man jetzt genau damit hätte machen können.
Also was jetzt wirklich das Ziel gewesen ist.
Ich kann mir so Sachen vorstellen wie irgendwie ganz komplexe numerische Lösungen für irgendwelche Lichtberechnungsgeschichten, die man dann später verwenden kann.
Man weiß es nicht.
Keine Ahnung.
Auf jeden Fall hatten sie da...
diese Idee mit, man braucht eine richtig gute Entwicklungsumgebung mit ganz viel Dampf dahinter bis zum Extrem treiben wollen und wollten da halt wirklich so eine Cray-Maschine für damals halt unglaublich leistungsstark hinstellen.
Aber ja, da fehlt mir die Fantasie, wofür man das jetzt konkret hätte einsetzen können.
Also ich habe es gerade nachgeguckt.
Das ist halt ein Multiprozessor-System mit Spark-Prozessoren.
Du kannst wahrscheinlich damit wahnsinnig schnell kompatieren.
Das ist ja nachvollziehbar.
Vielleicht ist es nur die Beschleunigung vom Kompilierprozess.
Genau.
So, okay is not okay, sagt, I disagree, auf meiner Bugsession mit 128 Kilobyte läuft es, Gigabyte läuft es, aber beim Kunden nicht.
Ja, genau, also das ist sozusagen eine Komponente des Problems.
Beziehungsweise, das kann man eigentlich da dran gut illustrieren, das Entwicklungssystem ist halt irgendeine Next mit 4 Megabyte RAM und das, wo drauf es laufen soll, ist halt ein 64 Kilobyte DOS-PC.
zeigt eben, dass das Entwicklungssystem was anderes ist als das, worauf es nachher läuft.
Ich weiß nicht, worauf Marco sich hier bezieht.
Marco Heimesdorf hat geschrieben, anderer Romero.
Aber keine Ahnung.
Da fehlt mir jetzt Kontext.
Ja, fehlt mir auch der Kontext.
Marco, du bist im falschen Chat.
Ja, oder da ist irgendwas bei LinkedIn, was wir heute nicht gesehen haben.
So, dann kommt das achte Prinzip.
Das ist ...
Write your code for this game, only not for a future game.
You're going to be writing a new code later because you'll be smarter.
Und das ist halt die, also ich bedeutet halt, dass ich halt Code nur für das Spiel, was ich jetzt halt schreiben sollte und nicht für irgendetwas, was ich mir halt irgendwann ausgedacht habe.
Das ist halt für mich nachvollziehbar, nicht?
Und deutlich sinnvoll.
Ich sollte halt irgendwie nicht versuchen, Dinge zu antizipieren, die vielleicht mal kommen.
sondern ich sollte halt Sachen für das jetzige Ding halt schreiben.
Also das ist doch mal so ein wirklich universell sinnvolles Prinzip, was wir da rausziehen können.
Das hilft, glaube ich.
Steckt sowas wie Jagney mit dabei.
Also wenn ich irgendwie jetzt der Meinung bin, ich mache irgendwas ganz Tolles, was ich später brauchen kann, brauche ich es vielleicht für das nächste Spiel doch nicht.
Vor allem, und der Punkt ist halt ganz wichtig, später bin ich halt einfach schlauer.
Also jetzt irgendwas...
was ich später vielleicht deutlich informierter machen kann, ist oftmals keine gute Idee.
Also lieber so ein Lernfenster nutzen und später dann richtig umsetzen, als jetzt so Sachen einzubauen, die man mal brauchen könnte.
Das ist also weit über die Spieleentwicklung hinaus, glaube ich, ein sinnvolles Prinzip.
Genau.
Wir sind jetzt schon ein bisschen über die Zeit hinweg.
Ich weiß nicht genau, wie wir weiter vorgehen wollen.
Also eine Möglichkeit wäre, dass wir jetzt die anderen Konzepte tatsächlich irgendwie versuchen.
nochmal sehr schnell durchzugehen?
Also wir hätten jetzt noch drei Stück.
Ich glaube, wir können über die relativ schnell weghoppen.
Das letzte ist vielleicht noch was, wo man zwei Sätze dazu sagen könnte, tiefer.
Und dann sind wir vielleicht fünf Minuten drüber.
Dann würden wir jetzt in einer Minute schaffen.
Aber ja, wir können es mal ausprobieren.
Also das neunte ist, Encaptured Functionality, Turned Design Consistency.
Das minimizes Mistakes and saves Design Time.
Also Kapsel halt Funktionalität ein, um Designkonsistenz zu erreichen und das verringert Fehler und führt zu weniger Design-Time.
Ich muss gestehen, ich habe es nicht verstanden.
Also Einkapseln ist halt ein Konzept aus modularer Entwicklung, das ist irgendwie klar.
Und eigentlich ist das halt etwas, was dazu führt, dass ich halt Dinge unabhängig voneinander weiterentwickeln kann im Wesentlichen.
Nämlich eben sage, ich weiß nicht, was genau da passiert, das ist eingekapselt.
Ich sehe nur die äußere Schnittstelle.
Und das, was intern passiert, sehe ich eben nicht.
Und das ist ja aber für Design-Konsistenz genutzt und ich habe es ehrlich gesagt nicht verstanden, glaube ich.
Ja, ich glaube, das ist nur so eine Wording-Geschichte.
Ich denke, er meint genau das Gleiche.
Also er hat das auch in so ein Beispiel gebracht mit irgendwelchen Fackeln bei Quake.
Also die hätten jetzt die Möglichkeit gehabt, sowas wie...
die Geräusche, den Schattenwurf und alles drum und dran als separate Entitäten zu modellieren und zu implementieren, haben sich aber dafür entschieden, dass es halt eine Fackelentität gibt.
Und wenn die sichtbar ist, dann sorgt die dafür, dass halt irgendwie alles automatisch da ist.
Also du hast halt diesen Sound, du hast diese Lichteffekte und, und, und.
Das heißt, es ist da halt eben konsistent.
Du kannst dieses Ding als eine Einheit rumbewegen irgendwo anders hin und musst nicht daran denken, dass jetzt der Sound auch noch kommen muss und so weiter.
Also das ist mit Encapsulation hier, glaube ich, gemeint.
Design Consistency.
Das Wording ist da vielleicht ein bisschen abweichend von dem, was wir gewöhnt sind.
Aber ich denke, das ist so ein fachlicher Schnitt, nicht?
Also dass du halt sagst, es gibt halt die Fackel.
Das heißt also, wir sagen halt, wir haben irgendwie Dinge, die halt im Raum sind und das ist halt das, woran wir uns halten.
Oder ist halt die Art, wie wir unser System aufteilen.
Du hast ein kursives, fachliches Modul und das Ding ist für dich spannend.
Du musst gar nicht wissen, was da innen drin ist.
Das Ding funktioniert für dich aus mit einer sehr einfachen Schnittstelle.
Ja, also Ja, nachvollziehbar eigentlich Basis.
So, dann kommt dieses Try to code transparently.
Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice.
Do not treat game programming like each code as a black box.
The project could go off rails and cost delays.
Also, das hat letztendlich bedeutet, sei transparent.
Erzähl jedem, was du halt gerade versuchst und was halt du gerade machst.
Und ich behaupte, dass das Ich sehe nicht, wie man damit große Systeme skalierbar entwickeln kann, weil wenn 100 Leute versuchen zu verstehen, was 100 Leute entwickeln, also nicht, ich bin ein Teammitglied, auf mich in einem 100-Leute-Team, es laufen also 99 Leute rum, die mir halt exakt erzählen, wie sie ihre Probleme lösen, das soll ich alles verstehen und Feedback geben?
Nee, funktioniert nicht.
Also funktioniert halt bei drei, funktioniert bei vier, aber sicherlich nicht bei 100.
Genau, also das können wir nicht so übertragen auf die Informationssysteme, wie wir sie kennen.
Das hat für IT funktioniert, die waren halt zu viert.
Und das hat auch Romero gesagt.
Also er dachte, large teams, no chance, you definitely have to plan.
Und dazu gehört halt eben auch so ein bisschen die Informationen richtig zu streuen und damit reinzukriegen.
Das ist, glaube ich, keine Sache, die man einfach so universell übernehmen kann.
Ja, und da muss ich halt gestehen, dass ich insgesamt damit halt ein Problem habe, weil ich würde halt behaupten, das Problem ist große Teams.
eben skalieren und nicht zu zweit oder alleine irgendwas bauen.
Und das ist halt auch das, was uns meistens passiert.
Aber es gibt halt auch sowas wie Pair Programming, Ensemble Programming, wo halt ein Team sehr eng miteinander arbeitet und interagiert und halt eben sehr gut funktioniert, wo die Leute halt auch ein intimes Verständnis davon haben, was die anderen halt eben tun, aber auch, dass es dann immer auf einen kleinen Kontext begrenzt.
Also würde vielleicht auch eher nur einen Teil davon abdecken können.
Genau, ich komme nicht umhin.
Also, da ist halt ein Kommentar, der mich so ein bisschen provoziert, so provoziert im Sinne von, ich würde gerne was dazu sagen.
Das ist halt das von Afrinischen oder sowas.
Afrinischen, egal.
Ich glaube, er sagt, ich habe bei dem ganzen Thema das Gefühl, man kann schlecht von damals zu heute abstrahieren, weil es systemisch komplett andere Abbedingungen herrschen.
Zehn-Personen-Team versus Organisation.
Und da kommt dann die nächste Frage, ist halt die Frage, inwiefern das alles noch eine Rolle spielt in Zeiten von unbegrenzter Hardware und Vibe-Coding.
Also ich würde dem entgegenhalten, dass ich, ich habe tatsächlich das gegenteilige Gefühl, ich bin halt der Meinung, dass die Basisdinge, Modularisierung, wie wir halt Sachen skalieren, wie wir halt in größeren Teams arbeiten, das, was wir jetzt auch alles diskutieren, sozio-technische Architekturen, auch sowas wie Conway's Law und all diese ganzen Geschichten.
Ich würde sagen, alle diese Dinge sind älter als ich und ich bin 72 geboren.
Und eines von den Problemen, was wir gerade haben, ist, dass wir halt meinen, dass das ja alles nicht mehr gültig ist.
Und das ist meiner Ansicht nach tatsächlich falsch schon auch gefährlich.
Ich glaube, das Problem ist hier eher, dass die Welt, in der der John Romero gelebt hat, eine andere ist, weil sie ein kleines Team hatten und weil sie ein Spiel programmiert haben.
Aber die Basisideen, wie wir Systeme skalierbar groß bauen und wie wir Systeme modularisieren und so weiter, sind, behaupte ich, älter als ich.
Ja, ich glaube, das kann man sicherlich so sagen.
Die Prinzipien sind, glaube ich, nicht so gut formuliert, dass man sie gut übertragen kann.
Die grundsätzlichen Dinge, die sie adressieren, und die muss man dann halt ein bisschen suchen, die sind sicherlich unbequem.
universell sinnvoll sich zumindest mal zu betrachten.
Wir hatten ja zu Eingang gesagt, also Quäntchen Salz ist notwendig, plus Randbedingungen prüfen und schauen, was davon trifft auf mich, auf mein Team, auf meine Situation zu.
Und dann kriegen wir schon raus, also passt er oder passt halt eher nicht.
Auf gar keinen Fall sollte man jetzt hergehen und sagen, Romero hat ja recht gehabt, der Erfolg gab ihm recht.
Wir machen das jetzt genauso und erwarten, dass man damit den gleichen Erfolg hat.
Ich glaube, das ist eher kein guter Ansatz.
Ja, ich bin insgesamt ehrlich, also um vollständig ehrlich zu sein, ich bin insgesamt nicht so positiv angetan von der Sache.
Also da kommt jetzt irgendwie noch die Aussage, da habe ich mich vielleicht falsch ausgedrückt, da stimme ich dir zu.
Soziokulturell sind das andere Rahmenbedingungen.
Das stimmt.
Gut, wir sollten vielleicht noch das letzte Prinzip hier irgendwie diskutieren, weil das ist halt das Nächste, wo...
wo ich halt, glaube ich, entschieden widersprechen würde.
Also der Schilder, Programming is a creative art form based in logic.
Also Programmierung ist eine kreative Kunstform, die halt in Logik basiert.
Und also dem würde ich halt widersprechen.
Ohne Zweifel sind für mich Computerspiele eine Kunstform, also multimediale Kunst.
Das ist für mich offensichtlich.
Aber Programmierung ist halt keine Kunst in dem Bereich, in dem wir es halt betreiben.
Da geht es darum, effizient, effektiv irgendein wirtschaftliches Problem zu lösen.
Und das ist halt was anderes.
Und dann steht halt da zweiter Satz, every program is different and will code differently.
It's the output that matters.
Da bin ich mir auch nicht so sicher, weil da irgendwie dieses Problem dann existiert mit, naja, nicht, die Person hat es geschrieben, die Person versteht es, nur die Person kann es ändern.
Oder das versteckt sich so ein bisschen dahinter.
Und da gibt es ja irgendwie Mechanismen wie...
Mob-Programming oder Aux-Hombo-Programming, wo also einer vor der Tastatur sitzt und eine ganze Gruppe sagt, was irgendwie geschrieben werden soll, beziehungsweise Pair-Programming, wo zwei Leute eine gemeinsame Tastatur haben und die lösen ja solche Probleme bis zu einem gewissen Maße.
Ich bin ganz froh, dass wir das Prinzip ans Ende gepackt haben, sonst hätten wir am Anfang schon völlig derailed.
Da kann man sich jetzt Ewigkeiten drüber streiten, wie das gemeint ist.
Man weiß es nicht genau, wie er es jetzt sagen wollte.
Da gibt es verschiedene Sichtweisen drauf.
So weit will ich mal noch gehen.
Und ja, Programmierung ist halt eben vielleicht nicht eine Kunst, sondern eine Ingenieursdisziplin.
Ich fürchte, wenn man diese Aussage macht, macht man so eine ganz, ganz große Box auf, die wir vielleicht für heute erstmal noch zulassen.
Aber zumindest mal so als Outro zum drüber nachdenken.
Food for Sond ist doch nochmal ein ganz nettes Ding.
Genau, und also letzter Kommentar sozusagen oder von den Zuschauern, da ist halt Mr.
Reasible, der hat gesagt, ist in meiner Papa definitiv nicht so.
Traurigerweise ist es so, dass dem Kunden am wichtigsten ist, dass erstmal etwas läuft und das am besten schnell umgesetzt, ob das jetzt effizient oder wie hübsch der Code ist, spielt leider absolut keine Rolle mehr.
Also ich finde es nachvollziehbar.
Es interessiert mich nicht bei der Software, die ich benutze, wie sie geschrieben ist und ob der Code hübsch ist.
sondern ob ich eine Funktionalität bekomme.
Und ich kann das deswegen nachvollziehen.
Das Problem ist halt, dass ich dann in Schwierigkeiten bei einer nachhaltigen Entwicklung komme.
Und diese Schwierigkeiten in einer nachhaltigen Entwicklung sind für Kunden tatsächlich auch transparent.
Das wiederum führt dazu, dass eben Kunden und Manager, ich glaube, da kann ich auch für dich sprechen, Menschen sind, die uns beauftragen mit dem Auftrag.
Gib uns mal Ideen, wie wir dieses System besser bauen, damit es eben wartbarer wird.
besser wird und an der Stelle sind sie halt Verbündete für Code-Qualität.
Ja, aber es ist halt oftmals nicht so wirklich sichtbar.
Also das ist ja genau das Problem, in dem wir uns bewegen.
Es wäre sehr sinnvoll, wenn wir da halt eben diese nachhaltige Perspektive von Anfang an drin hätten.
Das haben wir oftmals nicht und das ist halt das, was uns dann auch im Spiel hält, tatsächlich.
Ja, ich bin halt nicht sicher.
Also Mr.
Reza beschreibt halt gerade, aber das wirkt sich ja auf die Wartbarkeit aus.
Genau.
Und es sind Punkte denkbar, das, was ich da halt immer aus dem Rucksack ziehe, ist halt diese Geschichte mit, wenn wir zum Weihnachtsgeschäft ein System haben wollen für unser Startup und halt zeigen wollen, dass wir halt erfolgreich sind, dann ist es super, wenn ich halt am 1.1.
ein super wartbares System habe, dann können wir halt den Laden dicht machen.
Also es gibt bestimmte Situationen, wo halt die Nachhaltigkeit keine Rolle spielt.
Problem ist halt, dass halt zu häufig darauf nicht geachtet wird.
Und das muss eine bewusste Entscheidung sein, man muss sich da halt eben...
dem Trade-off hingeben und den entsprechend auch entscheiden können.
Okay, ich glaube, das ist irgendwie genug Stoff, um dann eine eigene Episode drüber zu machen.
Auch mit ganz viel Emotion und allem drum und dran.
Aber jetzt sind wir wirklich arg drüber.
Genau.
Ich glaube, das ist die längste Episode, die wir bisher gemacht haben.
Also zumindest mit der größten Überschreitung.
Vielen Dank, Tom, dass du das trotzdem durchgehalten hast.
Sehr gerne.
Vielen Dank für die Diskussion und für die Kommentare im Chat.
Und dann sehen wir uns möglicherweise wieder.
Ich muss mal kurz schauen.
Also da gibt es halt verschiedene Konferenzen, auf denen wir sind.
Das sehen wir gleich im Abspann.
Und die nächste geplante Episode ist am 29., also in 14 Tagen, zum Thema KI-Coding-Produktivität mit Ingo Eichhorst.
Dann würde ich sagen, bis dahin und vielen Dank.
Danke, ciao.
Hier ein Hinweis in eigener Sache.
Softwarearchitektur im Stream ist live vor Ort.
Mehr Infos dazu und einen speziellen Rabattcode für unsere Community findest du auf unserer Website.
Sei dabei, stell Fragen und komm auch gerne auf uns zu.