"Gesetze" der Informatik #90

Moin, so einfach komplex. Jetzt ist Folge 90 dran, ich moderiere das heute mal an, weil das Thema hatte ich mich gerne ausgesucht, finde ich super spannend, hatte ich überhaupt nicht auf dem Zettel und wir wollen uns heute mal über die Gesetze der Informatik unterhalten, da musste ich auch erst mal gucken, was ist denn das, wieso Gesetze der Informatik, ja es geht um Heuristiken, um um Sachen die vor sehr langer Zeit prophezeit wurden, die sich als wahr

erweisen. Ja, die quasi so ne Art größere Lebensweisheiten sind zum Projektmanagement und zum Inneren Funktionieren von Software, die wollen wir einfach mal durch Xen heute und Gerrit hat sich das ausgedacht und ich frag ihn gleich mal. Moin Gerrit, Wir sind auf das

Thema gekommen. Moin Burkhard, Das ist relativ einfach und zwar hatte ich das Vergnügen auch so n paar Semester Informatik zu haben in meinem Studium Wirtschaftsingenieur wissen, da haben wir nicht programmiert oder so maximal irgendwie mal so mit so ne so ne kleine Website erstellt oder sowas. Aber ich hatte halt einen, einen Prof. Dannenberg, und der hat uns unter anderem diese Gesetze, oder muss er eher sagen, wie du es gerade gesagt hast, Gesetzmäßigkeiten in den Kopf

gebläut. Er meinte, das müsst ihr verstehen, damit ihr versteht, wie die Softwarewelt tickt. Ja, und das hat er uns halt vor 10 Jahren gesagt und wenn wir gleich drauf kommen auf die ersten Gesetze wird wird auch klarer was da was er damit meinte. Ja das haben wir natürlich damals offen gestanden, nicht gerafft, ja. Aber ich erinnere mich immer gerne dran zurück und ich hab sogar mal die alten Vorlesungsunterlagen rausgekramt.

Ja, die ich noch so hatte und da waren schon so n Paar davon drinne und ja, mit einer kleinen Recherche hab ich noch n paar mehr gefunden oder haben wir noch n paar mehr gefunden und jetzt für heute vorbereitet 11 an der Zahl manche sind ganz klar mit der Informatik verhaftet wie du schon sagst es sind keine Gesetze wo man bestraft wird wenn man sie bricht so es gibt keine keine calaw Enforcement ja es sind also eher Dinge die man beobachten kann oder die

vorhergesagt wurden und dadurch. Könnte man die Gesetze nennen und ich glaub wir haben schon echt in vielen Podcast folgen immer mal wieder das ein oder andere davon auch erwähnt oder unsere Gäste haben das getan und das heißt die sind schon irgendwo in den Köpfen und ich würd es mich total freuen, wenn wir heute die alle mal auf einen Punkt vorstellen, erklären was dahinter steckt und auch so n paar Beispiele. Machen, das machen wir. Dann geht es los.

Ich glaub, du hast dir auch so n bisschen ne Struktur ausgedacht wie wir durchgehen, also sind nicht 11 die flach nebeneinander liegen, sondern du hast den Ganzen schon so n bisschen n roten Faden gegeben. Vielleicht fängst du einfach mal an Gerrit und Moderierst das mal so n bisschen ein, wo wir wo wir mit loslegen wollen. Das mach ich also. Wir gucken uns erst mal n bisschen Hardware und und allgemeinen Leistung von Computern an und das Erste ist

Moore Slaw, das Gesetz des Wachstums auch genannt, und Moore war ein Mitbegründer von Intel und er hat gesagt, dass die Anzahl der Transistoren auf einem integrierten Schaltkreis sich etwa alle 18 bis 24 Monate verdoppelt. Und jetzt kommst du. Was ist n Transistor und was meint ihr damit eigentlich? OK, safe hast du, ich sag ja immer, ich hab von Hardware keine Ahnung, hab ich auch heute noch nicht na ja OK transistor was kennst vom Transistorradio

da? Da kommt der Begriff her, aber ich am Ende des Tages ist es die ja die kleinste Schalteinheit würd ich sagen, so seh ich es ja also alle Elektrotechniker auch nicht jetzt vielleicht aber für mich ist das das Ding was halt den Strom an und abschaltet mehr oder weniger. Und die Einsen und Nullen produziert. Denn das ist mehr unsere ganze Informatik Software.

Am Ende des Tages ist es nur eine, nur aber eine Abfolge von Einsen und Nullen und wenn was berechnet wird, dann müssen halt diese Einsen und Nullen und vielleicht ein anderes bringen von Einsen 0 miteinander verrechnet werden und dann danach alles abzubilden und dafür braucht es Hardwaremäßig die Transistoren und natürlich je mehr ich auf je kleineren Fläche zusammenbekomme desto mehr Rechenoperationen pro.

Zeiteinheit kann ich halt einfach durchziehen und es ist im Prinzip die Transistorendichte ist korreliert direkt und sofort mit der Potenz meiner Hardware, die dann irgendwas rechnen kann, ne? OK, das heißt n Chip bleibt irgendwie gleich groß von der Baugröße aber hat alle 18 bis 24 Monate doppelt so viel Rechenleistung. So, das ist quasi die Aussage dann das hat er 1965 gesagt, der der Gordon Moore stimmt das heute noch? Ich glaub also ich hab auch n bisschen was zu gelesen.

Ich lustigerweise hatte ich das in meinem Vordiplom, Informatik hatten wir die gar nicht so durchgeixt vielleicht waren wir gleich irgendwie mit Compilerbau und Algorithmic und Zuven und was weiß ich sortieren zugange waren aber was ich noch gelesen hab ist, dass er das erst mal gesagt hatte und er hat sich selber validiert also er hat es noch erlebt ja also die ersten die ersten 234 Jahre konnte man beobachten.

Dass es tatsächlich stimmt, ja, ich glaub sogar Jahrzehnte, ja genau, weil die ersten, also die ersten Jahre, hat er Beobachter, das stimmt, und dann wurde quasi aus dieser, aus seiner Aussage, die ich glaub ein Teil eines Papiers war oder irgend so was tatsächlich diese Gesetzmäßigkeiten n wirkliches Gesetz, da hast du ja dann erst wenn es, wenn es tatsächlich

auch über lange Zeit valide ist. Ja und ich glaub es war tatsächlich, es ist einfach so, ja, es ist halt ein ein exponentielles Wachstum. Weil wir technisch in der Lage waren, halt diese Transistoren immer, immer, immer kleiner zu machen. Ja, und es ist ja heute noch, es gibt ja sehr krasse Firmen, die man eigentlich nicht so kennt, ich glaube, in den Niederlanden sitzt eine, die für sehr bekannt ist, die, die mit man braucht dafür schon wieder Hightech.

Ja, es ist so, n bisschen beflügelt sich selbst um die Transistoren so klein zu kriegen, brauchst du auch wieder Transistoren für Maschinen, die das so exakt machen, das sind ja keine Menschen, die das irgendwie auflöten, denn wir sprechen hier, heute sollen wir mal kurz sagen, von so einem Transistor. Die sind halt in der Größe von Atomen. Ja, also also es gibt es sind nur noch mehrere, also man kann Sprache von Nanometer und so

weiter Nanometer ist ja schon die Einheit, indem ich irgendwie bei bei Atomen schon irgendwie ankomme demnächst und wir haben nur noch n paar Schichtdicken von Atomen irgendwie und da drauf auf dieser Losgröße der deutschen Transistoren gesetzt. Insofern ist glaub ich dieses Gesetz jetzt demnächst jedenfalls mit dem, wenn wir es auf den Transistoren und auf dieser Hardware dengeln, bald Feierabend.

Weil die Gesetzmäßigkeit der Physik uns jetzt NB steht ja, weil n Atom ist halt die kleinste Einheit, mit der wir so rummachen können und da und da drunter, da geht halt erstmal nichts. Ja, das heißt ich Krieg nicht mehr Transistoren da drauf, weil es physikalisch einfach nicht mehr geht, ja selbst mit der mit der grasselten Maschine nicht

mehr. Ich glaub die Firma aus, aus aus den Niederlanden, die die an die Maschinen baut, die heißt ASML, ja, die haben auch die waren auch gut im Aufschwung unter dem ganzen. Jetzt also unter jedem Aufschwung, aber jetzt unter dem KI Aufschwung sind mit Nvidia auch ganz gut gewachsen. Genau, genau das ist auch total

wichtig. Nvidia Grafikkarten haben ja auch Recheneinheiten drauf, die GPUS ist quasi das Grafikkartenanaloge und zum CPU und gerade die jetzt auch mit KI und so weiter ja je mehr Transistoren desto mehr Training desto mehr geht ab. OK, würde ich sagen, lass es weitermachen. Ich ich finde es wichtig hier im Kopf zu behalten und und das war auch bei denen von Prof.

