Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
So, herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.
Heute über John Romeros Prinzipien mit Tom.
Tom, möchtest du dich erst mal vorstellen und zwei Worte über dich sagen?
Ja, sehr gerne.
Ich weiß nicht, ob ich es in zwei Worten schaffe, aber ich versuche es kurz zu halten.
Tom Asel, 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 Software-Architektur.
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 ISAKP, in der DDD-Community, in der Como-Community.
Und ja, so ein Schwerpunkt dabei ist die kollaborative Architekturarbeit.
Genau, und Aufhänger war, dass wir uns auf den DevDays gesehen haben.
Und da hatte der John Romero diesen Vortrag gehalten und den gab es vorher schon mal auf dem Worldwide Developer Congress.
Und wir verlinken da auch noch mal 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 mal eine Episode zu machen und diese Prinzipien 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 seine Prinzipien vielleicht sich anschauen sollte?
Willst du, soll ich was dazu sagen?
Ich glaube, wir können da beide was dazu sagen.
Fang 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.
Das ist halt 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 diesem Word-File sind die Grafiken drin, die Levels.
Und das bedeutet, man kann halt dann mit der Doom-Engine andere Sachen bauen.
Und dadurch ist dieser Markt entstanden, der heute durch sowas wie Unity oder Unreal-Engine dominiert wird.
Da waren die halt die Ersten.
Und es ist halt 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 irgendwie dazu, dass halt Doom immer noch weiterentwickelt wird mit anderen Grafik-Basis-Sachen.
Und deswegen gibt es auch diese berühmte Geschichte mit Can it 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.
Ja, da kann man vielleicht ergänzen.
Also was 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 sowas, wo man mal drauf gucken kann.
Also ist es 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 das, glaube ich, sich das mal anzuschauen.
Ich fand den Talk zumindest mal ganz interessant und bin da ja 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 Purple Tentacle auf Twitch wirft noch ein Doom in einem PDF.
Ich glaube, es gibt es auch in Excel.
Also das läuft tatsächlich überall.
Und noch so eine kleine Kleinigkeit ist halt, dass die Firma ID, und das hat er meiner Ansicht nach im Talk auch gesagt, tatsächlich ein bisschen mit NeXT verbandelt ist.
Also die Firma, die Steve Jobs zwischen seinen beiden Aufnahmen bei Apple mitgegründet hat, weil sie auf den Maschinen letztendlich entwickelt haben und auch einige von den Entwicklungstools, also die Leveleditoren für Doom und Quake.
Das sind halt NeXTstep Anwendungen, die irgendwie auf den NeXT-Maschinen laufen.
Das ist vielleicht noch so ein ganz nettes Detail.
Hier steht noch Voraussetzung.
Ich weiß gar nicht, ob wir das jetzt alles abgeklärt haben.
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 den Architektenbrillen 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 keine Ahnung vom Game Design, von Spieleentwicklung.
Ich bin ja nur auf der Konsumentenseite.
Aber am Ende des Tages ist auch das Software.
Und es ist durchaus spannend, sich anzuschauen, also welche Sachen funktionieren denn da gut und die können wir uns vielleicht 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 dahinter angesteckt haben muss.
Genau, in dem Kontext.
Also das ist halt ein Startup.
Die haben keine andere Chance.
Also die müssen mit den vier oder fünf Leuten loslegen und 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 irgendwie 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 Colin 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, es ist ein bisschen das, was ich vorhin versuchte zu sagen.
Ich glaube aber, dass es ein Start-up-Thema ist.
Wenn wir uns zusammensetzen und zu vierten Start-up gründen, müssen wir, komme was wolle, mit vier Leuten das hinbekommen.
Und in einem Enterprise-Umfeld ist das halt irgendwie was anderes.
Und ich glaube, dass deswegen das Umfeld das sicher determiniert.
Es kann sein, dass Leute, die das tatsächlich als Job machen, um Geld zu bekommen, vielleicht eben nicht diese 24 Stunden am Tag entwickle ich Mentalität haben.
Die waren damals halt eben auch jung.
Und ich glaube, dass da kein ernsthaftes Leben aussah, 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 halt so fallen gelassen hat, durchaus rausziehen.
Also diese Produktivität, die haben sie sich halt mit sowas wie 30 Stunden am Stück durchcoden 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 Start-up-Mode ist man halt auch anders unterwegs, als wenn ich einen 9-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, sowas, was da hinten dran steht.
Ja, für mich spielt da noch was anderes eine Rolle.
Tatsächlich mache ich demnächst wieder, bei letztes Jahr dort und dieses Jahr wieder, diese TechStream-Konferenz, die halt auch im Wesentlichen tatsächlich Coding Pro Potentate mitorganisiert.
Das ist halt eine Konferenz, die ja 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 durchdaufen 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 macht 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 mal zwei Sätze.
Also Romero konnte an die Erfolge mit InSoftware 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 nicht mehr so dieses durchschlagende Ding rausgekommen.
Während Karmack unter anderem dann bei Oculus mitgearbeitet hat an dem VR Thema.
Das ist vielleicht auch nochmal so ein Punkt, den man abmachen muss.
Aber dann wollen wir jetzt tatsächlich die Prinzipien für uns anschauen.
Muss ich mal sehen, was war das?
Genau, da ist also der erste Bildschirm und das wäre das erste Prinzip.
Also nur Prototypes, keine Prototypen.
Baue einfach das Spiel.
Just make the game polish as you go.
Also poliere es halt oder verbessere es halt, während du es entwickelst.
Don’t depend on polish happening later.
Also verlasse dich nicht darauf, dass du es später irgendwie sozusagen besser, hübscher machen kannst und besser machen kannst.
Always maintain constantly shippable code.
Also sorg dafür, dass es immer Code gibt, den man ausliefern kann und dass der Code immer in einem auslieferbaren Zustand ist.
Tom, was denkst du darüber?
Ja, das macht was mit mir.
Das triggert mich.
Dieser erste Satz nur Prototypes.
Also Prototypen sind für mich ein sehr, sehr wichtiges Werkzeug, um schnell Erkenntnisse zu sammeln.
Also wenn wir Hypothesen haben, die wir prü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 Kontext setzen.
Also eine Möglichkeit, mit Prototypen sinnvoll zu arbeiten, ist halt schnell Feedback zu bekommen.
Wenn ich das nicht habe, wirft es 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 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 im sehr engen 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 herunterarbeiten 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 er nennt es auch Rapid Development to the Extreme.
Sie haben halt extrem schnell was entwickelt und das setzt natürlich voraus, dass alle wissen, was sie da tun.
Also ich würde es so interpretieren, sie 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.
Das wirft natürlich trotzdem so ein paar Fragen auf.
Das ist jetzt 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 gesagt, naja, das ist halt, also ich würde behaupten, die Aussage ist falsch und es ist für mich schwer vorstellbar, dass sie das tatsächlich gelebt haben, weil ohne Prototypen kriege ich kein 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, ob sie 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 nach seiner Zeit, war es eben so, dass das fertige Produkt deutlich anders war, als das, was man immer 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 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 halt an unterschiedlichen Stellen nochmal zum Tragen.
Ich kann an der Qualitätsschraube zwar drehen, aber wenn ich halt an der Qualitätsschraube drehe und sage, weniger Qualität ist okay, dann bedeutet das, dass ich halt mindestens in der Wartung Schwierigkeiten habe und man kann sich jetzt überlegen, an welcher Stelle halt 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 nachvollziehbar, dass man hat 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 herstellen.
Ich glaube, da haben wir auch im Vorhinein nochmal darüber diskutiert.
Das ist heute, glaube ich, etwas, was typischerweise irgendwie eh klar ist.
Wir haben CI-Pipelines, wo man halt Continuous Integration betreibt.
Wir haben Continuous Delivery Pipelines, mit denen wir Sachen in Produktion bringen.
Das ist eine gute Idee, wenn diese Sachen halt in konstante Produktion gebracht werden können.
Damals war das was anderes.
Ich habe halt auch nach der Jahrtausendwende in einem Projekt gesessen, wo wir 14 Tage den Spaß hatten.
Also ich nicht, wo 14 Tage Menschen den Spaß hatten, dafür zu sorgen, 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 es jetzt nichts, was IT alleine sich überlegt hat.
Aber damit haben wir drei Prinzipien und das ist halt irgendwie schwierig.
Ich glaube, es lohnt sich nochmal so ein bisschen in die Zeit rein zu versetzen.
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 oder 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 er noch drin, dann ist das im Zweifel einfach, einen Patch nachzuschieben und ein System, was irgendwo auf dem Server läuft, mit einer aktuelleren Version auszurollen.
Damals, in den guten alten Zeiten, da bedeutete halt Release und Shipping, naja 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, 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 noch mal eine Spur härter.
Und so erklärt sich, glaube ich, auch diese Stricktheit 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 Bisketten 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 Purpotent hat gerade noch gefragt, wie passt der letzte Punkt mit Refactoring zusammen?
Das ist ein guter Punkt.
Ich sehe das Thema Refactoring eher bei diesem Polish as you go.
Also das ist eigentlich für mich dieses, ich versuche das System, wenn es denn da tatsächlich um innere Codequalität geht, konstant zu verbessern.
Das ist auch eines der Probleme, was ich so ein bisschen habe.
Ich glaube, da kommen wir zu den späteren Prinzipien auch noch mal 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 ein Stück Code refactoren kann.
Und dieser zweite Punkt, dass ich das poliere, hat so ein bisschen das Problem, dass man sich auch tot refactoren kann.
Also dass ich dann in einem Loop bin, wo ich nur sage, es muss noch besser werden und nicht mehr dazu komme, Code sozusagen zu shippen.
Ich glaube, das ist sogar eines von den nächsten Prinzipien.
Es gibt ein paar, die sind nicht so wirklich trennscharf, finde ich.
Ich habe die auch in der Reihenfolge so angeordnet, wie ich sie sinnvoll aufeinander aufbauen sehe.
Das war nicht unbedingt die Reihenfolge, die er in seinem Talk hatte.
Aber ich glaube, man kann es dann erkennen.
Wenn wir zum nächsten springen, greifen wir so ein paar von jetzt nochmal auf, die wir gerade gesehen haben.
Genau.
Also da steht, we are our best testing team.
Also wir sind unser bestes Testteam.
And should never allow anyone else to experience bugs or see the game crash.
Also wir sollten nie dafür sorgen oder nie erlauben, dass irgendjemand anders Bugs sieht oder dass das Spiel abstürzt.
Und dann ist 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 test 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 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 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 damit 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 Colin Purpur-Tentakel wirft das mal ein, findet unser Testchen 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-Systemen 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, Code, also perfekte 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 per Potentagel ist halt auch richtig.
Es gibt halt Testteams, die sind anders aufgesetzt.
Ich sehe nicht unbedingt, dass man jetzt sagt, also das ist tatsächlich 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 irgendwie drauf gucken.
Also wenn ich halt irgendwas baue und halt denke, das ist halt perfekt, habe ich halt mein eigenes Ding, von dem ich denke, wie es sein sollte.
Und das finde ich halt dann schwierig.
Coding pro Potentagel 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.
Also die Art und Weise, wie Benutzerinhalte die Software benutzen, kann man nicht vorhersehen.
Ich glaube, hier spielt bis zu einem gewissen Maß halt auch der Sonderfall eine Rolle, dass eben der Mensch, der vor dem Rechner sitzt, also in dem Fall der John Romero, zum einen halt auch ein Kunde ist.
Also nicht, weil das irgendwie Leute sind, die halt 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 der John Carmack eher.
Und das bedeutet halt, dass er vielleicht tatsächlich so eine Dominenexperte ist bis zu einem gewissen Maß.
Weil er eben sich überlegt hat, wie die Level 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änexperten.
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, 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 ihre eigenen Kunden quasi waren.
DocFooding 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 das sind sie nicht unbedingt diejenigen, die am meisten Ahnung davon haben.
Ja, und ich habe tatsächlich mit einem ausgewiesenen Domänexperten gesprochen.
Der hat tatsächlich lange Zeit in der Domäne, die dort für die HL2-Firmware entwickelt wird, gearbeitet hat.
Und der hat so etwas 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 hat diesen, sozusagen einen offenen Geist hat und hat gesagt, okay, die kommen da irgendwie auf coole Ideen.
Lass uns das unterstützen.
Der zweite Punkt, also du solltest 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ät zu ansprechen, 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, wir reviewen Pull Requests.
Also das sage, also habe ich so, weiß ich gar nicht, warum ich da den, vielleicht ist das halt auch kein Widerspruch, aber dieses nicht, 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 vorhin 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 weh tut und nicht mehr schlimm ist, wenn ein Fehler gefunden ist, weil das halt 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 Game 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 erst mal 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 eine CI-Pipeline darstellt, für wahnsinnig wichtig halte 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 Extremisten-Position, 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.
As soon as you see a 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 sowas haben könnte.
Natürlich erst mal 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 auch 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 bug, your new code will be built on a buggy code base and ensure an unstable foundation.
Also wenn ich den Bug nicht sofort fixe, dann habe ich eben eine federhafte Basis und komme dadurch nicht weiter.
Das tut natürlich besonders weh, wenn ich wirklich Shipping über Post mache, wie wir es vorhin gesagt hatten, und ich gar keine Möglichkeit mehr habe, dann etwas nachzureichen.
Dann ist der Bug halt für immer da drin.
Ja, das ist für mich eigentlich ausformuliert, wenn du 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 der Meinung, dass man die perfekte Software nicht bauen kann, aber das hier würde ich ihm tatsächlich mehr oder minder unterschreiben.
Vielleicht noch, also Colin Poop, der 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, also und das ist halt auch der Grund, warum ich irgendwie auch bei uns in der Firma rumlaufe und halt sage, das sind Dinge, die ich irgendwie auch suboptimal gelöst habe, einfach um zu sagen, da sind irgendwie, das machen wir halt irgendwie alle, es geht halt darum, dass wir da irgendwie besser werden und dass wir halt daraus lernen.
Also ich könnte jetzt sagen, ein Fehler ist 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.
Ich glaube, das ist der Punkt, man muss sich halt erst mal 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.
Und genau, ich kann jetzt auch mal die Werbeeinblendung für Aircrash Investigations machen, was ich jetzt wieder angefangen habe zu gucken.
Und das ist eben auch so, dass man halt sagt, okay, der Pilot hat also irgendwie Mist gebaut.
Warum?
Hat ihm irgendjemand gesagt, dass er das 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 wieder 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 nicht nur produktiv oder nicht produktiv, sondern 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 ähnlich verhalten.
Und da kann man was dagegen tun.
Und wenn man zum fünften Mal kaputten Kot 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.
Ja, genau.
Kultur halt.
Exakt, ja.
Und das ist genau das, was ich sage.
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 finde, das ist halt dieses Problem mit dieser Qualitätsschraube.
Und ich, 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 gute und schlechte Teile in einem System, dann muss ich eigentlich sagen, dann habe ich nur noch die Wahl, es zu steuern oder hinzunehmen.
Und das ist, glaube ich, für mich dieses Problem.
Ich finde den Begriff absolutistisch gut.
Solche Sachen, die sagen, du musst halt immer die maximale Qualität liefern.
Ja, cool.
Das heißt, am Ende hast du überall perfekten Code.
Vielleicht haben die das bei Doom wirklich hinbekommen.
Keine Ahnung, ich kenne das System nicht intern.
Sonst würde mir noch Tech oder MetaFont einfallen, wo es ja diese berühmte Bug Bounty gab, die sich mit jedem Bug der Betrag verdoppelt.
Und das ist eben tatsächlich der Versuch, eine perfekte Code-Basis zu bauen.
Das ist von Donald Knuth, der hat dieses System gebaut, um damit seine Bücher zu schreiben.
Das ist halt ein System, was Seitenbeschreibungen umfasst und Fonts generieren kann.
Und der hat halt irgendwann gesagt, er fängt an und gibt jedem, der einen Fehler findet, eine Bug Bounty und die verdoppelt sich 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.
Cody Popotentakel hat geschrieben, zumal die guten Leute mitunter nicht geübt sind, Fehler zu machen, weil sie seltener welche machen.
Das ist interessant.
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, bulletproof your engine by providing defaults upon load failure.
Also sichere dein System oder deine Engine ab, indem du 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 meinen 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.
Also die Aussage, das haben wir so, das haben, also ja, wir haben vielleicht keine Game Engines, wenn wir Informationssysteme bauen.
Ich glaube, wir haben Dinge, die zumindest mal den Platz einnehmen, wie eine Game Engine bei der Produktion von Videospielen.
Nach meinem leidenhaften 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 um das 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 übersetzt sich zum Beispiel eins zu eins auf den Bootstrapping-Prozess.
Also, dass die Anwendung entweder klar definiert in einen Fail-Fast-Zustand übergeht und sagt, okay, wir wissen, warum es gescheitert ist und es geht halt nicht in einem fragwürdigen Zustand irgendwie in Betrieb.
Oder aber wir haben das Ding soweit vorkonfiguriert, dass es zumindest mal sauber läuft und niemanden aufhalten wird beim Arbeiten.
Also das wäre für mich so eine Analogie zur 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 einen Spring oder so noch im Herzen drin.
Aber die sind dann dafür da, um andere Ziele zu erreichen, weniger tedious Arbeitsschritte zu haben, wieder Verwendungen 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 Bildprozess, 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?
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 Cramack hast du halt genannt bei Spring.
Das ist halt im Wesentlichen glaube ich der Jürgen Höller, der dafür sorgt, dass eben das Core-Framework so gut funktioniert oder funktioniert, wie es irgendwie funktioniert.
Und sowas hast du firmenintern nicht und es macht auch keinen Sinn.
Und das ist dort glaube ich irgendwie das Problem.
Bei YouTube hat er mir gesagt, dass man den ersten Satz, also es ist halt unwahrscheinlich wichtig, dass das System immer ausführbar ist.
Dass man das halt so verstehen kann, dass die Software niemals broken darliegen 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 im Technische Consultant.
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 komponieren 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 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 Umsetzen.
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 habe 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 bedeutet nicht, heutzutage kaufst du, also ich kann mir nicht vorstellen, dass jemanden als Spielestudio anfängt, eine eigene Engine zu bauen, weil das einfach ökonomisch wenig Sinn macht, weil die Lizenzkosten insbesondere für kleine Unternehmer sehr gering sind.
Und ich, wie soll ich sagen, also das ist halt der Grund, weswegen wir halt versuchen, Infrastruktur zu benutzen, statt sie halt selber zu entwickeln.
CodingPurpotentacle 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 die Runtime gemeint.
Also Bulletproof your Engine by providing defaults upon load failure bedeutet ja, dass ich eben dazu in der Lage bin, wenn das System 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 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 in mir 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 losliegt 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.
Das ist 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 halt da sind.
Also das meinte ich ja vorher noch mit Fail Early.
Also das sollte eine ganze Berufsentscheidung 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 ein anderes Ding, aber wir machen da zu viel Aufwürfe, sonst kommen wir gar nicht durch.
Sorry, dann hattest du das tatsächlich so gesagt und dann habe ich das heute noch 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 einen Total Refactoring kommt.
Also wie schon im Prinzip das, was ich sagte.
Also ich werde gute und schlechte Teile in dem Code haben.
Ich kann nicht alles perfekt machen, das glaube ich nicht.
Es wird Teile geben, die besser und schlichter sind, komparativ.
Und wenn ich da irgendwie rangehe und sage, ich möchte 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 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.
Und deswegen glaube ich erstmal, dass es kein so wirklich sinnvolles Prinzip ist.
Der Punkt, den du hast, warum du den 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, wie soll ich sagen, das wäre vielleicht ein Panel in sich wert, diese sehr starke Orientierung auf Qualität, die Software Craftsmanship eingeführt hat, finde ich echt schwierig.
Und das ist hier ja manifestiert, also es hat die Aussage, du willst halt wirklich die aller, aller, allerbeste 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 hat dasselbe Thema.
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 erst mal.
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 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 halt tatsächlich, also ich kann es für Spieleentwicklung nicht endgültig bewerten.
Für 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 dafür, dass ihr gute Spiele machen kann.
Wobei okay ist not okay, hat auch gerade gesagt, a fool with a tool is just a fool.
Also jemand, der nichts kann, ist auch, wenn er Werkzeuge hat, irgendwie immer noch jemand, der nichts kann.
Aber da steht ja auch hilft.
Also das bedeutet nicht, sorgt sofort dafür, dass es gute Spiele gibt.
Und in gewisser Weise ist das nachvollziehbar.
Also wenn ich 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 zu kaufen.
Und das ist ja lustigerweise mit IT-Software genau das.
Also der Vorteil von IT-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 technisch maßstäblich gesetzt.
Ich kann diese Technologie einfach benutzen.
Ich kann sie lizenzieren und kann selber ein Spiel machen, was technisch genauso gut ist, ohne mich anzustrengen.
Das heißt, ich habe jetzt ein Problem im Inhalt.
Also ich muss irgendwas haben, weil mir das Level Design super ist.
Und das ist eigentlich ja das, was sie eben pioniert haben.
Und das bedeutet, die zeitliche Auf-Tools-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, die Entwickler sollen bitte nicht die Tools schreiben.
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, dass wir 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 überhaupt eine Entwicklungsumgebung haben, die den Namen verdient.
Deswegen sage ich Adressat wechseln.
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 etwas entwickeln zu können.
Aber ich möchte natürlich nicht meine Entwicklerzeit darauf verschwenden, zu fixen, was irgendwie an Setup nicht da ist.
Also Leuten zu erklären, dass sie den Virenscanner so konfigurieren, dass der mir nicht meinen Bildprozess langsam macht.
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.
Das widerspricht 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 einsetzen und nutzen.
Das haben die auch gemacht.
Die haben einen C-Compiler benutzt und haben den natürlich nicht selber eingeschrieben.
Also Klammer auf.
Ich glaube, das stimmt nicht ganz, weil sie haben einen Cross-Compiler von dem Knut C-DOS selber gebaut, aber sie haben dann die Sachen eingebunden und sich darum gekümmert.
Das ist, glaube ich, auch richtig oder der richtige Ansatz.
Ich weiß nicht genau, wo der Widerspruch ist.
Das nächste ist auch recht spannend.
Da steckt noch ganz viel dahinter.
Genau, da steht, use a development system that is superior to your target.
Also benutze ein Entwicklungssystem, das da im Zielsystem überlegen ist.
Ja, also aus der Geschichte, diese Überlieferung.
Die haben halt für DOS-PCs gearbeitet.
Am Anfang auf DOS-PCs programmiert und debuggt und dann festgestellt, 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 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 so, dass die NeXT-Maschinen damals 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 ist, es gibt dieses Mastersoft-Doom.
Ich habe noch mal nachgeguckt, da stand es nicht drin, aber irgendwo habe ich das halt.
Das ist ein Buch über eben wie damals diese Systeme entwickelt worden sind.
Irgendwo habe ich mal aufgeschnappt, dass eigentlich der wesentliche Punkt war, dass sie einen Editor hatten und dann halt 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 Commando-Zeiten-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 NeXTstep gelaufen sind.
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 gewesen damals als das, was man auf DOS hatte und ein Betriebssystem, wo eben nicht irgendeine Anwendung dafür sorgen kann, dass der ganze Computer 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 gegen ein Betriebssystem, Windows, macOS, Linux und was auch immer, dass es eben einfach so mal kurz abstürzt, weil man halt irgendeinen blöden Fehler gemacht hat, mit einem Bufferflow oder was auch immer.
Sondern nicht, dass das Betriebssystem das irgendwie abfängt.
Ich würde auch erwarten, dass heute sowas wie ein Editor, ein vernünftiger Compiler oder so auf all diesen 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 hübscher, wäre jetzt mein Gefühl.
Sie waren damit auf jeden Fall produktiver und von daher passt das schon.
Da gibt es noch diese Kuriosität, dass Romero davon berichtet, dass sie also 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.
Ist mir so ein bisschen unklar, was man jetzt genau damit hätte machen können.
Ich kann mir so Sachen vorstellen wie 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, man braucht eine richtig gute Entwicklungsumgebung mit ganz viel Dampf dahinter bis zum Extrem treiben wollen und wollten da wirklich so eine Cray-Maschine für damals unglaublich leistungsstark hinstellen.
Aber dann fehlt mir die Fantasie, wofür man das jetzt konkret hätte einsetzen können.
Ich habe es gerade nachgeguckt.
Das ist ein Multiprozessor-System mit SPARC-Prozessoren.
Du kannst wahrscheinlich damit wahnsinnig schnell kompilieren.
Das ist ja nachvollziehbar.
Vielleicht ist es nur die Beschleunigung vom Kompilierprozess.
Okay ist not okay sagt.
I disagree.
Auf meiner Bugsession mit 128 Gigabyte läuft es aber beim Kunden nicht.
Ja genau.
Das ist sozusagen eine Komponente des Problems.
Beziehungsweise das kann man eigentlich daran gut illustrieren.
Das Entwicklungssystem ist halt irgendeine NeXT mit 4 Megabyte RAM.
Und das, worauf es laufen soll, ist ein 64 Kilobyte DOS-PC.
Das zeigt eben, dass das Entwicklungssystem was anderes ist, als das, worauf es nachher läuft.
Ich weiß nicht, worauf sich Marco hier bezieht.
Marco Heimisdorf hat geschrieben.
Anderer Romero.
Aber keine Ahnung.
Da fehlt mir jetzt Kontext.
Ja, viel mehr Kontext.
Marco, du bist im falschen Chat.
Ja, oder da ist schon was bei LinkedIn, was wir nicht gesehen haben.
So, dann kommt das achte Prinzip.
Das ist, write your code for this game, only not for future game.
You are going to be writing new code later, because you will be smarter.
Und das bedeutet, dass ich Code nur für das Spiel, was ich jetzt habe, schreiben sollte.
Und nicht für irgendetwas, was ich mir ausgedacht habe.
Das ist für mich nachvollziehbar und deutlich sinnvoll.
Ich sollte nicht versuchen, Dinge zu antizipieren, die vielleicht mal kommen, sondern ich sollte Sachen für das jetzige Ding 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 Jagni mit dabei?
Also wenn ich 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.
Der Punkt ist halt ganz wichtig.
Später bin ich halt einfach schlauer.
Also jetzt irgendwas vorzubereiten, was ich später vielleicht deutlich informierter machen kann, ist oftmals keine gute Idee.
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, noch mal sehr schnell durchzugehen, oder?
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, und dann sind wir vielleicht fünf Minuten drüber.
Dann würden wir zwei Konzepte in einer Minute schaffen.
Aber ja, wir können es mal ausprobieren.
Also das neunte ist, um Design-Konsistenz zu erreichen.
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 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 hier aber für Design-Konsistenz genutzt.
Und ich habe es ehrlich gesagt nicht verstanden, glaube ich.
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 Fackel-Entitä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 und mit Design-Consistency.
Das Wording ist da vielleicht ein bisschen abweichend von dem, was wir gewöhnt sind.
Aber ich denke, er meint es.
Das ist so ein abfachlicher 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 das ist halt die Art und Weise, wie wir unser System aufteilen.
Du hast ein kohäsives, 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 der einfachen Schnittstelle.
Ja, also ja, nach Prinzip 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 cause delays.
Also es hat letztendlich bedeutet, sei transparent.
Erzähle jedem, was du gerade versuchst und was du gerade machst.
Und ich behaupte, dass ich sehe nicht, wie man damit große Systeme skalierbar entwickeln kann.
Wenn 100 Leute versuchen zu verstehen, was 100 Leute entwickeln.
Also ich bin ein Teammitglied auf mich in einem 100-Leute-Team.
Es laufen also 99 Leute rum, die mir exakt erzählen, wie sie ihre Probleme lösen.
Das soll ich alles verstehen und Feedback geben?
Nee, funktioniert nicht.
Also funktioniert bei drei, funktioniert bei vier, aber sicherlich nicht bei 100.
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 ein Problem habe, weil ich würde behaupten, das Problem ist große Teams.
Also eben skalieren und nicht zu zweit oder alleine um was bauen.
Und das ist halt auch das, was uns meistens passiert.
Aber es gibt halt auch sowas wie Peer Programming, Ensemble Programming, wo halt ein Team sehr eng miteinander arbeitet, 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 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 Afrin, Afrinschen oder sowas, Afrination, 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 Rahmenbedingungen herrschen.
Team, Person, Team versus Organisation.
Und da kommt dann die nächste Frage, ist halt die Frage, wie schön das alles noch eine Rolle spielt in Zeiten von unbegrenzter Hardware und Webcoding.
Also ich würde dem entgegenhalten, dass ich, ich habe tatsächlich das gegenteilige Gefühl.
Ich bin der Meinung, dass die Basisdinge, Modularisierung, wie wir Sachen skalieren, wie wir 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 halt meiner Ansicht nach tatsächlich falsch und auch gefährlich.
Ich glaube, das Problem ist hier eher, dass die Welt, in 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, die muss man dann halt ein bisschen suchen.
Die sind sicherlich universell sinnvoll, sich zumindest mal zu betrachten.
Wir hatten ja zu Eingang gesagt, 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, passt er oder passt er 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, um vollständig ehrlich zu sein, ich bin insgesamt nicht so positiv angetan von der Sache.
Da kommt jetzt noch die Aussage, da habe ich mich vielleicht falsch ausgedrückt, da stimme ich dir zu.
So zykulturell sind das andere Rahmenbedingungen.
Das stimmt.
Gut, wir sollten vielleicht noch das Prinzipien diskutieren, weil das ist das Nächste, wo ich entschieden widersprechen würde.
Der Schild Programmierung ist eine kreative Kunstform, die in Logik basiert.
Dem würde ich widersprechen.
Ohne Zweifel sind für mich Computerspiele eine Kunstform, also multimediale Kunst.
Das ist für mich offensichtlich.
Aber Programmierung ist keine Kunst in dem Bereich, in dem wir es betreiben.
Da geht es darum, effizient, effektiv ein wirtschaftliches Problem zu lösen.
Und das ist etwas anderes.
Und dann steht 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 dieses Problem existiert mit, naja, 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 irgendwie Mechanismen wie Mob Programming oder Auxomal 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 darü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, ja, 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 erst mal noch zulassen.
Aber zumindest mal so als Outro zum darüber nachdenken.
Food for thought ist doch nochmal ein ganz nettes Ding.
Genau.
Und also letzter Kommentar sozusagen oder eher von den Zuschauern.
Da ist halt Mr. Reasable, der sagt, ist in meiner Pappe definitiv nicht so.
Traurigerweise ist es so, dass dem Kunden am wichtigsten ist, dass erst mal 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, sorgt doch mal dafür, gib uns mal Ideen, wie wir dieses System besser bauen, damit es eben wartbarer wird und besser wird.
Und an der Stelle sind sie halt Verbündete für Codequalität.
Ja, aber es ist halt oftmals nicht so wirklich sichtbar.
Also das ist ja genau das Problem, mit 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 ja, das ist halt das, was uns dann auch im Spiel hält tatsächlich.
Ja, ich bin halt nicht sicher.
Also Mr. Rees beschreibt da gerade, aber das wirkt sich auf die Wartbarkeit aus.
Genau.
Und es sind Punkte denkbar.
Das, was ich da halt immer aus dem Rucksack ziehe, ist diese Geschichte mit, wenn wir zum Weihnachtsgeschäft ein System haben wollen für unser Start-up und zeigen wollen, dass wir erfolgreich sind, dann ist es super, wenn ich am 1.1. ein super wartbares System habe, dann können wir den Laden dicht machen.
Es gibt bestimmte Situationen, wo die Nachhaltigkeit keine Rolle spielt.
Problem ist halt, dass so 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 da 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 im 14.
Tragen 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 software-architektur.tv.
Sei dabei, stell Fragen und komm auch gern auf uns zu.