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.