Dannenberg dabei. Leute, ihr müsst verstehen, nur weil heute die Welt so aussieht, heißt das in 10 Jahren, dass sich das halt quasi fünfmal verdoppelt hat. Ja, und was dann rechentechnisch möglich ist, das muss man sich mal vorstellen. Ja, und das hat er ganz versucht Einzubläuen, was wir verstanden. Haben ich glaub, dass das Gesetz

vielleicht sogar weitergeht. Ich, ich fürchte, dass wir jetzt so n Dip haben, weil wir, weil wir technologisch an den Ende kommen, was die Transistoren angeht, aber man kann es ja mal sagen, es ist vielleicht Äpfel mit Birnen, aber wenn wir

quantencomputing angucken. Dann haben wir ne neue Idee, wie wir das, also wie wir das Computing umsetzen, mit einer anderen Hardware Grundlage, mit den Kubits und so weiter das ist natürlich noch nicht so weit, dass das jeder unterm Schreibtisch stehen hat, aber ich schätze, dass das kommen wird, so wie ich die Menschheit kenne.

Und dann eröffnet sich quasi noch mal ne neue Tür, dann ist es vielleicht nicht mehr der Mur, der irgendwas sagt, aber dann haben wir vielleicht noch mal so nen exponentiellen Anschub, wenn wir quasi die Entwicklung. Umswitchen auf ne neue, auf neue Systematik wie Quantencomputing zum Beispiel. Ja, also da kann glaub ich auch noch mal richtig was kommen, ne ist immer noch kein Ende in Sicht. Ja, das ist schon aufgefahren. Ja. OK, dann würd ich mal das zweite

vorstellen. Go had das ist Würz law und das ist das Gesetz der Verlangsamung und der Herr Wirth ist der Herr Niklaus Wirth, ein Schweizer Informatiker, der unter anderem bei der Entwicklung von Pascal, der Programmiersprache Pascal mitgewirkt hat. Oder ja federführend, die sie

sogar vorangetrieben hat. Der hat gesagt, Software wird schneller langsamer als Hardware schneller wird und dann musste ich dran denken an die Folge mit dem Henrik klösch Folge 88 glaub ich da hast du das also mit ihm vor zurück diskutiert. Ja und das heißt ihr merkt das ja in der in der Praxis. Ja, das ist tatsächlich was, was mir mein Professor, mein Informatikprofessor auch schon mal gesagt hat. Da hab ich nur gesagt, sie sei ein Gesetz.

Hat er nicht Würzburg zugesagt, aber hat gesagt, das ist Halt Schicksal der der Informatiker, dass je schneller die Hardware wird, desto fauler ist man quasi und desto, ja weniger Mühe gibt man sich um extrem performanten Code zu schreiben, weil weil die Hardware das Halt schon einem für einen Wegbügelt ja und genau ich glaube das soll das heißen, wenn ich es richtig verstanden hab, dieses Gesetz, das obwohl du viel schnellere

Rechenleistungen hast gefühlt. Die gefühlte Schnelligkeit der Software nicht in dem gleichen Maße zunimmt.

Ja, ich glaube aber, das hat mindestens 2 Gründe, also der eine Grund ist natürlich klar ich, ich hab erstens höhere Sprachen als Softwareentwickler und damit kann ich nicht mehr ganz so hart optimieren meinen Code und so und vielleicht bin ich auch an der anderen Stelle ein oder anderen Stelle ein bisschen das E fair und sag OK das passt schon so und ich muss ja auch immer abwägen wie schnell bin ich mit meinem Produkt fertig und wie lange benötige ich zur Optimierung des

letzten Bits. Aber auf der anderen Seite muss man ja auch schon dazu sagen, dass die Software, die uns heutzutage umgibt, auch um Dimensionen komplexer ist als das, was wir damals hatten. Ja, ich, wir hatten das auch diskutiert, aber ich nehme mal das Beispiel, damals gab es natürlich auch n Word Prozessor damals, also mit Windows 95 oder irgendsowas ja irgendwie 10 Disketten hast du da reingeschliffen und dann konntest du da auch dein

Dokument editieren. Aber jetzt kann man das auch nicht vergleichen mit dem heutigen Word würd ich sagen, es wär schon auch gemein. Ja weil da steckt halt schon noch ne ganze Masse mehr an Featuren drin und so weiter die man damals halt einfach noch in Sternen hatte. Ja so man. Muss jetzt ja auch sagen, wenn jetzt beide zutreffen nur slaw und wird slaw, dann würde sich das ja ausgleichen oder sogar alles insgesamt langsamer

werden. Ne weil er ja sagt das muss man sich noch mal auf der Zunge zergehen lassen, Software wird schneller langsamer als Hardware schneller wird und du sagst jetzt 1 war ja genau das Thema. Hardware wird schneller, ja, weil mehr Transistoren, also was damit auch gemeint ist, ist neben neben dem, dass dass Entwickler vielleicht fauler werden, dass einfach auch so viele Abstraktionsschichten dazwischen jetzt auftauchen ne und und Frameworks die genutzt

werden. Also ich bin ja super weit weg von den einzelnen Nullen, wenn ich wenn ich heute programmiere mit mit mit Javascript oder ähnlichem. Ja, das ist, das ist richtig. Genau das stimmt. Damit erkaufen wir uns natürlich genau das, was ich gerade gesagt hatte, dadurch, dass wir quasi viele Abstraktionslevel haben, sind wir natürlich aber auch schneller dabei. Neue Produkte in die Welt zu setzen?

Ja, denn sonst müsste man ja quasi jede neue Software vom von der 1 und der 0 auf aufbauen und hart optimieren. Dann komm ich aber erst nach 10 Jahren überhaupt an. Irgendwie hab mein Softwareprodukt fertig, dann mag das ja irgendwie rasend schnell sein, es braucht bloß keiner mehr, weil alle anderen haben das schon längst gemacht, was du machen wolltest. Wir haben ja auch NN ökonomischen Aspekt bei der ganzen Geschichte. Total ist n Kompromiss ja, aber es ist immer gut das im Kopf zu

behalten. Ja das je mehr ne Software kann und je abstrakter ich unterwegs bin desto. Mehr Hardware Ressource nutze ich wieder und wird tendenziell auch wieder langsamer. Ja, es gibt eine Gegenbewegung,

finde ich. Das kann man ja vielleicht noch mal auch erwähnen, wir haben ja die das IOT, das gibt es natürlich jetzt schon auch lange, aber das gab es ja auch nicht immer, dass wir quasi auf den auf dem, dass wir alle möglichen Maschinen halt auch quasi clever machen, und hier hatten wir ja ganz lange nicht den Überschwang an zu krasser Hardware, sondern waren eher sehr limitiert in dem was halt so ne kleine Box irgendwie dann noch kann und viel weniger

Arbeit speichern, viel weniger Prozessorleistung. Und da wurde auf einmal wieder Mehrwert gelegt und man musste auch ein paar Programmierer wieder aus der Schublade holen. Die die das dann konnten mit den entsprechenden Technologien, mit den Programmiersprachen, die quasi sehr low levelig sind, dann sehr energieeffiziente und Performance effiziente Software zu machen, die dann halt auf dieser viel schwächeren Hardware

dann lauffähig wird. Ja und da da ist glaube ich, da sind schon viele, ja man kann mal so in die Arduino libries gucken, ja wenn man sich so den Code anguckt, da gibt es schon Leute, die sind sehr lange dabei, die letzten Bits noch zu optimieren und. Damit das alles gut auf so n kleine Arduino drauf passt und noch richtig zügig läuft. Ja, also man kann jetzt nicht alle Entwickler in den Pott schmeißen, ihr seid alle faul und ihr seid alle langsam und so

was ist los. Ja mindestens da gibt es noch so n Paar so n paar Leute die da auch richtig viel wert drauf legen ja. Danke für diese zweite Sichtweise auf das Thema. Das ist sowieso nicht unser Anliegen hier irgendwen in den Pott zu schmeißen oder n Vorwurf zu machen und ausdenken tun wir uns ja diese Gesetze auch nicht, ja. Das stimmt. Ein kurzer Hinweis in eigener Sache. Kennst du das auch, dass von neuer Software zur Digitalisierung der Produktion zurückgeschreckt wird?

Ihr seid gefangen zwischen starrer, veralteter Standardsoftware und endlosen Individualentwicklungsprojekten unsere Mission bei Heisenware ist es, das zu beenden mit unserem App Baukasten geben wir dir die Möglichkeit, maßgeschneiderte Software für den Shopfloor schnell und ohne Code zu erstellen Denk an Maschinendatenerfassung moderne Visualisierungen für die Produktionsleiter.

Oder eine mobile App zur Buchung von Zeiten direkt am Arbeitsplatz. Und das beste, du kannst deine Lösung ganz einfach ohne it Aufwand selbst betreiben. Kurz gesagt, günstiger als eine externe Entwicklung unendlich passender als Software von der Stange. Weitere Infos und eine kostenlose 30 Tage Testphase findest du auf heisenware.com. Einfach komplex als Träumhörer bieten wir dir im Anschluss 20% Rabatt auf alle Pakete im ersten Jahr und jetzt viel Spaß mit der weiteren Folge.

Ja, hau mal einen raus, Gerrit, Was ist das nächste? Ich glaub das hab ich schon mal, das hab ich schon noch mal mehr gehört, wenn ich das hier so lese was auf unserem Spicker steht. Pass auf, ich mach ne Intro dazu, aber dann musst du wieder kommen, weil es ist n Thema das

dir glaub ich auch wichtig ist. Werden ja auch schon Podcast folgen dazu gemacht Amdals Law das Gesetz des Flaschenhalses der Autor ist Jean Amdal, ein US amerikanischer Softwarearchitekt der. Bei IBM beschäftigt war und er sagt die maximale Beschleunigung eines Programms durch Parallelisierung wird durch seinen sequentiellen, nicht parallelisierbaren Anteil begrenzt. Das ist der Flaschenhals dann ne wo man nicht parallelisieren

kann. Ja Beispiel ne, hast du auch gleich mit aufgeschrieben, kann ich ja mal. Passt super ja ich les das einfach mal hier gerade mal kurz vor auf der Tonspur also wenn wir nen LKW zum Beispiel uns angucken und wir haben jetzt 2 Sachen wir wir haben das Laden. Und das verbringen quasi der Ladung an den Zielort. Ja, und ich kann aber den LKW quasi nur der Reihe nach beladen, weil dieser Prozess nicht parallelisierbar ist.

Ich muss den quasi muss die dicksten Pakete erstmal hinten stellen und das nächste davor und so weiter und das Beladen dauert irgendwie 1010 Minuten und die Fahrt, die dauert dann von mir aus 50 Minuten. Dann habe ich im komplett sequentiellen Fluss also eine Stunde Zeit, ich werde alle 10 Minuten und fahre 50 Minuten zum Zielort.

Und jetzt kann ich parallelisieren und wenn ich jetzt meinetwegen die LKWS parallel die Fahrt parallelisieren kann, indem ich halt sag, pass auf ich, ich fahr halt irgendwie mit 50 LKWS gleichzeitig, ja dann reduziert sich natürlich da die Zeit, aber die 10 Minuten, die ich halt für jeden LKW zum einladen brauche, die brauch ich halt ja auch, wenn ich die 50 gleichzeitig einlade, es braucht halt 10 Minuten, das heißt kurz weg dieser ganze Prozess zusammen

den Krieg ich halt nicht schneller als 10 Minuten plus gehackte hin. Weil selbst wenn ich dann quasi durch die parallele Fahrt dann quasi nur noch auf eine Minute aggregiert zusammen runterkomme, dass die Fahrt dauert, hab ich halt diese 10 Minuten beladungszeit. Das heißt, ich hab nur einen Kran oder so zum Beladen oder einen Gabelstapler. Und der ist mein Flaschenhals. Und der ist der Flaschenhals, der nicht parallelisierbar ist. OK. Richtig, genau.

Und das ist ja, das ist in der Informatik und im Computerprogramm, ist es genauso. Ja, ich würde mal nicht sagen, dass man. Also man kann schon sehr viel parallelisieren und es ist auch immer gut so, aber da hatten wir ja auch schon folgen drüber.

Es ist aber auch gar nicht so einfach, parallele Programme gut zu managen und deswegen ist das Glaube ich schon ein schon ein sehr wichtiges, sehr wichtiges Gesetz und man ist vor allen Dingen dafür wichtig, dass man als Softwareentwickler für die Architektur genau das herausfindet, erstmal also jetzt unserem Beispiel ist ja völlig offensichtlich, was da los ist. Ja, aber im Code muss es einem erstmal offensichtlich werden, wo sind denn überhaupt die Stellen, die erstens.

Zeitfresser sind und zweitens noch nicht parallelisiert. Das ist manchmal gar nicht so einfach herauszufinden.

Heutzutage können wir nämlich, weil wir haben ja relativ hoch verteilt, das ist ja also gerade wenn wir im Web gucken, dann sind ja Sachen sowieso die ganze Zeit parallel, ist irgendwie verteilt, ich hab Microservices da drin, hab ich irgendwie noch mal Parallelisierung und so weiter und sofort, also tricky, aber weil das so tricky ist, gibt es ne krasse Bewegung innerhalb der Programmiersprache würde ich sagen, ich weiß jetzt nicht, sollen sollen mich die Zuhörer korrigieren, aber ich

finde es so. Was zum Beispiel Node JS, was ja Java Script ist für es, für den Server und was von vornherein die Idee hat, alles was paralysierbar ist schon quasi mit in der Programmiersprache gleich zu paralysieren, indem wir diese schicke Awade Async awade haben, damit fräs ich eigentlich ganz gut schon was ab, weil quasi schon vorgegeben ist in der Sprache das immer dann, wenn irgendwas langsam sein könnte, wie zum Beispiel ein Pfeil laden oder ein großes

Pfeil schreiben oder Irgendsowas. Dann ist das quasi in der in der Programmiersprache schon mit angelegt, dass das ein asynchroner Prozess wird, also theoretisch parallel laufen kann, neben anderen Dingen, die im im im Code vorangehen. Ja dann muss ich dann nicht mehr

so viel nachdenken. Ja, da muss ich eigentlich nur noch aufpassen, dass das, was noch sequentiell ist, quasi nicht lange dauert, lange dauern tut irgendwas in der in den Anwendungen immer dann, wenn ich, wenn ich hartes Number crunching mache, wie man so schön sagt, also wenn ich.

Wirklich krasse Algorithmen durchrechnen nicht Matrizen Multiplikation mache von sehr großen Matrizen und so weiter das sind dann so die einzelnen Prozesse, die lange dauern, aber heute in der Webanwendung in der normalen, die jetzt jetzt nicht, was weiß ich gerade ne NKI Modell trainiert, sondern wo einfach weißt du user Events abgefrühstückt werden und dann ne was das typische was man halt so macht und dann geh ich ne Datenbank, geb das wieder zurück und so ich glaube das ist heute

schon ich weiß nicht wenn es den Amt da noch gäbe der würde sagen Oh das habt ihr schon ziemlich gut gemacht, da gibt es dann. Noch sehr wenig flaschenhälse, ja alleine halt, weil die modernen Programmiersprachen Python kann das auch, weil die da da einem Entwickler schon ziemlich viel an die Hand geben. So meine Sicht auf die Dinge. Ja, trotzdem bleibt es dann noch

irgendwie wahr. Ja, in dem Moment also ne, wenn irgendwas nicht parallelisierbar ist, dann ist das einfach der Flaschennetz. Das ist so o. K dann würde ich übergehen zu Teil 2 und das sind das sind Gesetzmäßigkeiten, die sich beziehen auf auf Netzwerke.

Und hier auch wieder der Erste. Das ist einer, der wurde uns da in dieser Informatikvorlesung ja einfach sehr, sehr stark eingebläut und den hab ich auch damals schon verstanden, muss ich sagen, ja, das ist der Netzwerkeffekt oder Mattcalf Law, genannt Mattcalf Robert Mattcalf war einer der Miterfinder des Ethernet und die Aussage ist, dass der Wert eines Kommunikationsnetzwerks proportional zum Quadrat der Anzahl seiner Teilnehmer ist. Was bedeutet das jetzt?

Ich hab es mir einfach so gemerkt, ein Netzwerk wird umso wertvoller, je mehr Teilnehmer es hat für jeden Einzelnen der Teilnehmer und das ist das einfachste Beispiel, sind halt Telefone, da gibt es auch gab es ein cooles Bild?

Ja, ein Telefon ist erstmal total wertlos, wenn wir jetzt uns nur den Use Case telefonieren angucken, Telefon kann heute noch ein bisschen mehr, aber wirklich das Telefon mit der Wählscheibe so 1 vielleicht im Kopf passiert jetzt mal gar nichts hab nur ich 1 hast du noch 1 bookert?

Ist das schon ziemlich cool. Da können wir telefonieren ja so n bisschen dosentelefonmäßig also der Wert ist jetzt gestiegen, weil 2 Teilnehmer und wenn jetzt n dritter Teilnehmer dazu kommt, dann ermöglicht das ja schon zur Quadratanzahl der Verbindungen die möglich sind ne. Also von mir zu dir und von uns jeweils zu dem zu dem dritten Teilnehmer, das heißt, dass dieser dieser und mit jedem

Teilnehmer wächst. Jetzt hier dieser Nutzen weiterhin ne und das ist jetzt so total offensichtlich, aber netzwerkeffekte findet man auch an ganz vielen anderen Stellen. Würd ich n bisschen was zu sagen und das ist auch total wichtig in dieser ganzen Startup und Softwarewelt, wo Investoren oft nachgucken, wenn man sich zum Beispiel Marktplätze anguckt, ne nehmen wir mal ebay, Oh ist das auch nicht mit aktuellsten Marktplatz, aber früher war das natürlich n Ding.

Wenn jetzt ein Händler da ist und und und und ein Kunde, dann hat das noch nicht viel wert, aber mit jedem Kunden steigt natürlich der Wert für diesen Händler und umgekehrt mit jedem neuen Händler darauf steigt auch wieder der Wert für die Kunden, weil sie ja wieder mehr Auswahl haben. Also es ist also ein hier kommt der Netzwerkeffekt zum tragen.

Oder n anderes Beispiel ist auch ja online Games ja oder sowas ne, wenn ich halt zum Beispiel online zocke und es sind mehr Leute drinnen, dann hab ich unter hab ich ja wieder mehr nutzen daraus, weil ich gegen mehr Leute spielen kann und gibt es noch etliche Beispiele ne also netzwerkeffekte sind total wichtig an der Stelle und klar die offensichtlichsten sind natürlich noch Social Networks aller Facebook und Instagram und so weiter und sofort ne. Meinst du das ist auch der Grund

warum sich so n Facebook, selbst wenn sie jetzt nicht andauernd Ihre UI neu erfinden und so weiter ewig hält, weil einfach die dieser Mehrwert so krass ist, dass ich halt einfach diesen sozialen Austausch auf diesen gigantischen mit diesen gigantischen Anzahl an Mitgliedern, die die sich gigantisch gegenseitig erreichen können und so der einfach so groß ist, dass es fast to Big to fail ist und sich alles irgendwie auf so n so n soziales Netzwerk zieht, ist wahrscheinlich der Grund sogar ne.

Ja, also also Facebook finde ich n spannendes Beispiel, weil. Anfangs war das glaube ich schon so, das hat ja auch angefangen an einem Campus, wo der, wo der Zuckerberg da war und dann ging das an andere Universitäten über und so, und da sind diese netzwerkeffekte, glaube ich, zum Tragen gekommen.

Plötzlich kann ich Leute erreichen in anderen, anderen Standorten und so, und heutzutage weiß ich gar nicht so genau, ob das das immer noch eine Rolle spielt, dass dass man theoretisch jeden erreichen kann, vielleicht kam das da auch an der Grenze, ich würde aber ein anderes Facebook Produkt.

Man nennen whatsapp zum Beispiel find ich total gut, weil bei mir im im Freundeskreis im Krankenkreis ist es so, dass dann immer mal wieder einer kommt und sagt, ja, lass doch mal alle Telegram benutzen oder lass doch mal alle Signal benutzen, so ist viel besser für sicherer, was auch immer. Er hat verschiedene Gründe dafür, aber es benutzt halt kein anderer und dadurch ist der Wert halt super klein. Obwohl das vielleicht die bessere Technologie ist.

Ne und whatsapp hat einfach diese Riesen netzwerkeffekte. Ne und gleichzeitig ist der Aufwand auch riesengroß, weil

kenn ich. Das ist genau das Beispiel, hab ich ja auch oder aber dann musst du zum Beispiel wenn du dann ich sag mal du hast irgendwie ein 235 Kandidaten, die haben halt sind halt die Telegrams und die restlichen mal whatsapp, dann musst du ja die gleiche Nachricht wenn du sie erreichen willst auch zweimal verteilen, nämlich einmal nach Telegram und einmal nach whatsapp und musst auch die Antworten entsprechend

in 2 verschiedenen. Ja, Bubbles quasi abfräsen und so weiter und das Macht ja dann auch schon wieder für den Teilnehmer keinen Bock mehr. Genau. Das ist genau also der Wert von whatsapp. Würde für dich noch mal steigen, wenn jetzt einer von deinen 5 telegrammen Kumpels sag ich mal auch noch zu whatsapp geht ja. Genau das ist das, was das Gesetz sagen will. Glaub ich ne. Richtig also ist natürlich immer

noch total relevant. So ist ja jetzt auch unabhängig von irgendwie Technologie der Netzwerkeffekt und ja ist quasi

auch ne Erklärung für. Im Startup Wesen, wo man sagt, so der Winner takes it all oder oder auch nicht im Startup, im im Technologiebereich allgemein der Winner takes it all Mentalität, dass man versucht also sowas wie wie whatsapp eben ne ist, dann ist ja ein Winner der alles bekommt, weil diese Netzwerkeffekte eben so groß sind, ne und wenn man sagt alles heißt das meist 90% 95% kleiner Teil weigert sich immer noch.

Also eigentlich ne coole Sache als Startup auf sowas zu setzen, aber dann gleichzeitig extrem schwierig, weil entweder ja schaffst du es dann oder bist halt komplett tot.

Ja, und ist spannend. Also jetzt mal auf unseren Bereich bezogen könnte es ja sein, wenn man sagt, also wenn wir, wir arbeiten ja bei der Heisenware mit den Maschinenbauern zusammen und mit den Produzenten, ne wenn wir jetzt viele Maschinenbauer haben, die vielleicht unsere Software benutzen um Daten zu verfassen bei Kunden, hat das vielleicht für nen Endkunden direkt nen Vorteil wieder weil seine Maschinen direkt vernetzbar sind ne und er direkt

austauschen kann mit seinem mit dem Maschinenbauer, mit dem Lieferanten. So könnten wir Netzwerkeffekte tatsächlich aufbauen, ne, also sprich für einen weiteren Kunden ist es für uns n großen Wert, wenn wir schon viele andere haben. Alles klar, das musst du dann aber regeln. Gerrit, Das ist Sales.

Gut. Gut, Let's go to the next one. Das Cap Theorie hast du aufgeschrieben, Gerrit das Gesetz der verteilten Systeme, vielleicht magst du da auch kurz noch n paar einleitende Worte sagen zu. Das kann ich machen und. Dabei versteh ich aber gar nichts. Ja, die Aussage ist die, dass ein verteiltes Datensystem immer nur 2 der folgenden 3 Garantien

gleichzeitig bietet. Consistency, Avalability and Partition ja, was so viel heißt wie Konsistenz, Verfügbarkeit und Auswahltoleranz was bedeutet das denn jetzt? Ja, das ist fies. Also ich, ich find es gemein, dass es das gibt, das willst du eigentlich nicht haben, aber es sagt so viel wie du kannst. Ich glaub davon gibt es auch noch mehrere ich aber ich hab dir jetzt hier nicht mit rausgesucht, die so ähnlich sind.

Ich hab auch schon mal 1 gesehen, dass es eine Matrix ist mit vieren und so weiter aber es scheint so zu sein, dass es Gesetzmäßigkeiten gibt, dass du, dass du kein perfektes System

hinkriegst. Ja für alle Use Cases, was du eigentlich haben möchtest ist ja, dass dein System sowohl konsistent als auch hochverfügbar ist, als auch überhaupt gar keine Ausfalltoleranz duldet so ja dann, das wär natürlich super, danach strebt jeder und dieses Gesetz sagt Halt, das kannst du halt knicken, ist quasi. Wir haben gesagt, es sind keine Naturgesetze, aber es ist quasi trotzdem in Stein gemeißelt, dass du, dass du das nicht

schaffst. Ja, und dass du die Zähne ausbeißen wirst, wenn man das weiß, dann kann man sagen, OK, ich kann halt, und das sagt das Gesetz, ich kann halt 2 von diesen Eigenschaften optimieren, aber nicht alle 3. Ja, ich glaube, das ist, das ist sehr stark angekommen, also das, das weiß ich auch, ja, und dann muss man sich halt fragen, was bin ich und für den Anwendungsfall den ich lösen will. Was sind mir die 2 wichtigsten

aus diesen 3? Ja, warum brauche ich, muss ich extrem konsistent sein und verfügbar und ist vielleicht nicht so wichtig, dass ich mal, wenn ich mal kurz weg bin, ja dann können die verknoten, ja die die User oder aber ist genau

das andersrum? Ja bin ich zum Beispiel eine Bank, mach online Banking, dann habe ich ganz klar auswahltoleranz muss gegen 0 gehen ja und Konsistenz muss auch, muss auch super gewährleistet sein ja und dann ist vielleicht Verfügbarkeit. Dann ist halt kurz mal das online Banking nicht erreichbar oder irgendsowas ja, das ist dann vielleicht noch die die Pille, die man am besten

schlucken kann. Ja, aber bevor mein System inkonsistent wird und ich nicht mehr weiß, hat er das überwiesen oder nicht und das ist auf jeden Fall der größere Schaden fürs Online Banking. Ja und jetzt guckst du irgendwie nen guckst du irgendwie nen was weiß ich linkedin an oder irgendsowas da ist die sagen vielleicht OK wenn linkedin down ist so dann schreit halt die ganze Welt so ey ich kann irgendwie nicht mich einloggen oder irgendsowas. Da ist halt ausfalltoleranz der Quatsch.

Verfügbarkeit ist halt der wichtigste Faktor, das muss halt

immer immer immer an sein. Ja und selbst wenn da mal ne Nachricht schiefgeht oder doppelt gepostet wird irgendsowas drumhin ja dann ist es auch nicht so schlimm, vielleicht zeigen diese beiden Beispiele sehr unterschiedliche Use Cases und es zeigt halt warum das so ist, dass man das nicht machen kann, das weiß ich selber irgendwie nicht so ganz genau, das ist irgendwie schade, ja ich würde auch lieber versuchen alle 3 zu optimieren, aber.

Genau, es ist ne Heuristik, man hat das so festgestellt und es wird irgendwie nicht gut funktionieren. Ne man sollte es nicht versuchen und sich die Zähne dran ausbeißen ne ich glaube. OK mehr kann man da glaub ich erstmal nicht zu sagen. Ne, dazu bin ich auch zu wenig Mathematiker und so weiter als dass ich jetzt hier irgendwie ne auf das Audio schon ne Beweisführung hin hin Bauern könnte so das das akzeptiere ich jetzt auch einfach so.

Wir müssen also Architekten auf dem auf dem Zettel haben und können sich dann noch mal weiter reinfuchsen, wenn man das möchte. OK, ich hab da aber noch eine Frage dazu. Kannst du jetzt so etwas sagen was die was jetzt da genau der Unterschied zwischen der Verfügbarkeit und der Auswahltoleranz ist? Also es geht ja hier um um Gesetz der verteilten Systeme.

Also wenn ich ne Verteilung hab, dann hab ich also verteilte Komponenten und man muss davon ausgehen, je größer das verteilte System ist, so größer ist die Wahrscheinlichkeit, dass mir eine Komponente von diesem verteilten System völlig abraucht. Also jetzt mal im Computersprech, darum geht es ja. Habe ich halt irgendwie 2 Computer in meinem verteilten System, dann ist die Wahrscheinlichkeit, dass einer davon ausfällt, wenn ich die irgendwie beide gut kenne,

relativ klein. Habe ich aber eine Millionen Computer, dann ist es keine Ausnahme mehr, sondern die Regel, dass davon vielleicht alle 10 Sekunden einer komplett ausfällt, weil dem die CPU Durchbrennt, die Hardware komplett kaputt geht, die Festplatte abrauscht oder irgendsowas, das ist die Ausfalltoleranz also. Wie stark beeinträchtigt das das gesamt die Gesamtleistung des Systems, wenn halt ein so n Ding ganz weg ist?

So ja und das wird halt ich würde sagen, ich hatte die glaub ich die interne Größe was damit zu tun. Also wenn ich ein ein riesiges System habe, ja dann kann ich das schon erreichen, dass ich ne ganz gute ausfalltoleranz hab. Je kleiner mein verteiltes System wird desto desto drastischer ist quasi das ausfallen einer Komponente für den Rest der Komponenten und so weiter Verfügbarkeit sei es einfach nur ist es da ist es für mich als Anwender sofort zu

nutzen. Und es, das kann halt gut sein, dass irgendwie vielleicht sogar ein Rechenzentrum komplett abgibt, weil da irgendwie der Bagger das Kabel abgedonnert hat. Trotzdem ist für mich die Anwendung verfügbar, ich merk das nicht, im Hintergrund werden vielleicht irgendwie schwer die Datenbanken Daten hin und hergeschoben, weil weil es aufgefangen werden muss und so, aber das System fühlt sich verfügbar an ne ich glaube das ist ich hoffe das beantwortet eine Frage.

Ja, absolut OK. Verfügbarkeit ist insbesondere etwas, was der User erlebt hat. Ich glaub das ist auch ein bisschen scheinbar. Genau. So versteh ich das. Gut, dann Nummer 6.

Das Gesetz der Toleranz, Postal Slaw, John Postal, anscheinend einer der wichtigsten Pioniere des Internets, der für die Verwaltung der IANA zuständig war, und das ist das zentrale Adressbuch des Internets. Kennst du das? Sogar du kennst das auch. Wir hatten schon ganze Folge darüber ist. Es das mit DNS und so weiter. Ja, also alle die, die jetzt nicht wissen, was die Jana ist, die können ja die DNS Folge, die ich nicht auf dem.

Ich weiß nicht, welche Nummer das ist, aber die findet man ja bei uns im in der Historie. Ja OK, dachte ich, aber weil das hier den ist gut dann die Aussage ist sehr konservativ in dem was du sendest und liberal in dem was du empfängst. Das wär ja total cool. Ja ist super geil. Das Beispiel ist quasi, dass ein Webbrowser beim Senden von Daten sich also strikt an die an die Web Standards halten sollte, also da soll er sehr konservativ sein, sich an die Regeln da

irgendwo halten. Wenn er aber eine Webseite empfängt und öffnet, die irgendwie ja kleine Fehler im Code hat, ne, also nicht perfekt quasi sich an die Standards hält, dann sollte der Browser an der Stelle eher liberal sein und und tolerant dieser Website gegenüber sich trotzdem irgendwie anzeigen, vielleicht mit kleinen Lücken oder sonst was. Ne, also Dinge die nicht perfekt angezeigt werden, aber lieber irgendwas als gar nichts, so könnte man es verstehen. Ne, ich hab n anderes Beispiel.

Als Papier, wenn wenn deine Kinder, wenn deine Kinder noch klein sind, dann haben die auch noch keine perfekte Grammatik und keine perfekte Aussprache. So weiter am Leib und aber als Eltern verstehst du die sehr sehr wohl.

Also du bist komplett liberal was du was du empfängst von deinen Kindern, während die mit dir sprechen, deswegen solltest du aber nicht unsauber antworten oder auch irgendwie flapsig flapsige Wörter oder schlechte Grammatik benutzen, sondern exakt den Regeln der deutschen Sprache antworten geben, obwohl du was ziemlich kauderwelschiges empfangen hast. Denn sonst lernen die Kinder nämlich auch nicht, wie es

eigentlich richtig ist. Ja, und so bleibt das System auch stabil zwischen Ansprache und Antwort und so weiter. Sehr gut also. Die Babysprache kannst du dir schenken, quasi ja. Ja, genau, aber man man erkennt, ich weiß nicht, ob du das schon mal gesehen hast.

Mich nervt das tierisch. Also ich bin auf jeden Fall der Verfechter dieses Gesetzes als Papa, ich rede also so wie ich auch mit dir reden würde, rede ich auch mit meinen Kindern, also jetzt vielleicht nicht vom vom inhaltlichen, aber von der von der Grammatik und von der Sprache her, das gibt aber ganz andere Eltern, die. Ja und so weiter. Wo du denkst, so was ist denn also wie lern ich das

eigentlich? Und jetzt die richtige Sprache so. Ich hatte neulich n Thema, glaub ich als wir als wir wandern waren sag ich so ja ich da ne Mu oder so zu einer Kuh und dann dann genau oder so na ja das ist ja aber ne Kuh und ich so OK soll ich dann Kuh sagen ja sag einfach Kuh OK. Ja, ich glaub das ist halt total wichtig genau und da sicherlich hat sich der Kollege das jetzt nicht dabei gedacht, aber das ist genau das, das ist genau das

Thema, das ist trotzdem, darum geht es ja und in der in der Informatik um darauf zurückzukommen ist es halt n selbsterhaltungsmechanismus, weil weil es dazu führt eigentlich, dass das Internet so stabil ist und stabil bleibt wie wir, wie wir es haben, würden wir jetzt halt ganz krass die Regeln durchziehen, ja oder dann wär vielleicht tatsächlich was du sagst, überall ist mal n kleiner Fehler oder irgendwas, ja jetzt wo wir KI haben, da ist auch überall mal n kleiner

Fehler drin. Und wenn die Webseite da einfach gar nicht mehr sich anzeigt, nur weil da irgendwo irgendwas drin ist, dann würde das alles nicht so funktionieren und relativ hart zusammenbrechen. Ja, das ist schon n ganz cooles Cooles, das ist einfach auch so ne Weisheit, finde ich ja das

Klimatom, das heißt wenn könnte. Man schon mal sagen, wenn irgendwie Fehler mit ankommen oder es es Fehler gibt, dann einfach an der Stelle liberal tolerant zu sein als Computerprogramm und trotzdem noch das Beste draus machen und nicht nicht den Dienst zu quittieren, ja. Ja, und das also. Also heutzutage ist ja das Internet relativ weit ne und die Standards auch relativ lange

abgehangen sag ich mal. Das war ja auch nicht immer so und ich weiß noch die Zeiten als so als das so mit dem Web richtig losging und so, da CSS zum Beispiel, also unsere cascading Stylesheets, die Sprache, die quasi definiert wie ich Sachen anzumalen hab und so weiter die hat sich auch fortentwickelt und die kommen ja gar nicht so schnell hinterher, die armen Browserentwickler das ist alles richtig umzusetzen so und es haben sich aber dann immer die Browser erfolgreich

gemeldet. Bei denen halt möglichst viel von diesen neuen, im Standard begriffenen Möglichkeiten verstanden wurden und aber auch gerade der schräge Kram, den irgendwelche anderen Leute schon vorher vielleicht in die Welt gebracht haben, bevor es irgendwie abgesegnet wurde durch irgendeinen Web Standard. Ja, wenn das halt auch ging und nicht deine Webseite nicht kaputt ist, weil du hast sofort n Mehrwert natürlich wenn du, wenn du jemand bist, der ne

Webseite zur Verfügung stellst und baust. Die sich aber irgendwie nur im Safari cool anzeigt und irgendwie im im Microsoft explodierer Entschuldigung Explorer immer noch nicht Explorer, dann halt nicht cool

anzeigt. Ja dann dann findest du halt den Microsoft Explorer blöd, aber du findst halt den Browser cool, wo das halt einfach alles funktioniert und der halt einfach mal über irgendwelche Sachen, die vielleicht noch gar nicht so klar standardisiert sind, drüber bügelt und das halt einfach mitdenkt und so gut wie es geht mit richtig macht ja perfekt, das sagt das glaub ich. Super, dann kommen wir zu Teil 3. Ja, von unseren Gesetzen. Der Mensch. Aber insgesamt ist das Gesetz

Nummer 7, ist vielleicht wichtiger, und das ist Brooks Law, und das ist das Gesetz des Projektmanagements und ich würde behaupten, das hat jeder und jede schon mal erlebt.

Die Aussage ist, wenn ein Softwareprojekt bereits im Verzug ist, führt das Hinzufügen von weiteren Entwicklern zu einer noch größeren Verzögerung und da muss ich immer denken, also vielleicht noch ganz kurz, wer ist wer ist West Brooks, das ist Fred Brooks, der hat das Buch The Metacal man month geschrieben, also der Mythos des. Mann, Monats oder Menschen Monats und ich find das merkt

man immer. Ja also und und das merkt man auch total ja mit Verlaub bei uns so n bisschen manchmal, wenn wenn neue Softwareentwickler dazu kommen, dann wird das mal

alles n bisschen langsamer. Ist zwar kein Projekt sondern wir haben ein ein langfristig werden wir ein Produkt ja aber dennoch merkt man auch da wird das mal langsamer dann am Ende zahlt es sich aus aber gerade bei Projekten die natürlich n klaren Anfang und Ende haben ist es natürlich so, dass es dann tut einfach nur alles verzögert mehr Ressourcen drauf zu schmeißen statt. Leute sich noch tiefer drauf konzentrieren lassen zu können. Genau.

Und ich glaube das das stimmt halt für also, also für Software stimmt halt deswegen, insbesondere weil das, weil das was man damit macht halt relativ komplex in sich selbst ist. Aber ich glaube, das gilt Halt für alles mögliche andere, was

sehr komplex ist. Ich weiß zum Beispiel im Architekturbüro, wenn du da ein Projekt hast, wo sehr viele feine Absprachen stattgefunden haben mit einer bestimmten Person. Und man da jetzt quasi das beschleunigen will, indem man einfach neue Personen hinzufügt,

ist es genauso. Ja, also diese neue Person muss ja erstmal aufholen, was alles schon besprochen wurde und was alles nicht soll und so weiter das ist halt, ich glaube die ist ganze Zeit immer dann gültig, wenn die Grundlage auf dem du arbeitest halt so ist, dass sie eine geteilte komplexe Wahrheit widerspiegeln, die alle gleichzeitig tief verstehen müssen, um es gut zum Ende zu führen. Ja und das da gibt es mehrere Beispiele, die. Unter Softwareentwicklern, ganz klar.

Aber wie gesagt, Architektur, Architektur fällt mir gleich als Nächstes ein und garantiert auch n paar andere Sachen, ne. Ich, ich möchte es noch mal betonen, ich glaube, es ist insbesondere bei Projekten so halt die halt wirklich so ne ne ne Deadline haben ein Ende ein ein fixes Ende, anders als bei Produkten logischerweise Teams die immer weitermachen, da lohnt sich natürlich ne Einarbeitung von neuen neuen Kollegen und Kolleginnen in den Produkten haben und.

Ich glaub das das Wichtigste ist, dass man. Quasi bevor es losgeht. Wenn du das Projekt hast, dass

man da sich überlegt, wie viele werde ich dafür brauchen müssen, um die Deadline zu machen. Das ist natürlich extrem kompliziert, aber dann habe ich natürlich höhere, anfangs höhere Anfangskosten, aber dann im Projekt quasi das Team, was ich brauche, um es dann auch zügig fertig zu machen. Was haben wir als nächstes? Magst du dir mal vorstellen?

Conways Laws so aufgeschrieben Gerrit das Gesetz der Organisationsstruktur. 1967 ja, da ich glaub, das war Mondlandung oder Irgendsowas, da gab es ja überhaupt erst die ersten Computer und angeblich wurde diese dieses Gesetz von Convay erst bekannt, nachdem es der Kollege von unserem vorigen Gesetz, nämlich der Herr Brooks, mit zitiert hat und es sagt so viel aus wie mal knapp gefasst ist, dass die innere Architektur, der Aufbau einer größeren Software Applikation,

die Teamstruktur. Der Entwickler oder der Firma sag ich mal die dahinter steht, relativ klar widerspiegelt oder noch mal in anderen Worten hab ich zum Beispiel ein Team, was sehr klare und strikte Aufgabentrennung hat, zum Beispiel das Team Frontend und das Team Backend und das Team Datenbank und das Team UI Design oder Irgendsowas. Dann dann, so sagt das Gesetz, würde man im Code dieser starken

Trennungen auch sehen. Und es führt dann zu Komponenten, die die, die dann in sich sehr schlüssig sind, aber die dann nach Außen her losgekoppelte Interfaces haben und so weiter da glaub ich ist was dran. Ja da hast. Du total was dran. Das hat auch der auch wieder der Hendrik vor 2 Folgen erwähnt. Convest Law als wir über die Moduliten gesprochen haben. Ja, nicht moduliten mit Nordpol, sondern Moduliten hast du gesagt, ne? Hab ich gesagt.

Ja gut, ich wollt es nur noch mal, weil das kann man ja schnell verhören, ja. Vielleicht undeutlich. Genau das ist nicht so gängig, deswegen ja richtig gut, dass du

es noch mal sagst. Nee, wirklich, der Modulit ja, also verschiedene, er hat das mein ich in dem also lieber besser noch mal selber nachhören, aber er hat das im Kontext gesagt, dass es also verschiedene Teams also gibt, die verschiedene Module einer Software zur Verfügung verantwortlich sind und dann aber später im compile Prozess oder irgendwo dann doch wieder ein.

Monolith Ja, entsteht ja aus diesen ganzen Modulen, also in dem Kontext wurde es einfach erwähnt und und das zeigt eigentlich, dass es heute noch mal ja wieder noch relevanter ist, dieses dieses Gesetz denn je und ja, quasi auch noch mal sagt, dass ne Organisationsstruktur oft irgendwie nach den nach der Technik aufgebaut ist. Die Frage ist ja, was ist, was ist die bessere Religion?

Ne ich weiß es gar nicht. Hast du also typischerweise, wenn es jetzt modulartig ist und du hast stark getrennte Teams. Dann wirst du wahrscheinlich sehen, dass es auch die also Code ist ja quasi wie Buch schreiben.

Du kannst n bestimmten Slang haben, ne Art wie du Sachen Ausdrückst, ne die sind wahrscheinlich pro Modul dann homogen und kohärent und dann guckst du ins nächste Modul und vielleicht ne ganz andere Technologie, ganz andere Art und Weise die gleichen Probleme zu lösen, weil es halt andere Leute waren n anderer hauptverantwortlicher Entwickler und er hat gesagt die machen das immer so und ich stell es einfach nur in Raum, muss ja gar nicht schlimm sein und nicht

schlecht sein, bloß wenn es jetzt einen gibt der das alles übersehen muss. Der das komplett Ding über alle Module hinweg angucken muss, der leidet dann natürlich ein bisschen, weil der eine nicht homogene Technik quasi sich anguckt, weil man dann schon klar sehen wird, OK, das hat, da hat wohl der eine verantwortlich gezeichnet, da der andere und da der nächste kann schwierig sein, muss es aber nicht, weiß ich nicht genau, ja würde ich mal so im Raum stellen, ne.

Ja, umso wichtiger, als wieder einen Architekten zu haben, glaube ich. An der Stelle der gewisse. Entscheidungen oder Entscheidungsbefugnisse einfach auch hat. Genau.

Und was würde dann passieren? Und das das würde wieder das Gesetz widerspiegeln, hättest du n Architekt, der das von vornherein verantwortet, die Teams der Modul der Moduliten, der würde halt sagen der passt mal auf nee also wir machen, also wir einigen uns jetzt mal hier das und das machen wir so ja und zwar quer über alle Module ja was zu einer homogeneren Technik führt ja ich also ich bin auf jeden Fall, ich mag zwar microservice nicht, mag dass wir technisch Sachen

modular aufbauen. Ich bin aber Verfechter von Homogenität. Ich finde, man hat noch ne schönere Architektur n eleganteres System, wenn innerhalb der Module die kleinteiligeren Sachen dann auch trotzdem gleich getan werden, ne, obwohl es nicht müsste. Also technisch ist es überhaupt nicht notwendig, ja, aber genau aus diesen Gründen, der kommt ja vielleicht nochmal n anderer Architekt rein oder irgend so was.

Irgendwer muss ja immer so ne Software mentain, die ist ja nicht, die ist ja nicht fertig und steht im Schrank, sondern irgendjemand hat ne Idee oder irgendwas muss angepasst werden an ne zukünftige Technologie. Und schon muss ich mir das alles genau angucken und das verstehen. Ja, und dann ist es schicker, wenn es einheitlich ist. Oder du willst mal Teammitglieder tauschen oder sowas? Gut, das war Conways Law und

jetzt kommen wir zu unserem neunten Gesetz von heute, Hoffstetters Law vom Pulitzer Preisgewinner Douglas Hofsetter und ich würd es, ich würd es besonders gewinnen, weil der sagt quasi es dauert immer länger als man denkt, selbst wenn man hoffsetters Law berücksichtigt. Ist ja rekursiv was. Und ich glaub, das kennt.

Jeder, jeder ja, also es dauert höchstens 2 Stunden für ne kleine Änderung sagt jemand, ein Entwickler vielleicht und dann dauert das doch länger, weil es gibt immer diese Unknown unknowns, diese sogenannten oder manchmal werden die auch Black Swans genannt, in der in der in der in der Managementliteratur, also ja, unvorhersehbare Ereignisse, auf die man sich aber einstellen muss, dass sie, dass sie eintreffen, ne, diese Unknown unknowns ist mehr so n bisschen n Scherz glaub ich ne.

Und ich glaube, es wird auch dann mehr so als Scherz genagt von Menschen, Entwicklern, dass irgendwas wirklich schnell geht, weil ich glaube, Entwickler sind auch echt genervt, wenn sie immer gefragt werden, wie lange irgendwas dauert. Ja, hier der Kollege, der die Kirche angemalt hat.

Michelangelo. Ja, von dem ist ja auch ein ganz ganzes Zitat zu diesem Thema, der wurde ja ständig gefragt von seinem was weiß ich, was das der Bischof war oder was, keine Ahnung, ja wann bist denn du endlich fertig, damit ich fertig

bin, es hat ja halt einfach. Auch ewig gedauert und da kannst du keine seriöse Aufwandsabschätzung zu machen, wenn du die verdammte Decke von der ganzen Kirche irgendwie mit feinen Pinselstreichen da gibt, bedecken sollst, musst gleichzeitig noch drüber nachdenken, was du vielleicht da überhaupt erst noch mal hinpinselst und so, das passt das Bild ganz gut, weil ich glaube aufwandsaufschätzung Abschätzung ist dann seriöser zu machen, wenn die Teile, mit

denen du arbeitest. Klar zur Verfügung sind und und alles schon immer so war und du quasi die Erfahrung hast und Abschätzung hat was mit Erfahrung zu tun find ich also wenn du schon mal gemacht hast, dann weißt du ja wie lange es dauert ja und wenn du was sehr ähnliches noch mal machen musst funktioniert die Aufwandsabschätzung besser. Ja und bei Software ist das Problem glaub ich das ist halt so n dass quasi fast jedes Softwareprojekt irgendwie so n

bisschen NRND Projekt ist. Weil du wirst immer irgendwas machen was du so noch nicht gemacht hast. Ja ich glaub das ist also wie. Zeigt mit dem Softwareentwickler, der wirklich alles schon einmal entwickelt

hat und die Erfahrung hat. Ja und für das brauch ich so und so lange, ja, das gibt es glaub ich nicht und insofern kommen da kommen da ganz schlimme, kommen da immer so ganz schlimme schwarze Boxen gut, einfach so über n Daumen so und dann dann geht es ja auch schnell als Entwickler du kommst nicht voran, heute stimmt es vielleicht nicht mehr ganz oder kannst die KI fragen, früher konntest du im Notfall keinen Fragen und dann dauert es einfach ja musst du es

ausprobieren. Mhm und was ich glaub noch sagen wollte, der der Kontext ändert sich ja auch selbst wenn du was. Genau gleich oder was gleiches machst, ist es vielleicht in einem anderen Kontext und dadurch hat es wieder andere

Abhängigkeiten et cetera. Aber ich glaube, es ist schon NN großer Wert. Deswegen sag ich immer, ich finde also, ich finde immer der Wert eines Softwareentwicklers ist dann nicht nur einfach seine schiere Kompetenz, es ist einfach die Erfahrung, ich glaube, aus einem Grund ist das auch so, weil weil du tatsächlich, wenn du sehr viel und sehr lange schon was gemacht hast, genau das etwas besser hinbekommst vielleicht als dein Junioriger genauso gut ausgebildeter und auch genauso cleverer.

Kollege, der aber einfach noch nicht diese ganzen Dinger gesehen hat, da seinen Fingern ne, das ist glaub ich aber ja es ist sowieso ne Folge, da wir hier n bisschen religiösen und glauben und Meinung und so weiter aber das macht ja nichts. Ja wir bringen mal diese Gesetze an, ne. Denkt einfach an den Hofstetter oder Hofstetter, wenn wenn es drum geht Aufwandsschätzungen zu machen oder Zeit zeitschätzungen OK dann noch so 2 übergreifende Prinzipien zum Schluss.

Und die, die die erste davon also und sag ich jetzt Nummer 10 würde ich dir wieder übergeben. Das ist High Roms Law. Ja, das finde ich total. Das ist das doch so. Ja, das hab ich, ich kannte das nicht, ja, aber das ist ja so wahr, wie es wahr, da steht ja also genau das Gesetz der impliziten Schnittstellen, was soll denn das heißen, also das heißt Pass verdammt auf was deine öffentliche API ist.

Ja, die ist ja egal was du dokumentierst, also was dein System kann wird, und das sagt das Gesetz. Auf jeden Fall genutzt werden, wenn du denn nur genug User hast und die genug Zeit hatten dein System zu malträtieren.

Ne, und das ist dieses Gesetz ist nicht so wichtig für Leute die mal n kurzes Projekt machen oder irgendwie ne App machen und die ist dann fertig und die sind sich geschlossen und dieses Gesetz ist ja die Hölle wichtig für alle die so ganz langfristige Services zur Verfügung stellen und so weiter die drauf angelegt sind irgendwie jahrelang irgendwie zu funktionieren. Ja also Google selber zum Beispiel, die haben jetzt zig APIS, ja für.

Für Google Maps und so weiter wie man das anfragt, wie man da dann seine seine Routen zurückkriegt und so weiter und sofort ja und und die sagen halt selbst wenn du es irgendwie dokumentiert wie du es benutzen hast, die Leute werden halt auch die undokumentierten Features oder hidden Features deiner API.

Gutes Beispiel ist Sortierung zum Beispiel ja du sagst einer Dokumentation Alter Verlass dich nicht drauf, das ist nicht sortiert, du gibst es aber immer alphabetisch sortiert zurück, ja. Und der Erste hat halt keinen Bock, deine Doku zu lesen. Baut seine ganze Anwendung drauf und verlässt sich, weil es schlimmer so war. Darauf dass es halt sortiert ist.

Und irgendwann machst du NAPI Upgrade, die implizite Schnittstelle quasi und dann hast du es halt einfach nicht mehr sortiert, weil es für dich jetzt performanter ist, weil du ne verteilte Datenbank hast oder oder und die Leute fangen an zu maulen, weil deren Anwendung nicht mehr funktioniert und du sagst irgendwie so Maultier hab ich.

Hab ich ja dokumentiert, aber das Gesetz sagt Halt ja, die maulen halt trotzdem ja und zurecht irgendwie und sieh zu, dass du selbst diese Sachen irgendwie in den Griff kriegst. Und das ist ultra fies. Ja, weil ich glaube, also alle alle teilen diesen Pain mit mir, die irgendwie langfristige APIS aufbauen müssen, müssen wir auch, weil du bist so in der Zwickmühle zwischen du musstest mich auch ausliefern, jetzt mal.

Beim alten Gesetz dauert alles länger als du denkst und dann musst du es so ausliefern, dass das alles so safe ist, dass in 5 Jahren dich keiner anmault. Dafür musst du so viele Edge Cases bedenken. Das dauert so viel länger und du bist dann so gefangen in diesem, was du dir einmal ausgedacht hast. Technische Schulden und so. Ja und es ist so hart die API zu ändern, irgendwie mal zu brechen, so ohne dass dich alle anschreien, ne, aber das ist halt ist halt auch so n Naturgesetz.

Naturgesetz, warum hast du Grad Google erwähnt? Willst du mal was zum Hirram Wright sagen? Nö, ich dachte jetzt Google ist mal n ganz schönes. Ganz schönes Beispiel für ne für ne für ne Firma die sehr sehr viele Nutzer hat und die und die halt sehr viele apis auch haben. Google hast du hast du hast du was auf der Zunge was was ich jetzt nicht auf dem Zettel hab Haus Haus. Der, der die Iron Slaw kommt vom Iron Wright interessanterweise

vom Vornamen jetzt abgeleitet. Vielleicht gab es Wright slaw schon und der war bei Google ja. Guck mal, sich, das hat ich jetzt gar nicht auf dem Zettel, aber. Ja ne, ist nicht schlimm. Macht Sinn. Ja OK das der das Leid erfährt glaub ich gerne ja. Dann würd ich sagen, last but not least einen, den eigentlich

wir alle kennen, der auch echt nicht nur in der Informatik stimmt. Das ist das Pareto Prinzip oder die 8020 Regel, benannt nach dem italienischen Ökonomen Wilfredo Pareto. Woher kommt es und ich glaub das wissen nicht so viele, ja der hat 1906 beobachtet, dass 80% des Grundbesitzes in Italien im Besitz von 20% der Bevölkerung waren. Ich glaub wenn es danach geht, wär es heute wahrscheinlich ne 95 5 Regel oder so ich glaube Grundbesitz hat sich noch krasser.

Ja, zugespitzt auf auf weniger Menschen, aber gut, 1906 warst du in Italien, also für mich ist es total im Sprachgebrauch und total in meiner täglichen Arbeit, wenn nicht 8020 ist in 80% der Fälle die richtige Herangehensweise, also würde ich jetzt mal sagen ne und die Aussage ist quasi, dass 80% der Auswirkungen durch 20% der Ursachen hervorgerufen werden, um es mal wissenschaftlich auszudrücken, beobachtest du es auch in deinem Alltag? Also ich muss sagen, ich kannte

es nicht. Also du dachtest ja gerade, dass das hat irgendwie jeder schon mal gehört, ich hab es noch nie gehört und das nee, ich fand, ich fand es total spannend, ich find es auch so n bisschen schauerlich, dass man das irgendwie so fest wieso 80 2. Warum nicht 7030 oder 6040 oder 9010 keine Ahnung so ich also für mich ist das Spucki und tatsächlich also ich werd jetzt mal gucken ob das so stimmt in Zukunft wo ich das jetzt gehört hab hab ich so jetzt in der

Technik tatsächlich irgendwie nicht so auf dem Zettel ehrlich gesagt. Und ist dann vielleicht dadurch. Ne Self fulfilling provicy fast schon so ne, wenn man das im Kopf hat und weiß. Ah es gibt jetzt 8020 irgendwie oder pareto, dann hat man das immer im Gefühl, dass man eigentlich mit 20% des Aufwandes irgendwie 80% des Ergebnisses

erreichen kann. Das ist eigentlich so der Klassiker, also in der Betriebswirtschaftslehre sag ich mal unter oder unter BWL ern schwer verbreitet, vielleicht bei Technikern nicht so, aber ich find jetzt die Beispiele hier eigentlich ganz cool eigentlich für die für die Informatik, also dass man zum Beispiel 80% der Nutzer nur 20% der Features zum Beispiel benutzen. Und dann hast du noch 20% der Feed der Nutzer, die deine anderen 80% brauchen. Was sagt das quasi?

Sagt der, dass du eigentlich mal n bisschen gucken musst? Mach ich für die für die Masse was oder mach ich hier wieder was hochspezielles ja und und und sollte dir da die Finger von lassen. Ach so, OK, jetzt macht es bei mir noch n bisschen mehr Klicks, sogar mit dem Beispiel ja. Das ist nur eine Anwendung. Ja, man kann auch sagen, dass sich 80% der Fehler in 20% des Codes befinden, oder?

Wie gesagt, das das häufigste ist aber eigentlich, dass man oft mit 20% des Aufwands 80% des Ergebnis hinbekommt, also im Sinne von einem MVPN Prototyp oder sowas.

Was also das also 80% der Fehler in 20% des Codes ist das das hab ich so, sowas hab ich noch nie gehört aber das ich das werd das werd ich mal überprüfen demnächst also ich werd das n bisschen mental verfolgen ja das OK kann ich mir kaum vorstellen, aber das mag so sein ja was ich gerne gerät aber ich weiß nicht ob das das Gesetz auch wieder gibt also was wir immer so unter den Softwareentwicklern sagen ist wo machst du denn Schluss so

ja mit. Also du hast zum Beispiel n Feature und bist irgendwie bei 90% und die hast du schnell erreicht. Das sagt man immer so 90% hast du schnell erreicht und auf den letzten 10% alles fertig zu glänzend zu polieren verlierst du halt exponentiell mehr Zeit als du für die 90 gebraucht hast.

Ich weiß nicht ob das das jetzt mit abdeckt, so aber also also das diese diese Gesetzmäßigkeit kenn ich, aber da sprechen wir also oder ich kann weiß ich nicht mehr so 90% zu den letzten 10% sagt man immer so letzten 10% ja Katastrophe. Lass die lieber gleich weg, so hör auf bei 90, du bist fertig.

Ja, das also Pareto wird wird genau dafür auch genutzt, aber offensichtlich ja, was man jetzt hier n bisschen nennen kann ist, dass es eigentlich woanders herkommt, also um Verteilung, während ich glaub, dass heutzutage meist genutzt wird. Ja sagt man halt zu Flaps, ich geh nach Pareto vor, das heißt investiere nicht so viel, aber du hast dann eigentlich schon deine 80% Lösung oder 90% ja dann mach erstmal Schluss einfach vor Schluss. Reicht hin, dachte.

Ja, ja, coole Folge find ich Gerrit cooles Thema. Ich hab auf jeden Fall noch n paar neue Regeln gelernt, die ich so vorher nicht auf dem Zettel hatte.

Schauen wir mal ja zum Gesetz der großen Zahlen und so weiter spielt ja auch alles n bisschen mit, ja mal gucken wie unsere Zuhörer das finden und erlebt haben schon vielleicht auch in ihrem Leben lasst uns doch gern einfach mal auch n Kommentar da oder n like wenn ihr es cool fandet freuen wir uns immer motiviert unglaublich und da sag ich heute mal als erster Danke Gerrit für die Folge. Und fürs für heute Mitexperte

sein. Und ja sag ich mal, schieß aus Hamburg. Ja danke dir Burkhard, ich glaub du hast da schon immer noch viel mehr zugeliefert und eigene Erfahrungen, die das ganze noch noch viel viel greifbarer gemacht haben. Also war cool und ja danke euch fürs Zuhören bis in 2 Wochen schönen Sommer ciao. Einfach komplex wird produziert und präsentiert von Heisenware Heisenware ist deine lowcode Plattform zur Erstellung und zum Betrieb interaktiver Apps rund um den Shopfloor.

Starte noch heute dein Free twil unterheisenware.com einfach minus komplex.